我赞同这里其他人的观点：如果能增加一层基于角色的访问控制（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 增强功能，因为它确实很有趣。