カテゴリ モデレーター 強化

|||
-|-|-|
| 概要 | カテゴリモデレーターにほとんどのモデレーターレベルのアクションを許可する
| リポジトリリンク | Github
| インストールガイド | Discourseにプラグインをインストールする方法

アップデート - 2024年5月6日

プラグインが更新され、現在最新の安定版リリース（-betaではない）であるDiscourse v3.2.1で動作することがテストされました。将来の安定版リリースのみをサポートすることを目指しています。つまり、-beta版を使用している場合、このプラグインは動作しない可能性が高いです。

プラグインのGitHubリンクにあるreadmeには、v3.2.1であることを確認する方法が説明されています。
私たちは最新の-beta版からv3.2.1にダウングレードしたばかりですが、遭遇した唯一の問題は、サイドバーが少しおかしくなることです。これを修正するには、ログアウトして再度ログインしてください。

このアップデートでは、以前からリクエストされていた「オーナーシップの変更」もカテゴリモデレーターが利用できるアクションに含まれました。

サポートされているDiscourseバージョン

v3.2.1

Discourseの機能リクエスト

これらの機能を組み込むための機能リクエストはこちらで公開されています。これらの変更をDiscourseのコア機能に含めることが有用だとお考えの場合は、ぜひサポートしてください。

機能

Discourseを使い始めて以来、カテゴリモデレーターが利用できるアクションは平凡だと感じてきました。ほとんどの基本的なコンテンツアクションは制限されています（スローモードの設定、スタッフの色/通知の追加など）。私たちの意見では、その理由はほとんどありません。

そのため、カテゴリモデレーターが割り当てられたカテゴリ内にいる場合に、コンテンツ関連のモデレーション権限のほとんどを付与するプラグインを作成することにしました。

除外されるのは以下の機能のみです。

• カテゴリモデレーターはユーザーに対してアクションを実行できません - 一時停止、ミュート、TLの変更、ユーザーの管理者ビューへのアクセスは、通常のモデレーターに予約されています。
• バッジの付与 - 管理者権限の一部が必要であり、これには干渉しないことを選択しました。
• モデレーション履歴の表示 - 管理者権限の一部が必要であり、これには干渉しないことを選択しました。
• トピックをPMに変換（およびその逆） - このアクションはニッチなケースと見なし、通常のフォーラムモデレーターに任せることを選択しました。

設定

他のプラグインと同様にインストールし、設定でチェックボックスをクリックして有効にするだけです。

変更履歴

• 初期のベータリリース
• Discourse v3.2.1で動作するバージョンを更新

TODO

• カテゴリモデレーターに対して有効にするアクションを選択できる詳細な設定ビュー

まったく理由がわからないのですか、それともあなたの場合だけですか？

メタでそれを使用することもあります。たとえば、誰かがもはや開発していないプラグインやテーマ/コンポーネントが別の人に引き継がれた場合、コンテキストに応じて、作成者を新しいメンテナーに変更したり、@systemに変更したりします。

言葉足らずだったようです。修正しました。TODOには、その機能をオプションで有効にする可能性が含まれています。

私たちのコミュニティでは、それは単にWiki投稿になり、誰もがそれに貢献できるようになります。あなたが指定した例では理にかなっていますが、私たちのフォーラムでは、それに近い唯一のケースは、何か（Raspberry Piを使用したセルフホスティング、ゲームのガイド、バンドのイベントリストなど）のガイドになるでしょう。

WordPress プラグインの例として、SSO で 1:1 になる場合でも、ユーザーは個別に Discourse ユーザー名で設定する必要があります。誰かが WordPress 側を忘れたり、誤って設定したりすると、投稿は「system」に所有されることになります。

WordPress モデレーターがブログ コメント カテゴリのカテゴリ モデレーターになれば、これを処理できます (もちろん、コメントをモデレートすることもできます)。

これは、カテゴリモデレーターがtl4にならないようにしたいという大きなユースケースですか？

コアの改善には非常に前向きです。

少なくとも、私は以下を区別したいと思います。

• 議論コミュニティによって、責任ある、生産的な、建設的な参加者として認識されていること、および
• 役割（議論への一般的な参加とは全く関係のない役割である可能性もある）により、特定の領域に対する責任と権限を持っていること

TL3は前者、TL4は後者の「あなたは終身雇用を得た！」バージョンに似ているように思われます。

カテゴリモデレーターは、後者に最適（またはそうあるべき）です。

TL4 はフォーラム全体に適用されます。私たちの考えでは、カテゴリモデレーターは、カテゴリによってのみ制限される、モデレーターが持つすべてのツールにアクセスできるべきです。

これは個人的な意見ですが、高TLを持つユーザーがカテゴリのモデレートに関して、カテゴリモデレーターよりも強力な権限を持つというのは、私たちには全く理にかなっていません。

私の意見では、TL4はフォーラム全体をモデレートできるものの、ユーザーに対して行動を起こすことはできないため、現状のままで良いと思います。
彼らは基本的に信頼されたユーザーであり、コミュニティによって保護され、育成するために認識されていますが、彼らが他のユーザーのアカウントに対して狂った行動を起こすリスクはありません。

繰り返しになりますが、私たちの見解では、カテゴリモデレーターは、モデレーターが行うことを、自身のカテゴリ内で実行できるべきです。これには、人々を禁止することも含まれますが、それは全く別のレベルの複雑さです。

私が考えていたのは、「banned_from_categoryslug」のようなユーザーグループを作成し、そのカテゴリに読み取り専用でそのカテゴリとユーザーが追加されることです。

