你好！
我想更改用户组的权限，例如：
管理员组 - 拥有所有权限
副管理员 - 可以执行任何操作，但无法打开管理面板中的某些部分
该如何操作？谢谢！
默认情况下这是不可能的，因为管理员拥有对论坛所有部分的无限制访问权限。根据您希望撤销的权限类型，或许将他们降级为版主会有所帮助？
版主无法创建分类，而我需要这个功能。
如果您在 Discourse 管理后台启用了 moderators_create_categories 设置，版主即可创建分类。
我在哪里可以找到那个？我浏览了管理面板中的所有分类，但没有看到任何可以分配给版主的内容。
*是否有类似 moderators_create_themes 的功能？
前往 管理 > 设置
然后搜索关键词 moderators_create_categories
您的 Discourse 是否已更新到最新版本？
您想问的是：“是否存在类似‘版主可能因创建有缺陷的主题而导致整个站点崩溃’的情况？”我相当确定答案会是“不会”。
您可以安装托管在 GitHub 上的远程主题，版主可以对其进行修改，但仍需要管理员来拉取这些更改。
你并不知道谁会去折腾主题，你怎么能做出这样的断言？
我问这个问题是因为，并没有像上面所说的那样拥有自定义规则的群组。
我的意思是，如果你足够信任某人并允许他们更换主题，那么你可以将他们设为管理员。
如果你希望允许非管理员修改主题或更改管理员的权限，则需要开发自定义插件。
但在我的当前场景中并非如此。我们有用户体验（UX）和设计团队，他们仅负责各自领域，因此只需授予其访问主题的权限即可。
我们也有同样的使用场景。我们有外部承包商（网页设计师），希望授予他们访问权限。完全管理员权限将可访问所有内容，包括私密管理讨论，这是不可取的。最好能有一个工作流，让网页设计师在无需完全管理员权限的情况下提交或尝试更改。
感谢你的帖子以及对此话题的提醒。
我们也希望（计划）在未来进一步完善部分管理员控制功能。
例如，我们感兴趣的是（未来某天）开发一个插件，该插件将通过 yml 容器文件中的变量进行配置，并将某些管理员操作（如下载网站的完整备份）限制为仅特定用户（用户ID）可执行。
这个插件构思已列入我的待办事项，一旦有机会，我会进一步研究。目前，我甚至尚未迈出第一步，即查看代码并评估该想法的可行性。
有人在这里找到解决方案了吗？
我有相同的使用场景，希望授予部分员工主题访问权限和首页广告访问权限。
简单的解决方案是信任用户，并将他们设置为管理员或版主。如果您不信任他们拥有完全控制权，但又希望他们拥有额外权限，则需要安装插件。
这并不是我不信任他们。但在我们的威胁模型中，这会引入额外的攻击面。如果由于用户自身的安全措施不足而导致特定用户被攻陷，该怎么办？这里存在许多变量。
那么我们将探讨插件方案。
同意，Discourse 需要额外的自定义控制。正如其他人提到的，可以聘请外部承包商来使用高级功能，同时保护成员信息。
群组管理功能尚可，但有时您可能需要部分高级版主功能，而非全部功能。
开发插件确实会有帮助。但正如“合并用户”插件已集成到核心中一样，更强大的版主/管理员自定义功能也应被集成，以支持更多类型的管理人员。
我赞同这里其他人的观点：如果能增加一层基于角色的访问控制（RBAC）的细粒度权限，明确指定 staff（员工）和 admin（管理员）可以访问哪些功能（而非所有功能），访问控制模型将会得到改善。
例如，某个站点可能希望增加更多管理员，但倾向于授予他们较小范围的管理员 RBAC 权限；比如，授予或不授予下载整个站点备份的权限，或访问某些员工操作日志文件的权限。此外，站点可能希望确保某些员工没有权限查看管理员或开发人员的操作记录，或者仅限制查看某些被视为更“私密”的操作。
所有网络安全专家都接受过相关培训（并通过直接经验深知），对任何组织而言，最大的威胁并非外部黑客或攻击者，而是“心怀不满的内部人员”。这一点在 IT 安全领域是毋庸置疑的基本风险，也是受过训练或经验丰富的 IT 安全专业人员所熟知的常识。因此，用“只要信任你的管理员”或“你必须信任你的员工”来 dismissing 内部人员威胁，对 IT 专业人士来说并不是一种技术解决方案。即使是最值得信赖、忠诚多年的员工，也可能因生活变故而转变为“心怀不满的员工”。此外，权限最高的员工往往最容易犯错；众所周知，通常来说，出于好意的员工或管理员失误造成的停机时间，往往比任何黑客攻击都要多。
之前，我曾考虑修改我们站点的 Discourse class Guardian 类，但在进一步检查该类后发现，似乎没有一个“快速修复”方案，能通过编写少量的猴子补丁（monkey patch）代码来增强 Discourse 的 RBAC 功能。我生性懒惰，倾向于尽可能创建简单的解决方案，因此将这个想法暂时搁置，转而投入到其他“高薪客户”的项目中。
随后，我考虑在代码层面再深入一层，将部分 staff 和 admin 的功能转移到 developer 角色下，但这种方法需要大量的猴子补丁，我当时认为这并非良策。毕竟，如果能用一个猴子补丁解决问题，而不是十个，显然一个补丁更好。
我目前还没有足够的时间或“迫切需求”去深入研究 Discourse 核心的这一部分，以确定是否存在一种“简单”的 RBAC 插件增强方案，可以通过一个“相对简单”的插件来实现。
老实说，我认为问题在于我还算不上是一位资深的 Ruby 专家，在大多数情况下，我甚至自认为只是个“想成为”Ruby 编码者的人，哈哈。我确信，更有可能存在一个简单的 RBAC 插件解决方案，但我个人尚未找到它。或许一位经验更丰富的 Ruby 开发者可以快速查看代码，并提出解决思路。
我的想法是引入一些新的布尔型站点设置，用于根据角色限制或授予特定的 RBAC 权限，然后通过插件中的猴子补丁将这些布尔值添加到代码的相应部分。不过，正如我之前提到的，我更倾向于只修补一个文件，而不是“多个”，以保持代码整洁、简单且易于维护。
等我有时间时，我会更深入地研究这个 RBAC 增强功能，因为它确实很有趣。
你好 @jrgong
通过插件实现这一点并不难，想必你对此也很熟悉。
基本上，你可以创建一个员工列表（通过邮箱、用户名等）作为全局设置，类似于 Discourse 通过邮箱地址定义开发者的方式。
然后，你可以在某些补丁中使用该 GlobalSetting 来允许你感兴趣的两种使用场景。
你的第一个使用场景：以员工身份自定义主题，我认为通过核心层面的“猴子补丁”（monkey patch）实现相对直接。
至于你的第二个使用场景，只需少量工作，你就可以 fork 这个插件，并重新设计该插件中的路由访问约束（以及任何所需的其他更改）：
由于广告插件的约束是内置于插件中的，因此最好直接修改该代码，以便根据你的 RBAC 策略，允许你“授权”的员工访问该插件中你希望开放的模块。
换句话说，如果你愿意编写代码，你提出的两个需求都是可以实现的；当然，你也可以在 Marketplace 频道中向精通 Discourse 插件开发的专业人士寻求帮助。
谢谢 @neounix，我非常感谢你的建议！我会找一名开发人员来完成这项工作。
编辑：除了分叉该插件之外，还有其他方法吗？
那 babble 聊天插件的访问权限呢？那是否也需要分叉？
我们讨论的是软件。
做事的方法总是有很多种。
我已经提供了我的建议。
