抱歉，这是个旧帖子，但为什么不将您的主题设置为 GitHub 上的仓库呢？授权您的设计和 UX 团队访问并在 GitHub 上更新主题。
现在，在 Discourse 中，您可以设置主题在重建时自动更新。
您的管理员现在只需执行重建操作即可引入设计和 UX 团队所做的任何更改，而后者完全无需访问管理员权限。
简而言之：
在编写访问控制相关代码时，通常应在服务器端执行这些基于角色的访问控制（RBAC）检查。
客户端 JavaScript 中的 RBAC 代码可能被客户端篡改。
这意味着，在定义员工、管理员和版主的核心 RBAC 权限时，通常应在 Rails 中实现，而不是在 JavaScript 中。
顺便一提，Discourse 现在也是通过其称为“守护者”（guardian）的机制来实现 RBAC 的，这是一个名为 class Guardian 的 Ruby 类，代码如下：
如果开发者打算通过在 JavaScript 代码中调用 Discourse API 来添加 RBAC 检查，请注意，这段代码可能被攻破，因为在浏览器中运行的代码是可以被篡改的。
我的建议是：确保所有核心 RBAC 逻辑都在服务器端执行，切勿试图在客户端 JavaScript 中绕过这一机制。
在 Discourse 2.5 及更高版本中，还有信任等级 4 和分类版主。
我有一个类似的用例：我运营着一个小型非营利社区，其中一位用户负责维护主题和设计。
除了我和我的共同所有者外，我不想让任何人访问私人用户数据（如电子邮件地址等），但我有 4 名版主。
为了让设计师开展工作，我不得不创建一个不含任何内容的复制站点，并让他担任管理员，然后手动复制主题和组件。然而，这种做法并不理想，因为某些修改需要借助实际内容才能进行验证。
为什么不往预发布/测试站点添加一些内容呢？这通常是推荐的作法。
因此，让开发人员在 staging 站点上进行开发，并将主题推送到 GitHub。但你仍需自行升级这些主题。你可以设法通过 API 进行升级，并以某种方式让开发人员能够触发该操作。
我正在开发一个工具，或许能在这方面提供帮助。
我们也有这个完全一样的需求，有人解决过这个问题吗？
我不知道这在这种情况下是否有用，但如果你只需要一些内容，可以使用 populate rake 任务：
谢谢，但不幸的是，它目前没什么用。
如果你不信任设计师能看到你的数据，你会设想出什么解决方案？
也许你可以只给他们一个API密钥，让他们使用discourse_cli将主题推送到那里，然后在他们完成后将其禁用？
绝对没有理由让设计师访问10万用户，哈哈。而且，这也会违反GDPR规定。是否可以只为主题更新提供一个CLI密钥？
抱歉！我想你是对的。
现在，与创建此主题时（显然我当时就是这么想的，才会写下我的回复）不同，我们确实有细粒度的 API 密钥。添加一个仅用于主题管理的新范围应该不难。
也许值得在 Feature 中创建一个新主题，要求提供一个主题开发者 API 密钥范围。这似乎是个好主意。
不，它不是。这可能违反该网站的规定，但这些规定可以而且应该改变。
如果@AV_C可以发布一个关于这个_要求_的参考，那就太好了。尽管我非常理解客户出于各种原因希望限制对用户群甚至私人分类的访问。完全管理员可以访问会员的注册电子邮件，并且私人分类可能包含其他敏感内容，具体取决于客户的用例。
我认为@pfaffman有一个好主意，可以确保通过受限的管理员API来覆盖这种差距。一旦设计工作完成，就可以撤销密钥，直到需要为止。
这也将符合Jay关于不在“关于”页面上显示用户的管理员的想法。