Hello!
I want to change user groups permissions, for example:
Admin Group - all permissions
Co Admin - can do anything but cannot open some sections on admin pane
How to do that? Thanks!
That’s not possible by default since admins have unrestricted access to all the sections of the forum. Depending on what kind of permissions you want to revoke, maybe demoting them to moderator can be helpful?
Moderator cannot create a categories and i want that
Mods can create categories if you enable the moderators_create_categories settings in your discourse admin.
「いいね！」 4
Where i find that? I looked through all the categories in the admin panel and did not see anything that I could assign to moderators.
*Is there something like moderators_create_themes?
Go to admin > Settings
Then search for the keyword moderators_create_categories
「いいね！」 4
Is your Discourse up to date?
What you are asking is, "Is there something like ‘moderators can crash the whole site by making a broken theme?’ ". I’m pretty sure that the answer is going to be “No.”
You could install a remote theme hosted in github that a moderator could change, but an admin would still need to pull in the changes.
You do not know who will tinker with the themes, how can you make that statement?
I asked this question because there are no groups with custom rules like it said above.
My point is that if you trust someone enough to change themes then you can make them an admin.
If you would like to allow non-admins to modify themes or otherwise change what a moderator can do you’ll need a custom plugin.
「いいね！」 2
Not in my current scenario. We have UX and Design teams and they are only responsible for that area, so only access to the themes would be necessary.
「いいね！」 2
私たちも同じユースケースを持っています。ウェブデザイナーなどの外部請負業者にアクセスを付与したいと考えています。フル管理者権限では、プライベートな管理ディスカッションを含むすべての情報にアクセスできてしまいますが、それは望ましくありません。フル管理者権限を持たずに、ウェブデザイナーが変更を提出したり試行したりできるワークフローがあると便利です。
「いいね！」 4
@Joaquin_Menchacha さん、こんにちは
このトピックに関する投稿とリマインダーをありがとうございます。
将来、管理者コントロールの一部を改善する計画（望み）もあります。
例えば、いつか yml コンテナファイルで変数を設定し、特定の管理者アクション（サイト全体のバックアップのダウンロードなど）を特定のユーザー（ユーザーID）のみに制限するプラグインに興味があります。
このプラグインのアイデアは「私の課題」の一つで、機会があればさらに詳しく検討する予定です。現時点では、コードを確認し、このアイデアの実現可能性を検討するという最初のステップさえ踏んでいません。
「いいね！」 3
ここで解決策を見つけた方はいますか？
私も同様のケースで、一部のスタッフにテーマへのアクセスとハウス広告へのアクセスを付与したいと考えています。
簡単な解決策は、人を信頼して管理者またはモデレーターに任命することです。完全な制御を任せるには信頼できないが、追加のアクセス権を与えたい場合は、プラグインが必要になります。
「いいね！」 1
彼らを信頼していないわけではありません。しかし、脅威モデルの観点から見ると、追加の攻撃対象領域が生まれてしまいます。もしユーザー側でセキュリティが不十分だった場合、その特定のユーザーが侵害される可能性はどうなるでしょうか。考慮すべき変数が多すぎます。
それでは、プラグインのオプションを検討しましょう。
「いいね！」 2
同意します。Discourse にはカスタマイズのための追加制御が必要です。他の人が指摘しているように、外部の請負業者に高度な機能を利用させつつ、メンバーの情報を保護するような仕組みが望ましいでしょう。
グループモデレーションはまずまずですが、フル権限のモデレーター機能のすべてではなく、一部の高度な機能だけが必要な場合もあります。
プラグインが役立つかもしれません。しかし、「ユーザーマージプラグイン」がコア機能に統合されたように、より多様なスタッフタイプを許可するための、より強力なモデレーター/管理者のカスタマイズ機能もコアに統合されるべきです。
「いいね！」 1
他の皆さんと同様に、アクセス制御モデルは、特定の機能（すべてではない）に対して staff や admin がアクセスできる範囲を指定する、より細かい粒度の RBAC（ロールベースアクセス制御）レイヤーを追加することで改善されると考えます。
例えば、サイト運営者がより多くの管理者を追加したい場合でも、管理者に付与する RBAC 権限の範囲を狭く設定したいと考えるかもしれません。具体的には、サイト全体のバックアップをダウンロードする権限や、特定のスタッフ行動ログファイルへのアクセス権を付与するか否かを選択できるようにするといった具合です。また、一部のスタッフに管理者や開発者の行動（あるいは「プライベート」と見なされる特定の行動）を閲覧する RBAC 権限を与えないようにしたいと考える場合もあるでしょう。
すべてのサイバーセキュリティの専門家は教育を通じて学び、直接的な経験からも知っています。組織に対する最大の脅威は外部のハッカーや攻撃者ではなく、「不満を持つ内部関係者」であるということです。この基本的な IT セキュリティリスクについては疑いの余地がなく、訓練された経験豊富な IT セキュリティ専門家にとっては確立された知識です。したがって、「管理者を信頼すればよい」「スタッフを信頼しなければならない」という理由だけで内部脅威を軽視することは、IT 専門家にとって技術的な解決策ではありません。何年も忠実に務めてきた最も信頼できるスタッフでさえ、人生の問題に直面した際に「不満を持つスタッフ」へと変化する可能性があります。さらに、最も特権的な権限を持つスタッフほどミスを犯す可能性が高く、一般的に言えば、善意のスタッフや管理者のミスによって発生するダウンタイムの方が、ハッカーによるものよりも多いことは周知の事実です。
以前、Discourse の class Guardian を当サイト用に修正することを検討しましたが、そのクラスをさらに詳しく調査した結果、Discourse の RBAC を強化するために最小限のモンキーパッチコードで済むような「簡単な修正」があるとは明確にはわかりませんでした。本質的に怠け者であり、可能であればシンプルな解決策を好むため、このアイデアは一旦保留にし、他の「報酬の高いクライアント」プロジェクトに進みました。
その後、コードのレベルを一段階下げて、staff や admin の一部の機能を developer に移管することを考えましたが、このアプローチには多くのモンキーパッチが必要となり、当時の私には良いアイデアとは思われませんでした。結局のところ、1 つのモンキーパッチで達成できることを 10 個のパッチで行う必要があるのであれば、明らかに 1 つの方が優れています。
Discore コアの一部をさらに深く調査し、「比較的単純な」プラグインを通じて作成可能な「簡単な」RBAC プラグイン拡張機能があるかどうかを判断する時間や「切実な要件」はまだ持っていません。
正直なところ、私がまだスーパーな Ruby 開発者ではなく、大部分を「Ruby コーダーの志願者」と考えていることが問題だと思っています（笑）。おそらく、シンプルで優れた RBAC プラグインの解決策がどこかに存在するとは確信していますが、個人的にはまだ見つけることができていません。もっと経験豊富な Ruby 開発者であれば、コードをすぐに確認して、どのようにアプローチすべきか分かるでしょう。
私のアイデアは、ロールに基づいて特定の RBAC 権限を制限または付与する新しいブール型のサイト設定を導入し、それらのブール値をプラグイン内のモンキーパッチを通じてコードの適切な部分に追加するというものです。ただし前述の通り、1 つのファイルのみをパッチし、「多数」のファイルをパッチするのではなく、クリーンでシンプルかつ保守が容易な方法を好みます。
時間ができたら、この RBAC 拡張機能についてさらに深く調査する予定です。確かに興味深いテーマですから。
「いいね！」 1
jrgong さん、こんにちは
ご存知の通り、プラグインを使えばそれほど難しいことではありません。
基本的には、Discourse がメールアドレスで開発者を定義しているのと同様に、メールアドレスやユーザー名などでスタッフのリストをグローバル設定として作成できます。
その後、その GlobalSetting をいくつかのパッチで使用し、ご関心のある 2 つのユースケースを許可するように設定します。
まず、スタッフとしてテーマをカスタマイズするというご要望は、コアへのマモンキーパッチ適用により比較的 straightforward に行えると思います。
次に、2 つ目のユースケースについては、少しの手間でこのプラグインをフォークし、このプラグイン（および必要に応じて他の変更点）のルートアクセス制約を再設計することも可能です。
広告プラグインの制約はプラグイン自体に組み込まれているため、ご自身の RBAC に基づいて「許可された」スタッフが、許可したいプラグインの機能にアクセスできるように、実際にそのコードを変更するのがよいでしょう。
つまり、お望みの 2 つの要件は、コードを書く用意があればどちらも実現可能です。もちろん、Marketplace でスキルのある Discourse プラグイン開発の専門家に依頼することもできます。
「いいね！」 2
@neounix さん、ご意見ありがとうございます！開発者に依頼して対応させます。
編集：プラグインをフォークする以外の方法はないのでしょうか？
また、Babble チャットプラグインへのアクセスはどうでしょうか？これもフォークが必要になるのでしょうか？
私たちはソフトウェアについて話しています。
物事には常に多くのやり方があります。
私はあなたに私の推奨事項を提供しました。
「いいね！」 2