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 タスクがあります。
ありがとうございます。残念ながら、現時点ではあまり役に立ちません。
デザイナーがあなたのデータを見るのを信頼しない場合、どのような解決策を想像しますか？
テーマをそこにプッシュするために discourse_cli を使用できるAPIキーを彼らに与え、その後、彼らが終わったら無効にするというのはどうでしょうか？
デザイナーが10万人のユーザーにアクセスできる理由など全くありません。また、GDPR規則にも違反します。テーマの更新のためだけにCLIキーを提供することは可能ですか？
申し訳ありません！ あなたがおっしゃる通りだと思います。
このトピックが作成された時（私の返信を書いた時の私の頭の中はそこにあったようです）とは異なり、現在では詳細なAPIキーが利用可能です。テーマ管理専用の新しいスコープを追加することは、それほど難しくないはずです。
Feature でテーマ開発者APIキーのスコープを求める新しいトピックを作成することも検討する価値があるでしょう。それは良いアイデアだと思います。
いいえ、そうではありません。そのサイトの規則に反する可能性はありますが、それらは変更可能であり、変更されるべきです。
@AV_C さんがこの tequirement の参照を投稿してくれると良いのですが。クライアントがユーザーベースやプライベートカテゴリへのアクセスを制限したいと思う理由は様々あることを強く理解できます。フル管理者であればメンバーのサインアップメールにアクセスでき、プライベートカテゴリにはクライアントのユースケースによっては他の機密情報が含まれる可能性があります。
@pfaffman さんの、制限された管理者APIを通じてこのようなギャップをカバーできるようにするというアイデアは良いと思います。デザイナーの作業が完了したら、必要になるまでキーを無効にすることができます。
これは、Jayさんの、ユーザーが「About」ページに管理者として表示されないようにするというアイデアにも合致するでしょう。