我明白它是如何相似的，但另一个讨论中的问题与这里的问题有关：
除了管理员之外，你无法看到一个链接到你通常无法访问的机密对话实际上是禁止的。这只是一个（昨天发生在我们身上并促使我开始这个话题的）例子，其中管理员和参与者的非分离可能会有问题。
此外，我看到 Discourse 团队有全员管理员的习惯，这是一种横向的超级大国，并且在文化上无助于区分正常使用和特权使用。并非所有社区都是横向的，有时拥有管理员权限的技术人员不应被信任论坛上的一切，这不是一个极端情况：自计算机系统诞生以来，root 就可以看到和做任何事情。特权当然伴随着责任，但有时仁慈是不够的，尤其是当一个人无法区分可以和不可以的时候。
虽然“使用另一个浏览器配置文件”的解决方案可以处理普通账户和管理员账户，但它并不实用，尤其是当我们都习惯于随时可以使用工具时。每次需要管理员功能时都启动一个新的浏览器可能会非常烦人（并非所有人都喜欢或能够承受在他们的机器上占用空闲资源）。它也不能阻止窥探的“Bastard Operator From Hell”（BOFH）情况发生。
时代在变。在这里，我们有一位管理员意外访问了影响他人生活的机密信息，而他们本不应该这样做。这是隐私泄露。这是一个安全问题。
我理解潜在的复杂性，但核心问题仍然存在，并且应该以某种方式解决。在我看来，随着代码库的成熟，现在重新审视这个问题并评估所提出的方法是否可行将会很有用。
是的！关于这种（侵入性）问题的警告和保护措施将会很有用。
关于现有插件：
- GitHub - discourse/discourse-anonymous-moderators 可能有用，但最近处理电子邮件的更改（https://meta.discourse.org/t/enabling-e-mail-normalization-by-default/338641）可能会改变这一点——依赖于无默认设置可能会有问题。
- GitHub - discourse/discourse-staff-alias: Allow staff users to post under an alias 仅限于 发帖。
鉴于上述所有原因，我宁愿使用经典且众所周知的 sudo 隐喻，在参与者和管理员之间实现真正清晰的分离。