这可能是社会和/或文化原因，我因此分享我的想法——不评判任何人。
有些人生活在对变革持抵制态度且完全受审查的国家（因此他们可能会将直接从不同视角或文化攻击自由的某些事物常态化）。
但 Discourse 希望成为全球顶级的论坛平台，我认为讨论这类话题对每个人来说都是有益的。
感谢提供这个空间。我希望它能被重新审视，既不损害使用场景，也不损害用户和社区对 Discourse 的信任 
1 个赞
我们讨论的是防止大型社区最终出现非常糟糕的用途，而不是损害用户对 Discourse 的信任。
我们不是在谈论盲目论坛或阻止管理员拥有数据，因为从使用单个数据库的集中式数据库来看这是不可能的。
我认为这个问题非常适合归入“是，但是”的讨论，而不是“是或否”的辩论。
抱歉，但这并非我话题的要点。您可以另开一个话题，随意提问。
我认为你没领会我的意思。这正是这个话题的重点。
移除模仿功能并不能阻止这种情况，没有它同样很容易做到。移除模仿功能的主要影响是使排除特定账户的问题变得更加困难。
8 个赞
我没有。手动管理数据库与点击发布是完全不同的。
这在默认的 Discourse 实例中是启用的，没有明确的声明或通用的用例，除了开发人员测试。
这就是我帖子的重点。再次抱歉，但你可以开另一个帖子，或者随便你怎么想。
你应该启动一个演示并尝试一些管理员功能，你不需要数据库访问或冒充他人来更改某人的话或阅读他们的消息。
2 个赞
如果只需要单击一下，或者需要单击十几下，这之间的差别不大，它仍然是可行的。我知道有人经常在家工作，他需要通过大约半打的密码、双因素 ID 和其他繁琐的步骤才能进入他公司的内部系统，但这只需要几分钟就能完成。
要么你和你的用户信任开发人员和管理员，要么你不信任。如果你不信任该系统，那么你使用它的方式可能会改变。
当然，这是从你的角度来看
从我的角度来看，这可能证明了 Discourse 考虑了隐私和自由。
手动管理数据库对于开发人员来说是可以的。为每个管理员提供一个模拟按钮是不必要的，也是不合适的。
中间可以有一个简单的系统，以透明的方式显示模拟功能的使用情况，或者类似的东西。
我的意思是，你可以考虑其他选项，或者将整个问题局限于你自己的视角。
在你再次回应之前，你需要回顾我最近的几篇帖子，管理员仍然可以做到这一切，而无需冒充或访问数据库。冒充和大多数管理员操作都已记录在案，以防其他管理员需要追踪恶意管理员的踪迹。
7 个赞
或者干脆用加密插件关闭那个开放的功能。归根结底，为人们可能觉得有问题的功能提供选项是一件好事。虚假的安全感、保障等。唯一安全的系统，引用阿达玛的话说，就是一台不与任何其他系统联网的离线终端。
所有支持和反对的观点都有其合理的立场。妥协是所有各方的最佳解决方案。加密插件的开发是为了满足人们的愿望，并在某些地方可能需要为私信/直接消息子系统提供一层隐私保护。
也许如果不是作为核心选项，那么可以开发一个插件来实现那些想要安心的自托管系统的期望效果。
有人可能会说，制作自定义徽章的脚本不需要禁用，因为只有管理员可以直接访问制作它们。然而，除非有变动，否则这必须从根用户启用。
我同意在理想情况下，人们应该能够信任处于职位上的人。不幸的是，信任有时会被误置，直到发现时才知晓。
1 个赞
这是一项性能措施，用于确保共享环境中的托管客户不会拖垮彼此的网站。它使得区分服务器管理员和论坛管理员成为可能。
1 个赞
单击一次或单击十二次似乎相似，但并非相同，因此许多公司因未能启用一个简单的按钮“取消订阅我”而损失了很多钱。
我们可能在谈论相反的情况，但从道德和伦理的角度来看。
我从四年前就开始使用 Discourse 作为管理员，我知道你在说什么（与冒充用户完全不同的情况）。
你说的不能通过一次点击就能像另一个人一样发帖。这就像使用第三方 IP 或 ID，与编辑他们的帖子进行审核不同。
顺便说一句，我希望加密能够停止并打破读取用户私信的可能性，但这属于另一个话题，我正在等待更新进行测试
1 个赞
我将再次引用这句话，因为看起来你已经添加了慢速模式……
我一直在考虑一些关于“更改所有权”和/或“编辑你的帖子并隐藏修订”的实际示例，以证明这主要是关于用于让你看起来说了你没说过的话而无需触摸冒充按钮的方法的无意义的争论，但我已经决定不这样做。
但是，仅凭 UI 中的所有魔法按钮，我就可以成为一个彻头彻尾的混蛋，更不用说玩转 rails 控制台了。我认为很多都取决于社区的信任，而不仅仅是管理员，因为许多这些功能在 TL4/catmod/mod 级别也可用。我认为总的来说，“员工”组通常不会竭尽全力破坏任何工具，因为这将是对他们自己社区的自我破坏行为。
因此，我不知道为什么冒充功能本身被单独挑出来说它不道德？
但让我留下这个……
3 个赞
说实话，所有这些声称滥用和其他东西的评论对我来说都没有意义，禁用此特定功能没有任何意义。管理员仍然可以像其他人指出的那样做任何事情。
但是，您仍然不想听取他人的意见，并且想小题大做。我仍然不明白真正的问题是什么。您会失去您的用户吗？还是您担心您的其他管理员会滥用此功能对付您？如果是这样，那么您就不应该信任您不信任的管理员，就是这么简单。
理查德，我将坦诚地说，你和@merefield都有非常有效的积极用例。但我认为你们俩都只看到了更改带有可选设置的元素会如何阻碍你们的工作流程。实际上，这并不会，因为如果你提供托管服务，这个功能对你们俩都不会改变。
除非，例如，我发布了一个我需要帮助解决的问题，并附带了金钱补偿或免费的协议。你、罗伯特或任何提供帮助的人都可以列出自托管 Discourse 所需的工具。
例如，“丹，我可以帮你解决你的问题，费用是 X 美元。我需要以下工具。在你的网站上创建一个账户并授予管理员访问权限，我还将需要访问‘模拟’功能（并提供一份允许使用该功能的用户名列表，以便我能够正确有效地诊断和修复问题）。如果你禁用了‘模拟’功能，你需要你的根管理员启用它。如果你同意我的条款，我们可以开始这个过程。”
我会自动化它，所以我一点也不担心（事实上，我有一个 shell 脚本，它接受我们托管的 Discourse 安装的主机名和用户名作为参数，并为我提供一个登录链接（包括 2FA 和登录）。
我已经解释了我的反对意见两个多小时前（但我很乐意重复它们，以避免进一步混淆我的动机）
1 个赞
我尽力手动总结我正在阅读的内容：
- 有些人希望提高冒充的难度
- 有些人希望保持当前低难度的冒充
对于那些希望增加一点难度的人（我属于这一类，因为我个人不想诱惑自己去点击按钮，类似于 iOS 上的屏幕使用时间和其他技巧，以帮助我避免诱惑）：
- 为您的网站添加一个非常简单的自定义主题组件，使用以下 CSS：
.btn-impersonate {
display: none;
}
也许您想要比这更大的阻力，也许有人可以制作一个插件或更高级的主题组件来实现这一点，但我想先尝试一下，看看它是否能提供足够的阻力来避免任何不必要的诱惑。
9 个赞
对我来说，这是主要问题。管理员仍然可以使用其他可用工具“冒充”用户，只需点击几下即可。
但归根结底，Discourse 是一个开源项目，带有一个插件系统，您可以始终让它以您认为适合您自己社区的方式工作。
如果您想要一个插件，我会从一个覆盖 Guardian.can_impersonate? 的插件开始，它由确定“冒充”按钮存在性的序列化器以及后端检查使用。至少根据我在我的开发实例上进行的快速测试，它有效：
# plugin.rb
after_initialize do
class ::Guardian
def can_impersonate?(target)
false
end
end
end
9 个赞
一个在某种程度上（在某种程度上）相关的话题，虽然它不是关于诱惑，而是关于在使用一个敏感功能时没有意识到我们在使用它，或者是不小心（阅读用户的私信）：Add a warning when checking personal messages from a user public profile, as an admin
我分享了两个经历，一个写在第一篇帖子中，另一个在这里：Add a warning when checking personal messages from a user public profile, as an admin - #11 by Canapin
4 个赞
……我不知道我可以如此轻松地从任何用户的个人资料中点击他们所有的消息……
是的，这是我喜欢 Discourse Encrypt 的另一个原因，并且希望它也能扩展到个人/私人聊天。
不过，作为管理员，我似乎无法轻松查看用户的私人聊天，是这样吗？
1 个赞