继续讨论 我如何创建悄悄话帖子？：
悄悄话可以像新开发的群组特定预设回复功能一样进行扩展，也允许使用多个悄悄话（特定于某些群组）。
示例：
我们有一个 @documentation-group，它可以使用悄悄话，而无需访问管理员悄悄话。
允许一个以上的悄悄话部分会很有用。无论如何，感谢您的考虑。
3 个赞
7 个赞
不知道在过去的两年里，你们团队是否讨论过这个问题？ 
我们开始整合其他团队到该平台，他们希望使用私信功能，但我们不希望他们看到我们的管理员私信。
1 个赞
我担心当我提出这个问题时，它被认为是VeryComplex™，到目前为止并没有引起太多兴趣。
1 个赞
此功能请求可能作为替代方案引起您的兴趣
它很相似但又不同。我认为我们不希望另一组在任何情况下都能看到我们的管理员耳语。这里有一个小可视化，希望它有帮助——可以将其视为耳语的层级：
- 管理员耳语，只有管理员能看到
- 内部团队的耳语；管理员也能看到
- 外部用户看不到任何耳语
1 个赞
如果 bbcode 插件或主题组件不会影响耳语。
在我提供的链接中，您将可以在帖子中获得额外的代码，只向所有人显示帖子的一部分，而隐藏的内容仅显示给楼主和目标组。
现在，除了工作人员外，其他人无法查看帖子修订。
类似 bbcode 的解决方案的想法是允许您将帖子中的内容隐藏给另一个组。一个例子是桌面角色扮演游戏。但是，聪明的用户可以通过检查元素来查看并更改 CSS。
我认为#feature request非常清楚，我们应该注意不要将所有内容都视为#support主题，并深入研究变通方法。让我们试着保持专注。
2 个赞
您是在设想内部团队 A 可以看到内部团队 B 的悄悄话吗？
还是说每个内部团队只能看到自己团队的悄悄话？
还是说某个悄悄话需要以某种方式定义其接收者？
何时会选择使用悄悄话而不是私信来管理接收者？
（回复 @putty 的队友）
理想情况下是后者，但我意识到将不同用户分组可能会非常复杂。想法是，我们公司有许多内部团队现在也希望在我们的 Discourse 上为他们的用户构建体验。感觉就像我们建立了一个父社区，但他们也在其中构建了迷你社区。
因此，许多团队对在他们的群组收件箱和类别中使用悄悄话功能感兴趣。当然，问题是我们不希望他们看到管理悄悄话。
1 个赞
好的，我明白了。
这确实棘手。悄悄话本身已经是一种有点危险的工具，因为能看到悄悄话的人必须在两个层面上理解一个话题，一方面要费力地从公众的角度去看，另一方面还要看到包含悄悄话的特权视角。
我认为再增加一个层级可能会让大多数人感到过于困惑。我承认电子邮件基本上已经提供了这种自由，因为许多客户端会显示一个单一的线程，而不考虑在过程中谁被添加或删除到抄送列表中。但我也看到这会导致我想要避免的那种困惑。
我认为一个可能恰到好处的折衷方案是，将悄悄话的可见性设置为一个类别级别的配置。例如：
- 在类别 A 中，X 和 Y 小组可以看到悄悄话
- 在类别 B 中，Z 小组可以看到悄悄话
在这种模式下，X 和 Y 仍然可以在 A 中看到管理员的悄悄话。但我认为你可以定义类别和规范，使其能够正常工作，而不必在单个主题中添加第三层悄悄话。
2 个赞
关于 @putty 所描述的：
- 管理员私聊
- 私聊
这个想法，您怎么看？这会是一个很好的折衷方案，因为至少在我们的实例中，“所有其他私聊”中的每个人都将是同一家公司的员工。我在这里大胆猜测一下，但我觉得我每天都在学习这个平台的复杂性：我假设如果这是配置方式，它是否会（至少在某种程度上）比允许单个群组控制谁可以看到他们的私聊更简单？
这将使公司全员能够跨类别、主题或私信在社区中相互私聊。现在仔细想想，这听起来确实很棒。这太棒了！
1 个赞
是的，我也不确定最终哪种实现和配置会更复杂。不过，我仍然担心在同一个主题内会有第三层讨论。
不过，你今天就可以做到，对吧？只要你也能让所有员工看到管理员的私下消息，那就行。
你是否可以考虑接受这个限制？
在哪些情况下，你需要管理员能够私下交流，而其他所有员工都看不到？而且，如果你允许其他员工互相私下交流，你难道不想让管理员也能和其他员工私下交流吗？那会如何运作？
也许在“所有员工都可以互相私下交流”的模型中，管理员在需要私下交流时应该使用不同的工具（例如私信或仅限员工的类别或聊天频道）。如果可以接受，你今天就可以做到。
3 个赞
不幸的是，我们有时也需要管理我们的内部用户！当您的规模变得如此之大时，会出现同样适合管理员之间私聊的场景。如果您有兴趣，我可以在私信中告诉您更多关于这个用例的信息。
是的！
- 管理员可以看到/回复/创建管理员私聊
- 管理员可以看到/回复/创建普通私聊
- 员工可以看到/回复/创建普通私聊
- 员工不能看到/回复/创建管理员私聊
例如，管理员会看到这个：
员工会看到这个：
这些只是一些拼凑的截图，但我认为这能说明要点。
4 个赞
是的，我认为这就差不多了。
我仍然对这里的价值/复杂性权衡表示怀疑，但我现在明白了，增加一种额外的耳语类型将如何实现你现在的要求。
考虑到系统的现有限制，你会选择允许所有人耳语并为仅限管理员的对话使用其他解决方案吗？还是你会选择将耳语仅限于管理员？
2 个赞
目前很难决定。我一直要求我的团队遵循的理念是，做对用户最有利的事情，而不是对我们最容易的事情，因为这最终也会对我们最有利。
有了这个理念，我猜我可能会让所有人都可以私聊，让我的团队将管理对话转移到Slack，或者在通知问题修复后转移到聊天。这并不理想，并且剥夺了版主/管理员的私聊功能，但它确实能让我们继续发展社区。
2 个赞
+1 此功能！
在我们的案例中，我们有一个由作者和其他贡献者组成的非版主团队，我希望让他们可以选择在特定类别中进行耳语，而无需让他们看到员工/版主的耳语。
3 个赞
它不安全。而且狡猾的用户可以规避它。
但是，如果当前用户不是工作人员，可以使用 CSS 来隐藏工作人员创建的耳语的主题组件呢？至于某些类别。
如果不是您想允许他们使用的类别，可以使用类似的逻辑来处理齿轮菜单中的耳语切换，以便不为该组显示耳语按钮。
工作人员组需要知道不要分享真正敏感/安全需求的东西。
类似这样的东西可以作为一种有待改进的临时解决方案。
嗯……怎么规避？
只要这是在后端实现的，流式传输到客户端的帖子将取决于用户特定的授权。
“非管理员的耳语”将不包含在发送给非知情者的序列化信息中。
如果实施此功能有任何障碍，我认为这不是其中之一。
2 个赞
我只是在主题组件中使用了一个简单的 CSS。
这是否需要一个插件？如果我的逻辑有误，我深表歉意。
不过，你对这些事情的理解比我深刻得多。但如果可行的话，听起来很酷，因为在这个话题的早期，有人说由于复杂性，无法创建单独的耳语。
我得出这个结论是基于另一个话题中的想法，即使用通用的 bbcode CSS 来仅在帖子中显示隐藏内容，以针对特定用户或群组。
1 个赞