こんにちは！
ユーザーグループの権限を変更したいと考えています。例えば：
管理者グループ - すべての権限
副管理者 - 何でもできますが、管理パネルの一部のセクションを開くことはできません
その方法は？ありがとうございます！
デフォルトではそれは不可能です。管理者はフォーラムのすべてのセクションに無制限のアクセス権を持っているためです。どの権限を剥奪したいかによりますが、管理者権限をモデレーターに格下げするのが役立つかもしれません。
モデレーターはカテゴリを作成できませんが、それを可能にしたいです
Discourse 管理画面で moderators_create_categories 設定を有効にすると、モデレーターがカテゴリを作成できるようになります。
どこで見つかりますか？管理パネルのすべてのカテゴリを確認しましたが、モデレーターに割り当てられるものは何もありませんでした。
*moderators_create_themesのような機能はありますか？
管理画面 > 設定へ移動
次に、キーワード moderators_create_categories を検索してください
お使いの Discourse は最新バージョンですか？
ご質問の意図は、「壊れたテーマを作成することで、モデレーターがサイト全体をクラッシュさせるような機能はあるのか？」ということですね。その答えは「いいえ」であることは確実です。
GitHub 上でホストされているリモートテーマをインストールして、モデレーターが変更できるようにすることは可能ですが、変更を反映させるには引き続き管理者の操作が必要です。
誰がテーマをいじるのか分からないのに、そんなことが言えるのですか？
私は上記のようにカスタムルールを持つグループがないという理由でこの質問をしました。
私が言いたいのは、テーマを変更するほど誰かを信頼できるなら、その人を管理者にすればいいということです。
管理者以外のユーザーにテーマの変更や、モデレーターが行える操作の変更を許可したい場合は、カスタムプラグインが必要です。
現在の私の状況ではそうではありません。UX チームとデザインチームがあり、それぞれその分野のみを担当しているため、テーマへのアクセス権のみが必要になります。
私たちも同じユースケースを持っています。ウェブデザイナーなどの外部請負業者にアクセスを付与したいと考えています。フル管理者権限では、プライベートな管理ディスカッションを含むすべての情報にアクセスできてしまいますが、それは望ましくありません。フル管理者権限を持たずに、ウェブデザイナーが変更を提出したり試行したりできるワークフローがあると便利です。
@Joaquin_Menchacha さん、こんにちは
このトピックに関する投稿とリマインダーをありがとうございます。
将来、管理者コントロールの一部を改善する計画（望み）もあります。
例えば、いつか yml コンテナファイルで変数を設定し、特定の管理者アクション（サイト全体のバックアップのダウンロードなど）を特定のユーザー（ユーザーID）のみに制限するプラグインに興味があります。
このプラグインのアイデアは「私の課題」の一つで、機会があればさらに詳しく検討する予定です。現時点では、コードを確認し、このアイデアの実現可能性を検討するという最初のステップさえ踏んでいません。
ここで解決策を見つけた方はいますか？
私も同様のケースで、一部のスタッフにテーマへのアクセスとハウス広告へのアクセスを付与したいと考えています。
簡単な解決策は、人を信頼して管理者またはモデレーターに任命することです。完全な制御を任せるには信頼できないが、追加のアクセス権を与えたい場合は、プラグインが必要になります。
彼らを信頼していないわけではありません。しかし、脅威モデルの観点から見ると、追加の攻撃対象領域が生まれてしまいます。もしユーザー側でセキュリティが不十分だった場合、その特定のユーザーが侵害される可能性はどうなるでしょうか。考慮すべき変数が多すぎます。
それでは、プラグインのオプションを検討しましょう。
同意します。Discourse にはカスタマイズのための追加制御が必要です。他の人が指摘しているように、外部の請負業者に高度な機能を利用させつつ、メンバーの情報を保護するような仕組みが望ましいでしょう。
グループモデレーションはまずまずですが、フル権限のモデレーター機能のすべてではなく、一部の高度な機能だけが必要な場合もあります。
プラグインが役立つかもしれません。しかし、「ユーザーマージプラグイン」がコア機能に統合されたように、より多様なスタッフタイプを許可するための、より強力なモデレーター/管理者のカスタマイズ機能もコアに統合されるべきです。
他の皆さんと同様に、アクセス制御モデルは、特定の機能（すべてではない）に対して 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 拡張機能についてさらに深く調査する予定です。確かに興味深いテーマですから。
jrgong さん、こんにちは
ご存知の通り、プラグインを使えばそれほど難しいことではありません。
基本的には、Discourse がメールアドレスで開発者を定義しているのと同様に、メールアドレスやユーザー名などでスタッフのリストをグローバル設定として作成できます。
その後、その GlobalSetting をいくつかのパッチで使用し、ご関心のある 2 つのユースケースを許可するように設定します。
まず、スタッフとしてテーマをカスタマイズするというご要望は、コアへのマモンキーパッチ適用により比較的 straightforward に行えると思います。
次に、2 つ目のユースケースについては、少しの手間でこのプラグインをフォークし、このプラグイン（および必要に応じて他の変更点）のルートアクセス制約を再設計することも可能です。
広告プラグインの制約はプラグイン自体に組み込まれているため、ご自身の RBAC に基づいて「許可された」スタッフが、許可したいプラグインの機能にアクセスできるように、実際にそのコードを変更するのがよいでしょう。
つまり、お望みの 2 つの要件は、コードを書く用意があればどちらも実現可能です。もちろん、Marketplace でスキルのある Discourse プラグイン開発の専門家に依頼することもできます。
@neounix さん、ご意見ありがとうございます！開発者に依頼して対応させます。
編集：プラグインをフォークする以外の方法はないのでしょうか？
また、Babble チャットプラグインへのアクセスはどうでしょうか？これもフォークが必要になるのでしょうか？
私たちはソフトウェアについて話しています。
物事には常に多くのやり方があります。
私はあなたに私の推奨事項を提供しました。
