管理员权限似乎将 server admin 角色与 chief moderator 角色混淆了。
我的问题基于我们的使用场景：IT 部门负责搭建我们的 Discourse 服务器实例，但并不负责或关心 Discourse 内部内容的运营或开发。
是否有某种方式可以将 server admin 应负责的功能（例如 SSL 配置）与 chief moderator 需要执行的任务（例如设置分类）区分开来？
例如，负责 SSL 设置的 IT 管理员甚至不需要 Discourse 账户，只需拥有服务器访问权限即可。此外，大多数与 IT 相关的设置可以通过在 app.yml 中配置环境变量来完成，从而无需让 IT 人员访问 Discourse 的 Web 部分。
这样一来，您的“首席”版主完全可以担任 Discourse 的管理员或版主。
谢谢 @Falco。
那么，是否可以在管理员权限内设置层级？例如，让 adminType2 能够执行 XYZ 操作，但不能执行 JKL 操作？
不，目前没有细粒度的自定义权限系统。
@Falco，这在我看来有些令人遗憾。
在“电子邮件”部分中，有一些字段是某些“服务器管理员”所关心的，而“首席版主”实际上并不需要这些。例如，电子邮件账户和密码、用于 POP3 轮询的端口号以及其他相关信息。
此外，还有许多其他“管理员”参数可能会影响服务器负载，我完全可以理解“服务器管理员”希望控制这些设置的需求。一个简单的例子就是图片和附件的最大文件大小。在仔细查看所有管理员选项后，我发现有大量设置应由“服务器管理员”而非“首席版主”来控制。
我提出这些问题的核心在于：面向公众的团队很容易受到后端团队的制约，尽管双方都有合理的顾虑。
是否存在某种“首席版主”模板，可以从管理面板中移除对某些参数的访问权限？
你可以将这些设置放在 app.yml 的 env 部分，这样它们就不会在用户界面中显示。
查看 使用对象存储进行上传（S3 克隆） 以获取示例。所有站点设置都可以通过这种方式被覆盖和隐藏。
感谢 @pfaffman。
我查看了关于外部存储的链接，但对于新用户来说有点令人困惑。
所以，据我理解，您的意思有两点：（1）管理区域中看到的所有设置都可以在 app.yml 文件中配置；（2）在 app.yml 文件中配置的选项不会在管理区域中显示。
是这样吗？
后续问题是：能否将当前的管理员设置导出到文件中，并将其整合到 app.yml 文件中？
看来您已经理解了。您需要手动生成环境变量值。