管理者が作成した投稿は、スタッフやモデレーターを含む他のすべてのユーザーが編集できないようにしたいと考えています。利用規約さえもモデレーターが編集できることを確認しました。
アクティブなフォーラムユーザーがモデレーターの役割をオファーされたが、その後、利用規約のような法的文書の編集や削除など、非倫理的な行動を開始するシナリオを検討してください。
そのような特定の権限または制限を確立する方法はありますか？
利用規約とプライバシーポリシーは現在デフォルトの「スタッフ」カテゴリにあるため、作成できるユーザーなどを調整できません。
信頼レベル3のユーザーでさえ利用規約を変更できることに気づきました。提案が「信頼レベルを下げる」というものであれば、それは実行可能な解決策ではありません。モデレーターは、制限なしでフォーラムを効果的にモデレートするために他の権限を必要とするからです。
これらの種類の制限を設定するためのデフォルトの方法はありますか？
さらに、各権限を編集し、権限を追加/削除する方法はありますか？
管理者が編集できる別のカテゴリに移動してください。
返信ありがとうございます。
自分の投稿を引用します。TOSは「スタッフ」カテゴリにあります。スタッフカテゴリのセキュリティを設定/編集することはできません。あなたの方法は管理者が作成した他のカテゴリでは機能しますが、Discourseはデフォルトのスタッフカテゴリのセキュリティを設定することを許可していません。
利用規約とプライバシーポリシーは現在、デフォルトの「スタッフ」カテゴリにあり、誰が作成できるかなどを調整できません。
よくわかりません。私がやった可能性もあります。しかし、私の主な懸念はまだそこにあります → 法的文書を編集できる人を制限すること。
では、新しく作成されたTOSドキュメント（新しいカテゴリ内）を、「examplesite. com/tos」のデフォルトの公式「Terms of service」タブに表示するにはどうすればよいですか？
あなたの方法で可能ですか？
これを実現するには、利用規約を管理者が管理する別のプラットフォームにホストします。次に、ディスコースの設定を使用して、外部の利用規約やその他のポリシーページを表示します。これにより、管理者はどこで変更を加えるべきかを知ることができ、ディスコース上で直接編集できるのは管理者だけになります。
管理者がアクセスできる新しいカテゴリを作成し、利用規約ページをそのカテゴリに移動することができます。
その方法で成功したことはありますか、それともうまくいくだろうと考えているだけですか？それは新たな問題を引き起こす可能性があります。
本日テストしたところ、問題なく動作し、TOSページをスタッフカテゴリに戻すことができました。
システムが編集可能なバージョンから公式ページをどのように公開するのかはわかりませんが、名前/カテゴリを変更しても問題は発生しないようです。
新しい利用規約ページが「利用規約」のデフォルトタブに表示されず、投稿にリダイレクトされる（そして、他のすべての隣接するタブ「概要、FAQ、プライバシーポリシー」が利用規約タブの隣に表示されなくなり、利用規約タブ自体も表示されなくなる）ため、あまりプロフェッショナルではありません。
Discourse のこれらの不要な制限により、サイトのカスタマイズが非常に困難になります。
「概要」ページについても同様です。「統計」を削除しようとしてもできません。Discourse の強制的な決定により、表示する必要があります。奇妙なルールです。
TOS ページについても同様です。「いいえ、すべての非倫理的なモデレーターが編集できるようにしておく必要があります。これは Discourse の強制的な決定です」
Discourse がサイトに強制的に意思を押し付けているのは奇妙です。
Discourse の主なスローガンは「すべての権力はコミュニティにあり、管理者にはない」だと思います 
Discourse の現在のポリシーは、不正行為をしようとしていると疑われるモデレーターを置くべきではない、しかしもし置いたとしても、彼らの行ったことはすべて元に戻せる、というものだと感じています。
カテゴリーモデレーターは、信頼度の低いモデレーションのヘルプを目的とした役職です。
新しいスタッフが利用規約を「とにかくやらないで」のようなものに変更した場合、古いバージョンは投稿の編集履歴に保存されます。リビジョンを非表示にしても何も起こらず、管理者はそれを見ることができ、データベースからリビジョンをパージできるのは管理者のみです。
…ただし、スタッフ専用のカテゴリ「staff- category」があり、そこにはTOSが頻繁に置かれており、スタッフがTL3でない限り、TL3はそれを編集する方法がありません。
ここで大きな問題が発生しています。@PrettyGirl が何を 変更したのかわかりません。なぜなら、通常のTL3がスタッフ限定カテゴリを編集したり、見ることさえできるような大きなバグがあるとは信じたくないからです。
回答が提供されているのに、なぜまだこのように言うのか分かりません。
「管理者のみが作成/返信できる権限を持つ「管理者」カテゴリを作成し、利用規約とプライバシーポリシーのトピック（および必要であればFAQ）をそこへ移動させれば、当面の課題は解決しませんか？公開されている /tos と /privacy ページはトピックIDに基づいているため、基になるトピックが別のカテゴリに移動されても存在し続けます。
ただし、非倫理的なモデレーターがいるという問題は、別途対処する必要があるより広範な問題になります。
正しく作成すればプロフェッショナルになります。私は2ダース以上のクライアントがポリシーページを外部でホストしており、そのような外部ページを展開する際に、UXの一貫性を確保し、フォーラムやメインサイトへの適切なバックリンクを設定することに細心の注意を払っています。
CSSで非表示にするだけの問題です。それが問題なければ。
もし彼らが非倫理的であったり、コミュニティの原則に沿っていなかったりするのであれば、管理者/モデレーター/スタッフなどの資格がないのかもしれません。彼らがスタッフの採用に対して取っているアプローチには根本的に何か問題があり、これは技術的な解決策よりも哲学的な解決策が必要です。
あなたが求めていることのほとんどは、カスタムプラグインで実現可能であり、このコミュニティの誰かに作成または依頼することができます。
ここにはもっと大きな問題があり、それはコミュニティとあなたの間の信頼であり、最も制限的な権限でも対処できません。あなたはこれを異なる視点から考える必要があり、スタッフメンバーとして誰かを募集する際に賢明な選択をするようにアプローチを調整する必要があります。
いずれにしても、スタッフカテゴリはTL3には表示されるべきではありません。どのようにしてそれが可能になっているのか分かりません。
それを試した後に言いましたか？私は最初にこのトピックを私のフォーラムの管理者のみが編集できるカテゴリに移動しました。副作用はありません。あなたが言ったような「可能性がある」ということはありません。
そして、このトピックに関連する5つの非表示設定があります。rails cでRubyコンソール環境に入り、SiteSetting.tos_topic_id = xxxを使用して、任意のトピックIDに設定してください。
tos_topic_id:
default: -1
hidden: true
guidelines_topic_id:
default: -1
hidden: true
privacy_topic_id:
default: -1
hidden: true
welcome_topic_id:
default: -1
hidden: true
admin_quick_start_topic_id:
default: -1
hidden: true
client: true
Discourseは、他のプラットフォームよりも管理者に多くの権限を与えています。試さずにそのようなコメントをしないでください。つまり、Discourseが自動車メーカーだった場合、トランスフォーマーを無料で納品するように依頼すべきではありません。
新規インストールのデフォルト設定では、管理者または信頼レベル#4のモデレーターのみが利用規約/その他の公式ページを編集できますが、TL4の誰でもTL3が編集できる別のカテゴリに移動した可能性があります。
一方、TL4であってもスタッフであるとは限りません。管理権限またはモデレーター権限を持たないTL4の場合、スタッフカテゴリにあるトピックを表示、編集、または移動することはできません。他方、モデレーターの権限はTLに依存しません。Trust Level Permissions Reference を参照してください。モデレーターの列にTLはありません。
TL4はスタッフモッドか管理者だと思っていました。