カテゴリBANはサポートされていませんが、プラグインで可能でしょうか？

開発
1

メインのコミュニティ内に、さらに小さなフォーラムが存在するような大規模コミュニティには、ユースケースがあります。ゲーム文化におけるクランを想像してみてください。

これらのサブコミュニティは、ボードのメインルールを採用しますが、さらに特定の追加ルールと、セクションをモデレートし、リーダーシップを発揮する専任チームも持ちますが、それは本題から外れます。

カテゴリモデレーターは、カテゴリに対してのみ行動でき、ユーザー自身には行動できません。しかし、私のユースケースでは、サブフォーラムのルールを破ったユーザーの参加を阻止できる必要があります。

必要なのは、カテゴリモデレーターが特定のユーザーをカテゴリからブロックできるように、コア機能に十分な粒度があるかどうかを知ることだけです。

私が想像する方法は、category_id と user_id の両方を追加するカスタムテーブルが生成され、ユーザーが特定のトピックやカテゴリにアクセスしようとしたときに、そのテーブルもチェックされるというものです。

的外れでしょうか？実現可能でしょうか？私はソフトウェア開発の経験が豊富ですが、Rubyについてはほとんど知らないので、Discourseのソースコードのどこを見ればよいのか全く分かりません :weary:

「いいね！」 1
2

クランカテゴリのメンバーのみが投稿できるようにし、カテゴリに含めたくないユーザーを削除できます。これには、カテゴリに含めたいすべてのユーザーがそのグループのメンバーである必要があります。

「いいね！」 2
3

素晴らしい議論のトピックです。

これを解決する最も簡単な方法は、信頼レベルです。

「禁止」が必要なときに人々をノックダウンし、カテゴリに高い信頼レベルを要求させます。

最近、まさにこの状況が発生し、ユーザーをTL 1にロックし、カテゴリにはTL 2が必要でした。これで完了です！

「いいね！」 2
4

私も同じことをしました。そして、誰かが自動的にTL2より高くなるのを許可しないので、精神的にも管理上も非常に簡単で複雑でない解決策でした。そこには優雅さのヒントもありました :wink:

「いいね！」 2
5

以前、クライアントのためにこれを行いました。信頼レベルは私たちには機能しなかったので、代わりに各カテゴリごとにプライベートグループを作成し、各ユーザーは自動的にプロビジョニングされ、カテゴリモデレーターがオーナーになりました。

「禁止」は、そのようなメンバーシップを削除するだけで、管理者の作業はゼロでした。

開始するには少し手間がかかりますが、その後は実質的にゼロです。

「いいね！」 4
6

しかし、グループが動的な場合、それはどのように行うのですか？

例：クライアントの1社には、「販売中」カテゴリのあるフォーラムがあり、TL2以上のユーザーがアクセスできます。
特定のメンバーがそこでトピックを作成できないように禁止したいと考えていますが、TL2と同じメンバーから特定の5ユーザーを除いたグループをコピーして維持する必要があります。

「いいね！」 3
7

おそらく、基準に基づいてユーザーをグループにプロビジョニングし（TL2への昇格を検出するなど？）、必要に応じて削除するという同じ方法ですか？TL2がエントリー基準であるというだけで、メンバーシップを決定するためにそのTL2ステータスに依存する必要があるわけではありませんよね？また、インスタンス上で何かをエンジニアリングする時間とリソースがあるかどうかも関係します。

それが万能の解決策であるとは提案しませんでした。余分な作業をしたくない場合、彼らのユースケースでは機能しないかもしれませんが、私のクライアントの例や、インスタンスがギルド/クラン/その他のものに分割されているシナリオでは、うまく適合する可能性があります。

「いいね！」 1
8

しかし、いずれにしてもインスタンス上で何かをエンジニアリングするのであれば、カテゴリ禁止機能があった方がいいですね :sunglasses:

メンテナンス性も向上します。50,000人のユーザーがいて、そのほとんどがカテゴリにアクセスできるようにしたいが、ごく一部のユーザーはアクセスできないようにしたい場合、そのごく一部のユーザーのリストを取得するのは困難です。

「いいね！」 1
9

つまり、禁止は排除の別の言葉にすぎず、Discourse には除外権限はまったくありません。 「非包含」が実質的に同じことである場合、それは存在するべきでしょうか？ トラブルシューティングを楽にする明示的な許可モデルが好きです。

何年も前の vBulletin の許可/拒否モデルを解決しようとした奇妙な悪夢をまだ見ています。より多くの苦痛と負債を伴って経験したのは RSOP だけです。

10

代替案のご提案ありがとうございます。しかし、私が知りたいのは具体的な技術的な質問であり、妥協案ではありません。:slight_smile:

「いいね！」 2
11

はい、そうだと思います。

@crius プラグインで可能だと思います。カテゴリシリアライザーの permissions をオーバーライドすることでクライアント側でかなり進めることができ、サーバー側では NewPostManager.add_handler を使用して追加のチェックを行うことができると思います。

「いいね！」 3
12

グループの使用を検討しましたか？アクセス用に2つのグループを持つカテゴリを作成します。1つのグループはカテゴリのモデレーターです。もう1つはサブフォーラムの参加者です。参加者グループは、サブフォーラムエリアへのアクセスをリクエストする必要があります。あなたのカテゴリモデレーターの一部またはすべてがそのグループのオーナーです。メンバーがサブフォーラムからキックされる必要があるルールを破った場合。参加者グループからキックし、他のカテゴリモデレーターと期間についてコミュニケーションを取ります。

13

それでしたら、残念ながらプラグインのスポンサーになることを検討する必要があるかもしれません。ここで、プラグインのクラウドファンディングという素晴らしいコンセプトが活かされるでしょう。コアチームは最終的にあなたが求めているようなものを追加するかもしれませんが、開発リストの優先順位により時間がかかる可能性があります。

一方で、グループの提案があれば、グループからのキックアウトオプションを追加するテーマコンポーネントで可能かもしれません。

14

本当に正しい質問をしたか確認してください :wink:

あなたの主な目標は1つの問題を解決することであり、カテゴリ禁止はその未解決の答えにすぎません。正しい質問は「Xの問題をどのように解決し、どのような選択肢がありますか」ということです。

「いいね！」 1
15

TLまたはユーザーグループでこれを管理する可能性を評価しましたが、モデレーターの作業負荷が増加するため、大規模なコミュニティでは現実的ではありません。

特にユーザーグループは、リーンなユーザーエクスペリエンスにとって有害です。

私はソフトウェアエンジニアとしての豊富な経験と、同様に豊富な経験を持つ他の人々がいるため、スポンサーシップを求める必要はありません。私たちは単にRubyを使用しないため、それが唯一の遅延要因となります。

いずれにせよ、ご意見ありがとうございます。このフォーラムは非常に意見が分かれる傾向があることは理解していますが、ソフトウェア自体に関しては、「オプションを提供する」というアプローチに従う方が良いでしょう。もちろん、コード的には複雑さが増しますが、それは別の話です。

洞察を加えてくれた@RGJに感謝します :heart:

「いいね！」 3