我并不同意。不过，一旦“特定人群”扩展到几百人的规模，你就会希望获得 Discourse 为浏览公开主题所提供的一些便利功能。因此，这里的关键区分点或许在于接收群体的规模？
1 个赞
你好，Geoff！希望一切顺利。
我也同样希望能看到“最新/热门/新消息”页面中的私信（出于完全相同的使用场景）。不过，就你提到的这一点（切换现有主题公开/私密的属性）而言，如果我的理解正确，该功能似乎已经存在。
通过右上角的主题级管理操作扳手图标，你可以点击“设为私信”（如果它已经是私信，则点击“设为公开主题”）。将现有主题切换为私信似乎会保留所有在该主题中发帖人员的访问权限，之后你还可以添加工作人员组。不过，这会将该讨论串从主题列表中移出，并放入消息部分。
是的……这就是问题所在。
我希望能有一个类似“隐藏”的功能，但能让该消息对所有具有特定信任级别的工作人员可见。这或许可以实现……
手动设置例如 trust_level_3 是否可行，让任何人都能向其发送私信（在“群组” → trust_level_3 → “管理” → “交互”中设置）？
这样看来，在将公开主题转换为私信后，您可以手动将 trust_level_3 群组添加为参与者。
这可能不完全符合您的需求（而且我不确定自己是否足够了解其内部机制，因此无法肯定地说这一定可行），但它或许能在一定程度上满足部分需求。
我也是后来加入讨论的，使用场景与 @Geoffrey_Challen 几乎完全相同（运营一个大型班级，希望利用 Discourse 来管理问答和讨论）。
我个人并不担心邮件数量过多（反正我已经设置为邮件列表模式），但我认为如果能从一个地方直接查看“有哪些主题可能需要我阅读或回复”，将极大地提升生活质量，无论这些帖子是公开的，还是发送给了工作人员组（甚至只是直接发给我）。
最初讨论过的“创建”权限是解决这一问题的一种方式。另一种方式是允许将某些组的私信（PM）在主题列表页面（如“新主题”、“热门主题”等）中渲染为伪分类。鉴于私信与公开主题在数据库结构上的相似性，这似乎或许可行（当然，这也会增加一定的复杂性）。
还有一种不同的替代方案，可能以类似的方式提供帮助，但不需要进行如此大规模的改动：如果搜索框能够支持同时搜索所有主题和私信（目前据我所知，我只能搜索其中一种，而不能同时搜索两者），并且最好能按特定的私信接收组进行筛选，那将非常有用。例如，我希望能够说：“显示所有未关闭的主题，无论是公开主题还是发送给工作人员组的私信。”
如果以这种方式修改搜索功能是可行的，那么它似乎能够提供我所期望的许多功能，而且无需对除搜索以外的其他部分进行改动。但也许那里也存在一些我尚未考虑到的复杂情况。
我认为这确实是问题的一部分。也许还与组私信与公开帖子的流量大小有关？我们的使用场景涉及大量公开主题和组私信的互动（两者都有大量主题），而对于许多其他使用场景，发送给工作人员的私信可能较为罕见，这或许会影响人们与这些内容进行交互的方式？
好的……今天下午折腾了几个小时后，我有了一个仅创建权限的原型（在 cs125 分支中，见 https://github.com/cs125-illinois/discourse）。虽然测试非常有限，但目前看来以下功能可以正常工作：
- 可以为分类分配“创建”权限。
- 拥有该权限的用户可以在该分类中创建主题，并回复自己的主题。
- 他们仍然可以“查看”其他用户创建的主题，但尝试访问时会返回“此页面是私有的或……
这几乎与“限制回复”插件的工作原理完全一致。
唯一无法处理的是第 3 点。由于上述所有原因，实现这一点将非常棘手。
[quote=“david, post:73, topic:33150”]
尝试按话题修改查看权限非常困难，且不太可能实现。这是因为这需要对整个应用程序进行大量更改，包括话题列表、推荐话题、通知等。如果你需要按话题修改查看权限，请使用私信（PM）。[/quote]
3 个赞
如果我理解有误请纠正，但看起来您的插件并不能阻止用户_查看_他们未创建的帖子。这对我们的使用场景至关重要：学生在我们的课程论坛中发布问题，其中可能包含代码或其他解决方案部分。因此，我们不仅需要只有工作人员才能_回复_，还需要只有工作人员才能_查看_。“限制回复”插件声称其权限模式为“创建/回复（仅自己）/查看”。我们需要的是“创建/回复（仅自己）”，但_不_包括“查看”。
尽管如此，能够通过插件实现这些功能确实令人鼓舞。是否有可能也限制查看权限，以支持我们的使用场景？
关于第 3 点：我在想是否在前端实现会更简单。目前，经过我们的修改，学生根本无法进入这些主题，因此，即使我们只需在 UI 中隐藏它们，也足以满足需求。
是的，你说得对。这就是为什么我说它无法实现（3）。
如果某位用户正在关注该分类，并收到关于秘密主题的通知我该怎么办？邮件列表模式呢？用户的“活动”页面呢？“热门”主题呢？“最新”主题呢？搜索功能呢？可能还有许多其他问题……这是一项巨大的工程，我不推荐这样做。
群组私信正是为你们的使用场景而设计的。我们在 Meta 上通过群组私信处理所有支持邮件，效果非常好！如果你在群组收件箱方面遇到具体的可用性问题，那么我认为你最好将精力投入到探索如何改进这些功能上。
3 个赞
我并不同意你的观点。但我们之所以在这里，是因为我们尝试过群组私信，但效果并不理想，毕竟我们有大约 200 人接收这些消息。
我在回复 Sam 时已经提到过这一点，但一旦收件人列表变得非常大，群组消息似乎就不太有效了，而我回复每条单独消息的可能性也会降低。换句话说：如果群组消息真的那么有效，人们就不会继续使用大型公开邮件列表，而是会采用 Discourse 这样优秀的工具。
我们可能会继续使用群组消息，以避免你正确地指出的、修改类别权限可能导致的破坏风险。但是，当你的实际体验是群组消息并不像宣传的那样有效时，被告知“群组消息效果很棒！”确实没什么帮助 
2 个赞
没错，不同社区的使用方式总会有差异。我的意思是，探讨一下需要哪些功能改进，才能让私聊（PM）真正发挥作用，会很有趣。我认为这方面的改进比在普通分类中重新实现私聊功能要可行得多。
你在群组私聊中遇到了哪些具体问题？举个例子，是不是通知过多？这原本也是我们遇到的问题之一，现在你可以为每个群组收件箱配置跟踪级别了。
6 个赞
是的，这确实是一个非常有用的补充！谢谢。
如果你查看上面的一些讨论，你会发现私信系统存在一些问题。主要是，处理消息的工作流程不同，导致主题之间产生了人为的割裂，而我希望以类似的方式处理这些主题。（因此，我们尝试将其附加到现有的分类权限模型上。）
这里有一份列表，但归根结底，就是让消息群组尽可能像分类一样。将它们放在首页和最新主题视图中，浏览时外观一致，提供相同的搜索和过滤选项（无需记住这是消息）等等。不幸的是，我的感觉是，这需要与新增分类权限一样多、甚至更多的破坏性改动。但也许并非如此？
@david：抱歉打断大家的讨论，但我有一个与 @Geoffrey_Challen 非常相似的使用场景。虽然我不能代表他发言，但我觉得有一件具体的事情能切实帮助到我：希望能有一个选项，允许在单次搜索查询中同时匹配公开话题和私信（目前看来我只能搜索公开话题或私信，无法同时搜索两者，除非我遗漏了什么）。
我理解这里提到的其他一些改动（如“创建”权限、允许私信显示在常规话题列表中，等等）涉及广泛且复杂的变更，但或许对搜索功能进行一些调整，使其能够跨所有话题（包括公开话题和私信）进行搜索，会更加务实且改动范围更集中。这样，我们仍然可以通过搜索获得某种统一视图的雏形。
就我个人而言，我认为覆盖默认界面并不重要，但如果我能有一种快速回答“我现在需要回复的所有线程有哪些？”的方法，无论这些线程是公开的还是私密的，并能根据标签等进行筛选，那将非常棒。
目前，我写了一个小脚本，可以直接从 Postgres 数据库中获取这种统一列表；或者我也可以通过搜索对话框为每个需要搜索的内容运行两个独立的查询（一个针对公开话题，一个针对私信）。但这两种方式都有些令人头疼……
2 个赞
这听起来是个很棒的主意——我会很乐意使用这个功能。最好的做法是创建一个新的 #feature 主题，这样我们就能在这个主题中追踪这个想法，而不会弄混。
编辑：已完成，见此处
4 个赞
我真的很难理解，为什么自2015年讨论以来，大家一直反对允许这种权限结构。我完全能理解原帖（OP）的吸引力，同时也理解大家对将其作为私信替代方案的顾虑。如果权限能稍微细化一些，那将对 Discourse 带来巨大的变革——它将打开许多大门，让社区能够实现更多富有创意的用法。
细粒度权限的影响……已有详尽的文档记录。我至今仍因 vBulletin 出于同样原因将分类权限搞得一团糟而做噩梦。
关键在于，如果你希望用户能够创建主题，且仅能看到自己创建的主题，那么这一功能在私信中已经存在。结合群组邮箱，它已能复现所需的预期行为。
1 个赞
我个人对 vBulletin 或其他论坛软件没有任何使用经验。我在社区类平台方面的经验主要来自 Discord，在那里社区创建者对权限拥有更多控制权。我也见过许多其他系统成功实施了权限系统，允许更精细的控制。我认为没人要求在这个场景中设置 500 个切换按钮，而是希望能够独立地分配“创建”、“查看”和“回复”权限。
用户期望的行为是：打开一个分类，点击“新建主题”，输入内容，然后他们的帖子仅对自己以及拥有“查看”权限的人可见。相比之下，私信在导航上对用户来说要繁琐得多——它们需要用户更多的主动操作，而且该功能在界面中埋得更深。
一个更简单的解决方案是允许通过电子邮件创建主题，但这也有缺点。它不能直接促进社区参与，而且要求用户使用第三方系统来实现目标。
私信和分类权限是两个不同的议题，既不是原帖作者（OP）所请求的内容，也不是许多后续用户将会关注的重点。