RGJ
(Richard - Communiteq)
1
我一直在考虑这个问题，并决定将我的想法分享给大家，听听你们的看法。
在过去的几个月里，我与许多试图建立直接客户支持的人交流过——即支持团队解决（机密）客户特定问题——作为他们现有（公开）社区支持论坛的补充。
大多数解决方案都涉及“assign”、“solved”和“ticket”插件，然后有多种方法（但似乎没有万能药，这就是我开这个话题的原因）。
解决方案 #1：为每个客户创建单独的类别/组
这只适用于客户数量相对较少的情况，而不是数百个客户。
这里的主要缺点是：“（…）你正在创建一个专门的票务平台，或者至少你的 Discourse 网页界面用户与请求支持票证的用户之间不会有重叠。”
但这个话题确实解决了一个主要问题：“你看了一下安全/权限系统，但找不到你想要的东西：基本上纯粹的创建和创建/回复权限不存在。”我将在下面回到这一点。
解决方案 #3：群组收件箱。
Sam 的原始想法“将 Discourse 用作私有电子邮件支持门户”演变成了群组收件箱。你设置一个群组收件箱，将其分配给你的支持团队，然后任何人都可以向该收件箱发送消息或电子邮件。
这现在是首选解决方案，而且有效。
然而，我不太喜欢它。
在我看来（！），这种方法有几个缺点，其中三个主要缺点是：
- 发送到支持组的消息很难找到（实际上，在我看来，如果你没有可以点击的通知，所有消息都很难找到），并且虽然支持人员有良好的概览，但用户没有。工作人员处理工单的用户可以看到一个单独的群组收件箱，而创建工单的用户只能在他们的“常规”PM 中找到它们。
- PM 中缺乏标签支持：只有工作人员可以标记 PM，用户无法查看或按标签过滤。
- 没有一个可以发送消息的“地方”。必须明确地在某个地方宣传与支持团队通信的可能性（我发现很难找到一个合乎逻辑的地方，大多数情况下它最终会出现在某种横幅中）。
总而言之，对我而言，它感觉有点“附加”，是类别主题和 PM 之间的折衷。
#4 私有主题
这个想法已经被提出过几次（也在这里 在这里 和 在这里），并且我已经提到了上面的“创建”和“创建/回复”权限。
如果有一个“投递箱”类别，人们可以在其中发起一个主题并与支持人员（基本上是一个组）互动，并且只有他们和该组成员可以看到该主题，那会怎么样？
这将是这个用例的万能药。我们将有一个明确定义的“支持”类别，每个用户都可以看到他们（仅他们）的支持工单。一切都在一个地方，你可以使用标签等。
但是 @codinghorror 和 @sam 都多次告诉我们，特定于主题的权限不会实现（我完全理解，因为它增加了很大的复杂性）。
我认为有两种前进的方向：使用 #3 群组收件箱并希望这些缺点得到解决，或者再次尝试 #4 私有主题的想法。
与此同时，出现了一些（搞乱实现每个主题权限的）插件，例如 Restricted Replies - 只允许某些组在一个类别中回复，以及 Discourse Private Replies，它使得回复对除主题发起者（和工作人员）之外的任何人不可见……这似乎是可行的……所以我一直在考虑在插件中再次尝试这个。
但是。
在我继续之前，我想听听
- 是否有其他人对群组收件箱的看法与我相似，因为我知道这些感知到的缺点可能非常主观。
- 关于私有主题插件想法的任何（！！）反馈
24 个赞
Heliosurge
(Dan DeMontmorency)
4
这确实是一个很好的讨论话题。
也许可以或许私信回复，以实现你的想法。但这需要有人了解他们在做什么或在讨论什么，或许可以与插件作者合作，进行一次赞助的插件分支。通过赞助，这将是探索众筹概念的一种好方法。
群组邮箱是个好主意，但恕我直言，私信系统需要有一个易于使用的搜索选项，或者带有文件夹选项的群组书签。例如，客户A 2020年10月的请求。
7 个赞
在不了解原始上下文的情况下，特定主题的权限似乎比实现 #4 所需的更广泛（正如你所说，也更复杂）。
我的设想是，通过扩展类别权限来包含“仅查看自己的”。与现在的权限类似，必须允许已添加组的“查看”或“仅查看自己的”之一。
允许创建会自动允许回复，而“仅查看”会自动允许创建——一个只能查看自己主题的类别，如果不能创建主题，那将毫无意义。
我认为这在权限方面“只需要”两个额外的更改。当当前用户所属的组只提供“仅查看自己的”权限时：
- 主题列表应过滤为当前用户创建的主题
- 除非主题是由当前用户创建的，否则应拒绝访问主题
我怀疑实际上在处理类似“最新主题”列表时存在额外的复杂性，但这可能（也许……）不是巨大的额外工作。
我们目前不在 Discourse 中提供私密支持，所以我没有第一手经验，但我认为我自己的看法与你的看法一致。
可发现性很重要，无论是找到在哪里寻求支持，还是查看当前和过去的支助查询，使用群组私信方法似乎都可能面临挑战。
7 个赞
RGJ
(Richard - Communiteq)
6
感谢您的反馈！我恰好是该插件的作者，我们（Communiteq）如果觉得这是正确的方向，愿意投入资源。所以这些都不是问题。
是的，听起来是这样。
但我仍然在努力理解这具体将如何构建，因为“仅查看自己的”意味着“创建”，“创建”意味着“回复”，而“回复”意味着“查看”。
但我们不希望“仅查看自己的”意味着“查看”。
8 个赞
是的，这似乎比我想象的要棘手。看起来回复实际上并不意味着查看，而是将一个组添加到类别权限中确实如此。
权限是一个枚举，其中一个组恰好具有 readonly、create_post 或 full 中的一个。要找出用户是否可以在给定类别中回复/创建，就需要获取用户所属的组在（create_post 或 full）用于回复或（full）用于创建主题的类别列表，并检查相关类别是否在该列表中。
创建主题很容易，在枚举中添加一个额外的值，如 full_own，只需将其添加到 category.rb 中的 TOPIC_CREATION_PERMISSIONS 常量即可。如果用户对于相关类别具有 full 或 full_own，他们就可以创建主题。
回复更复杂，但我认为添加一个额外的范围来返回用户具有 full_own 的所有类别是合适的。类似这样：
OWN_TOPIC_POST_CREATION_PERMISSIONS ||= [:full_own]
scope :own_topic_post_create_allowed, -> (guardian) { scoped_to_permissions(guardian, OWN_TOPIC_POST_CREATION_PERMISSIONS) }
然后在 post_guardian.rb 中，can_create_post? 需要一个额外的条件，如下所示：
(!SpamRule::AutoSilence.prevent_posting?(@user) || (!!parent.try(:private_message?) && parent.allowed_users.include?(@user))) && (
!parent ||
!parent.category ||
Category.post_create_allowed(self).where(id: parent.category.id).count == 1 ||
(parent.is_my_own? && Category.own_topic_post_create_allowed(self).where(id: parent.category.id).count == 1)
)
然而，只查看自己的主题并保证在相关类别页面、最新、搜索和任何其他地方都是如此，这看起来更具挑战性。我还没有弄清楚。
6 个赞
我认为这里最容易实现的目标是第三项，即改进群组收件箱，使其能够很好地为登录用户提供支持，而不仅仅是为通过电子邮件寻求支持的用户提供支持。
您对群组收件箱的主要抱怨似乎是用户端功能不足，如果您的用户登录是为了跟踪工单，并且还使用私信与其他网站用户交流，那么这是合理的。到目前为止，在我们使用群组收件箱在此元论坛上提供支持的过程中，我还没有遇到这种情况。我们通过群组收件箱提供支持的大多数用户从不登录——他们主要使用自己的电子邮件，因此可以使用他们的电子邮件来根据需要组织和归档与我们的通信。
我确实通过元论坛上的 @support-teams 与一些用户进行交流，所以我会问他们这对他们来说效果如何，以及他们是否有任何建议。我还会自己进行更多测试，看看它现在实际是如何工作的。在我看来，这个请求是：
- 允许非工作人员用户查看消息标签（目前只有工作人员可以看到标签。也许我们可以为此使用标签组，提供一些非工作人员可以在消息中看到的标签？
）
- 当用户向群组发送消息时，在消息菜单上为用户提供一个指向群组收件箱的链接，以查看自己与群组的消息（这对工作人员来说已经可以了，我不确定这对非工作人员来说是如何工作的。收件箱和存档存在一些问题，这些问题不是单独针对每个用户控制的）
- 提供一个链接来开始向群组发送新消息（我认为如果允许向群组发送消息，这个链接会出现在群组页面上）
即使是我，作为 @support-teams 群组的成员，为 Discourse for Teams 提供电子邮件支持，也注意到这一点，即开始向群组发送新消息的能力。如果我想从支持团队开始发送新消息，我必须同时包含支持团队和我想写信的人的电子邮件地址。这有点笨拙。
此外，我们使用群组收件箱的方式是，我们通常不会像处理主题那样关闭已解决的消息。我们只是存档它们。这使我们可以在消息已解决时将其从我们的视野中移出，同时也允许客户通过电子邮件跟进并将消息移回收件箱。
5 个赞
这是一个非常有趣的观点，我之前并没有真正考虑过。通过电子邮件支持，客户很常见地会找到旧邮件并回复它们，而不是发送新邮件。如果一个主题被关闭，当他们的邮件被拒绝时，这充其量会令人困惑。
在第 4 扇门后面，无论以何种方式实现，如果无法关闭主题，那么在员工方面可能很难识别未处理的主题，尤其是在支持人员数量增加的情况下。已解决插件在这里并不能真正起到作用，因为客户可以回复一个旧主题，而不同的支持人员将不知道它是否需要关注，或者另一名员工是否已经解决了它。
6 个赞
RGJ
(Richard - Communiteq)
11
我不确定修改 full、create_post 和 readonly 是否是正确的方法，因为在很多地方 full 和 create_post 都意味着“查看全部”。以这种方式创建可维护的插件将不容易。此外，我认为这不是很直观。
另外，如果主题作者能够为主题添加其他人（例如同事），例如通过提及他们，那就太好了，在这种情况下，这种机制将不足以满足需求。
目前我的想法是保持权限不变，并在安全组下方添加一个部分：
启用此类别中的私有主题
允许以下组查看所有主题 [x support staff] [x sales support]
我在私信插件中做过类似的事情，但那是针对主题中的帖子，而不是类别中的主题。
我认为通过对 TopicGuardian 进行一些修补，我可以取得很大的进展。
是的，这可能很容易解决。您对我的请求的总结是准确的，我发现还有两件事可以让消息与主题更加一致。
下拉列表中的项目部分与下一个屏幕中的选项卡相同，除了 Messages 和 Badges。所以当我需要去我的消息时，我总是点击 Summary，然后是 Messages。
比较下拉列表中的项目
与个人资料屏幕中的选项卡
Summary、Activity、Invites 和 Preferences 在两者中都有，但一个是 Drafts，另一个是 Notifications、Messages 和 Badges。所以“Messages”对我来说感觉非常隐藏（对于 Notifications 和 Badges 也是如此，但我并不经常使用它们）。
7 个赞
说得好。我不确定这道障碍背后的想法是什么。我也注意到，当你在收件箱中时，它确实默认添加了 in:personal，这很好！但它没有添加例如 in:support-teams 来仅搜索群组收件箱中的消息，我认为这会是个好主意。据我所知，高级搜索也没有简单的方法按群组收件箱进行过滤。（抄送 @pmusaraj）
这是一个好主意，但我认为那个下拉菜单的空间有限——你不希望那个列表有超过 7 个项目。此外，对于大多数社区，我认为我们实际上不希望推广消息功能……我们希望人们公开交流！对于那些通过消息交流的人来说，通知下拉菜单和电子邮件通知等提供了充足的即时访问需要处理的消息。
话虽如此，我们正在积极改进菜单系统（关键词：sideburger），因此会将这个问题考虑在内。Discourse for Teams 中的侧边栏已经提供了对群组收件箱和关注标签的即时访问，我们可以将其与 sideburger 项目一起引入到核心 Discourse 中。
这是我在我的 Discourse for Teams 网站上，位于 Kabissa 群组收件箱中的样子：
5 个赞
我想知道是否可以将群组指定为支持群组，并在汉堡菜单中根据此设置一个条目，并具有以下状态：
- 指定了 0 个群组，没有菜单条目
- 指定了 1 个群组，“发送支持消息”条目，该条目会启动给该群组发送消息
- 指定了 \\u003e1 个群组，“支持”条目，链接到一个类似于群组的页面，显示所有指定的群组并带有发送消息按钮
也许额外的菜单条目和页面是多余的。在“关于”页面上添加一个生成的附加部分？
这并不完全明显，但它在消息选项卡上，消息列表底部的向下箭头会带您到 /my/messages 屏幕。点击次数与“摘要”，然后“消息”相同，但少加载一个页面。
如果我是一个向 Kabissa 发送消息的用户，那么该主题是否主要与该群组相关联，或者该主题除了我的用户和允许访问的 Kabissa 群组之外，是否没有任何其他内容？
如果它确实主要与群组相关联，那么在我的消息页面上显示 Kabissa 收件箱是否可行，尽管显然只包括我能够访问的消息。
6 个赞
当我在这里的 meta 上测试时，通过创建一个 tl0 用户，我可以导航到 support-teams 组页面并选择“Message”按钮向该组发送消息。一旦我发布了消息，它就出现在我的已发送消息文件夹中。所以这虽然有效，但可能对某些情况来说有点太隐蔽了。您可以根据您网站的用途，随时将链接添加到汉堡菜单，或添加到您主页上的横幅等。所以我不认为这里还有什么需要做的了？
截图中的 Kabissa 收件箱只显示给 Kabissa 组中的人。给 Kabissa 发消息的人会在他们自己的消息中看到这些消息。
5 个赞
jomaxro
(Joshua Rosenfeld)
15
请注意，存在 in:all。它将同时显示公开消息和私人消息。
如果我没记错历史的话，这样做的目的是强制区分私人消息和公开主题。最大限度地减少关于什么公开、什么私人的混淆。话虽如此，群组收件箱在一定程度上模糊了这种界限。
8 个赞
我想到的是提高支持特定群组的可发现性。将链接添加到汉堡菜单确实适合拥有单一支持群组的社区（这实际上非常适合我自己的目的），但拥有许多支持群组的社区可能会受益于为指定群组生成的关于页面上的页面或部分。
回想起来，如果社区需要，这可能更适合插件。
我试图问的是，也许表达得不好，目前的模型是否拥有足够的信息，以便将来能够向用户显示他们与之互动但未加入的群组的过滤收件箱。这与 @RGJ 对发送到群组的消息难以查找的担忧有关。
例如，作为贵公司 Discourse for Teams 网站上的普通用户，我可以在我的消息中看到一个 Kabissa 收件箱，其中显示了我发送给 Kabissa 群组的所有消息。（或者可能是我参与其中的消息。）
我的怀疑是它没有，它可能只有参与者可以参考，而参与者可以是任何数量的用户和群组。
7 个赞
schungx
(Stephen Chung)
17
很高兴这越来越受欢迎！这是因为我认为 Discourse 是一个很棒的私有支持工单系统，而且当它正常工作时，它运行得 非常出色。
我完全知道这不是 Discourse 的设计初衷，而且我试图将 Discourse 强行用于它不应该做的事情，但介于私有收件箱与主题的全部功能和优势之间，我宁愿选择后者，并继续尝试强行使用……
4 个赞
这是我们希望支持的功能（无论是比喻意义还是字面意义），但我们不想被“挤压”进一个“支持工具”的角落。 
如果您对如何改进 Discourse 以更好地扮演此角色有具体反馈，请告诉我们。
我们一直在倾听 
8 个赞
jrgong
(jrgong)
19
这个想法太棒了！即使在我们的社区中，也有人要求将支持工单与他们的用户收件箱分开。这种用户只能看到自己工单的类别将非常有帮助。
4 个赞
jerry0
(Jerry)
20
谢谢！
我们使用私信群组进行私人支持——效果很好。重度使用支持系统的用户的主要抱怨是无法搜索他们的消息。
我们曾试图教他们必须在搜索查询中添加代码in:personal才能搜索他们的消息，但这并不直观，坦白说，我没有看到一个用户真正能够做到这一点，他们只是放弃并抱怨他们无法搜索他们的消息。
他们甚至不明白搜索框下方的这个“建议”是做什么用的。
如果他们进入高级搜索，他们可能足够高级，可以勾选“搜索消息”单选按钮，但当这会添加单词in:personal时，一切看起来都很奇怪，然后他们在那时就放弃了。
如果有一种更直观的搜索消息的方式，而不涉及在搜索框中添加代码，那将是一个巨大的改进。
如果没有，仅仅使用更直观的语言，例如代码“in:messages”，将是一个小小的改进。
6 个赞
jerry0
(Jerry)
22
确实如此——那将是极好的！
一个“默认搜索私信”的设置（通常是关闭的）将是理想的。
这样，用户对在普通主题和私信主题（我没有）的搜索结果之间混淆的任何担忧，都可以与人们根本无法搜索私信主题（我有）的担忧相平衡。
3 个赞
