Sorry old post but why don’t you set up your theme as a repo in GitHub? Permission your design and UX team to have access to update the Theme in GitHub.
In Discourse you can now set Themes to auto update upon rebuild.
Your admins will now only need to rebuild to bring in any changes made by the Design and UX team and the latter will not need access to admin at all.
Just a short note:
When coding matters of access control, in general, these RBAC checks should be performed on the server side.
RBAC code in client-side Javascript can be manipulated by the client.
This means that when defining core RBAC permissions for staff, admins and moderators, this should be done (generally speaking) in Rails, not in Javascript.
OBTW, this is also how Discourse does RBAC now, using what Discourse calls “guardian”, a Ruby class called class Guardian, here:
https://github.com/discourse/discourse/blob/master/lib/guardian.rb
If a developer is going to add RBAC checks in Javascript code by calling the Discourse API, keep in mind that this code can be compromised because code which runs in the browser can be manipulated.
My recommendation is to make sure all core RBAC code is performed on the server side and do not try to short cut this in client-side Javascript.
There is also trust level 4 and category moderators, in discourse 2.5 and beyond.
I have a similar use case, in that I run a small non-profit community where one of our users is maintaining the themes and design.
I do not wish to give anyone beside me and my co-owner access to private user data (e-mail addresses etc.), but I do have 4 moderators.
In order for the designer to work, I’ve had to create a copy site with no content where he is the admin, and I then copy themes and components manually. However it is not desirable since some changes requires content in order to proof.
Why not add some content to the staging / testing site? That’d be the typical recommendation.
So let the developer develop on the staging site, and push the themes to github. But you’ll still need to upgrade them yourself. You might contrive to do the upgrade with the API and somehow make the developer be able to trigger it.
I’m working of a tool that might be able to help with that.
我们也有这个完全一样的需求，有人解决过这个问题吗？
我不知道这在这种情况下是否有用，但如果你只需要一些内容，可以使用 populate rake 任务：
谢谢，但不幸的是，它目前没什么用。
如果你不信任设计师能看到你的数据，你会设想出什么解决方案？
也许你可以只给他们一个API密钥，让他们使用discourse_cli将主题推送到那里，然后在他们完成后将其禁用？
绝对没有理由让设计师访问10万用户，哈哈。而且，这也会违反GDPR规定。是否可以只为主题更新提供一个CLI密钥？
抱歉！我想你是对的。
现在，与创建此主题时（显然我当时就是这么想的，才会写下我的回复）不同，我们确实有细粒度的 API 密钥。添加一个仅用于主题管理的新范围应该不难。
也许值得在 Feature 中创建一个新主题，要求提供一个主题开发者 API 密钥范围。这似乎是个好主意。
不，它不是。这可能违反该网站的规定，但这些规定可以而且应该改变。
如果@AV_C可以发布一个关于这个_要求_的参考，那就太好了。尽管我非常理解客户出于各种原因希望限制对用户群甚至私人分类的访问。完全管理员可以访问会员的注册电子邮件，并且私人分类可能包含其他敏感内容，具体取决于客户的用例。
我认为@pfaffman有一个好主意，可以确保通过受限的管理员API来覆盖这种差距。一旦设计工作完成，就可以撤销密钥，直到需要为止。
这也将符合Jay关于不在“关于”页面上显示用户的管理员的想法。