あるいは、単に専用のテーブルを使用してユーザーを拡張することもできます。そこには user_id、category_id、および datetime を追加します。ユーザーがトピックにアクセスするたびに、実際にそれにインタラクトできるかどうかを確認するチェックが実行されます。

グループベースのアプローチを選択する利点は、管理者がフォーラムモデレーターが最終的に禁止を解除するためのUIがすでに実装されていることです。もう一方のアプローチでは、専用のビューを開発する必要もありますが、より柔軟性があります（禁止の期限切れなど）。

では、どのようなメリットが追加されますか？

トピックをグループが管理する他のカテゴリに移動する？
フラグキューを確認する？

これはDiscourseが望む方向性ではないかもしれませんが、カテゴリーモデレーターがこのような権限を持てば、カテゴリーをフォーラム内のフォーラムとして使用する可能性が開かれます。私の観点からは素晴らしいことです。

グループオーナーはグループからメンバーを削除できるため、そのメンバーのカテゴリへのアクセス権（グループ制限がある場合）も削除されると考えられます。したがって、グループオーナーとカテゴリモデレーターの組み合わせで対応できるのではないでしょうか。

カテゴリーモデレーターにとって、具体的に何が変わるのか教えていただけますでしょうか。どうぞよろしくお願いいたします。

「これらが唯一の除外事項です」という記述を考慮すると、Trust Level Permissions Reference の中で、カテゴリーモデレーター列に「TL」または空白と記載されているものはすべて、バッジの付与、オーナーシップの変更、ユーザーアカウントのアクションを除き、 に変わることになります。

より詳細な制御が可能になることを強く望みます。あるいは、さらに良いことに、その詳細な制御がプラグインではなく、組み込み機能であることを望みます。私にとっては、オーナーシップを変更できないこと（皮肉なことに、これも除外事項の一つであることは承知していますが）が大きな問題です。しかし、もちろん、すべての人にとってそうではありません。

100%同意します。

これは確かに機能します。このモデルを使用してセットアップを作成し、表示メッセージ（投稿できない場合）に関するhtml/markdownトピックの一部でした。グループオーナーにメッセージを送信するためのリンクを含むメッセージを生成します。

これは機能しますが、グループオーナーに時間オプション付きの禁止/サイレントリストオプションを追加する方が良いでしょう。問題のあるユーザーは、グループアクセスカテゴリから禁止できます。グループを自由に作成および削除できるようにするオプションもあります。制限付きグループであっても、このリストは、禁止メモ付きのグループからの禁止通知ユーザーに拡張できる可能性があります。

注 カテゴリモデレーターを使用してRedditのようなサブフォーラムシステムを有効にするために、グループ機能を拡張するための#feature requestを開始できる可能性があります。@simonも関心を持っているようです。

信じてください、Discourse自体にもそうあってほしいと切に願っています。誰かがフォーラムのスタイルに取り組んでくれたとしても、私は自分で変更をテストしなければなりませんでした。なぜなら、CSSとビジュアルだけを担当する人にフル管理者権限を与えることができなかったからです。

これについては検討できます。正直なところ、アプリケーション（通常のフォーラム全体のモデレーターは最終的にそれができます）について考えが及ばなかったため、単に無視していました。

全体として、Discourseがより詳細な制御を実装し、カテゴリモデレーターが自分のカテゴリからのみユーザーをBANできるようになれば、喜んでこのプラグインを廃止するでしょう。しかし、残念ながら、それは現時点では優先事項ではないか、彼らが関心を持っていることではないようです。

これらの変更に関する Feature request が見つからないのですが？ OP にリンクしていただけると、より注目を集めるのに役立つのではないでしょうか？

グループの拡張のアイデアを私か他の誰かが始めるかもしれません。

つまり

• グループオーナー向けの停止/禁止リスト。便利な機能です。無料で参加可能＆参加リクエスト制。期間オプションが必要になります。この拡張機能は、Reddit風のテーマとの一貫性をさらに高めるのに役立ちます。
• テーマを制限するオプション付きの#Theme および/または Theme component

現在、グループへの参加リクエストとテンプレートプラグインを使用して、参照用の禁止リストを使用しています。

最新の変更の1つで、どうやら

キューに入れられた投稿に新しい「修正」オプションを追加
モデレーターは、承認待ちの投稿をレビューする際に、「修正…」をオプションとして選択できるようになりました。ユーザーには、修正を依頼する理由と、任意でコメントを記載したプライベートメッセージが送信され、投稿を再送信する際に改善する機会が与えられます。

単に新しいオプションを追加した以上の何かがあったようですね。プラグインが動作しなくなりました。私たちの見える範囲ではDiscourseを壊しているわけではありませんが、追加されたオプションが利用できなくなりました。単一の新機能を追加するために多くのものをリファクタリングすることを誰かが決定すると、常に楽しいですね

変更された内容を把握するために、コードをもう一度確認しようとしています。

開発者またはそれに近い人物が、これは優先事項ではない／意図している方向性ではないと言っていたと理解していましたが、私の勘違いかもしれません。今は通りすがりにすぎませんが、誰かが機能リクエストを開きたい場合は、このトピックをクロスリンクして、一番上のリンクに表示されるようにするか、私を@メンションしていただければ、最初の投稿を更新します。

CEOからこのような励ましを得たということです。

もしそれらをコアに追加したいのであれば、おそらく#feature requestをいくつか作成するのが良いでしょう。