JammyDodger
我不这么认为，但这确实是个好建议 
11 个赞
我认为我们也应该有一个设置，允许某些人给你发送“喜欢”，就像主网站上的私信一样。
2 个赞
3 个赞
我同意。我认为我们可以直接使用现有设置，并在必要时更新文案。我看不出有任何令人信服的理由要为聊天和非聊天直接/个人消息设置不同的选项。
5 个赞
有些用户（包括我）可能不希望收到用户之间的聊天消息，但可以接受接收个人消息。
事实上，我将完全坦诚地说，如果无法单独禁用它们，我将不会在我自己的实例上使用此插件。
5 个赞
我也差不多。我想我以前说过，我非常喜欢在私人话题上使用端到端加密，并且害怕私人聊天被解密，所以我可能会保持启用私人话题，并禁用私人聊天，直到私人聊天也支持端到端加密。
2 个赞
啊，我一开始的想法正好相反：“如果我已经限制了谁可以给我发私人消息，我可能不希望那些不能给我发私人消息的人通过聊天直接给我发消息。”
在你的情况下，有没有什么情况是你希望允许一部分可以给你发私人消息的人给你发聊天私信的？还是你总是希望阻止所有人给你发聊天私信？
这一点我完全同意。我有一个作为版主的实例，由于性格冲突，我不得不应管理员的要求屏蔽某些用户，所以我绝对不希望他们能够发起聊天。
这实际上有点复杂，因为它取决于具体实例。
在一个我担任版主的实例中，我们签署的官方版主协议规定，我们不能使用任何聊天平台与用户进行一对一的关于版务问题的沟通。所有事情都必须通过私人消息完成，并且必须包含版主组。在这种情况下，能够禁用聊天但保留私人消息功能实际上很重要。
在那些我只是普通用户的实例中，如果有人特别烦人，我完全可以屏蔽特定用户。
老实说，我理想中的情况是拥有单独的屏蔽列表，但作为开发者，我讨厌添加大量额外代码来支持这一点，因为很可能如果有人不想接收用户之间的聊天，他们也不想接收来自那个人的私人消息。
3 个赞
对于该论坛，将整个站点的用户间聊天完全禁用是否有意义？
我正在回顾这个话题，我认为这就是我们需要开始的地方。我会更进一步，认为该页面上所有相关的设置都应同样适用于聊天。（忽略和静音用户，以及直接消息和个人消息的允许列表）。
稍后可能会添加聊天的其他设置，但我认为首先阻止聊天成为这些设置的漏洞（可能除了忽略？）很重要。
3 个赞
我们应该做的一件有趣且非常正确的事情是确保聊天插件更新所有描述以匹配新的现实。
它是“禁止所有通知、私人消息和直接消息”等……
我想知道新的描述文本是什么，以及我们是否可以足够宽松地覆盖核心，或者我们需要覆盖它？
2 个赞
只是一个更新，我们已做出以下更改，因此现有设置现在也适用于聊天：
6 个赞
完美！只是为了澄清，这是否同时适用于全站设置和用户特定设置？
1 个赞
目前，它仅适用于用户特定的设置。这是否能满足您在此案例中的需求，或者您的情况是否可以通过站点范围的设置得到更好的解决？
1 个赞
我们受到美国证券交易委员会（SEC）的监管，因此出于法律原因，我们已为整个网站禁用了私人消息功能，因此我们需要在个人之间的聊天消息也应用该设置后才能使用它。
8 个赞
好的，我们已将此设置也应用于聊天的功能列入计划，一旦可用，我将在此处通知您！
6 个赞
同样，我有一个教育客户，他热衷于在类别/群组设置中探索聊天，但不能冒险启用一对一消息传递。
6 个赞
我现在使用的“hacky”方法是使用 CSS 来隐藏所有非员工用户的“新 DM”按钮：
body:not(.staff) button.new-dm {
display: none;
}
这很容易被有知识的人（或在这里 Meta 上搜索过的人）绕过，但对于那些在禁用选项被更正式地集成之前需要立即解决问题的人来说，这可能有效。
2 个赞
是的，我同意，这正是我所指的：
1 个赞
我认为“Chat”（聊天）和“Message”（消息）有些冗余。当然，它们的实现方式有所不同。但归根结底是一回事。我想这取决于论坛管理员决定允许两者都使用还是只允许其中一个。如果我的论坛启用了该插件，我个人只会允许使用 Chat。因为 Message 也有输入指示器，并且在帖子中。所以，我个人看不到区别。我认为看到两种方式可以向某人发送私信，对于 Discourse 的老用户和新用户来说都会感到困惑。而且，当您需要查看与某人的聊天记录时，现在必须在两个部分检查？
所以我支持选择。如果管理员想禁用 Message，或者禁用 Chat 进行一对一通信，那将非常受欢迎！
啊，这已经可以通过管理员设置中的 enable_personal_messages 来完成 
2 个赞