こんにちは皆さん、
Discourseで特定の機能を実現するためのガイダンスを探しています。私が管理しているコミュニティでは、ユーザーが過去14日以内に2つの特定のカテゴリのいずれかに投稿した場合、新しいトピックを作成できないようにするルールを実装する必要があります。この制限は、以前のトピックが削除された場合でも適用されるべきです。
いくつかの調査の結果、discourse-flexible-rate-limits プラグインを見つけました。これは良い出発点になるかもしれませんが、ユーザーグループとアクションに基づいた柔軟なレート制限を可能にしますが、短期的な頻度(分、時間、日)に焦点を当てており、直接サポートしていません。
- 複数のカテゴリにまたがる投稿を確認すること。
- 14日という長期間の制限を強制すること。
- 削除されたトピックをチェックに含めること。
このプラグインをカスタマイズしたり、ゼロから何かを作成したりする前に、お伺いしたいことがあります。
- このような機能がすでに処理されている既存のプラグインや方法はありますか?
discourse-flexible-rate-limits のような既存のプラグインを変更して、カテゴリをまたぐ長期的な制限を含めるための推奨されるアプローチはありますか?
- これを効果的に実装するための一般的なアドバイスはありますか?
この素晴らしいコミュニティからの洞察や提案をいただけると幸いです。もし関心があれば、実装方法についてのアップデートを共有することも喜んで行います。
前もって感謝いたします!
pfaffman
(Jay Pfaffman)
2
よく理解できていないかもしれませんが、ユーザーが特定のカテゴリ(トピック作成フックを使用)で投稿したときにグループから削除し、その後、そのカテゴリでの最後のトピックから数日後にグループに再度追加するジョブを毎日実行するプラグインが必要だと考えているのではないでしょうか。
おそらく3〜5時間程度の作業で、仕様/テストが良好であればもう少し時間がかかるかもしれません。
「いいね!」 2
こんにちは、@pfaffman さん、ホリデーシーズンおめでとうございます。返信ありがとうございます!
状況を明確にするためにフローチャートを作成してみました。
flowchart TB
A0(ユーザーがカテゴリAまたはBで新しいトピックを作成しようとする) --|> A1{ユーザーは免除グループ<br>(管理者、モデレーター、TL3、TL4、購読者)に<br>属していますか?}
A1 -- いいえ --> B1(カテゴリA、B、またはCでの<br>ユーザーの最後のトピックを確認<br>(非表示または削除されたレコードを含む))
A1 -- はい --> Z1(投稿を許可)
B1 --> B2{その最後のトピックは<br>14日以内に作成されましたか?}
B2 -- はい --> C1(投稿をブロック + エラー表示<br>クールダウン表示<br>ルールへのリンク)
C1 --> E1(下書きを保存 +<br>送信ボタンを無効化) ---> End(終了)
B2 -- いいえ --> D1(投稿を許可)
D1 --> End(終了)
Z1 --> End(終了)
簡単な仕様書も作成してみました
flowchart TB
A0(ユーザーがカテゴリAまたはBで新しいトピックを作成しようとする) --|> A1{ユーザーは免除グループ<br>(管理者、モデレーター、TL3、TL4、購読者)に<br>属していますか?}
A1 -- いいえ --> B1(カテゴリA、B、またはCでの<br>ユーザーの最後のトピックを確認<br>(非表示または削除されたレコードを含む))
A1 -- はい --> Z1(投稿を許可)
B1 --> B2{その最後のトピックは<br>14日以内に作成されましたか?}
B2 -- はい --> C1(投稿をブロック + エラー表示<br>クールダウン表示<br>ルールへのリンク)
C1 --> E1(下書きを保存 +<br>送信ボタンを無効化) ---> End(終了)
B2 -- いいえ --> D1(投稿を許可)
D1 --> End(終了)
Z1 --> End(終了)
フローの説明
-
A0: ユーザーがカテゴリ A または B で新しいトピックを作成しようとします。
-
A1: システムは、ユーザーが免除グループに属しているかどうかを確認します。
- 管理者
- モデレーター
- トラストレベル3(TL3)
- トラストレベル4(TL4)
- カスタム「購読者」グループ
- はいの場合、クールダウンチェックをスキップしてすぐに投稿を許可します(Z1)。
- いいえの場合、B1に進みます。
-
B1: システムは、ユーザーがカテゴリA、B、またはCで最後に作成したトピックを取得します。この検索には以下を含める必要があります。
- ソフト削除されたトピック(データベースから完全に削除されていないもの)。
- 非表示またはコンプライアンスカテゴリ(例:カテゴリC)に移動されたトピック。
-
B2: システムは、その最後のトピックの作成日が過去14日以内であるかどうかを確認します。
- はい → C1に進みます(投稿はブロックされます)。
- いいえ → D1に進みます(投稿は許可されます)。
-
C1: システムは、ユーザーがまだクールダウン中であることを通知するエラーメッセージを表示します。メッセージには以下を含める必要があります。
- まだ投稿できないという簡単な声明。
- 残りの時間(日数と時間)(分は不要)。
- コミュニティルールページへのリンク(以下に提供)。
-
E1: エラー表示後、ユーザーのコンテンツは自動的に下書きとして保存され、「送信」または「トピックの作成」ボタンは無効になります。
-
D1: ユーザーの最後のトピックから14日以上経過している場合、システムは新しいトピックの投稿を許可します。
-
Z1: ユーザーは免除グループに属しているため、制限なく投稿できます。
2. 詳細仕様
2.1 制限グループ vs. 免除グループ
- 制限グループ:
- 以下の免除グループに属していないすべてのユーザー(通常はTL0、TL1、TL2)。
- 免除グループ:
- 管理者
- モデレーター
- トラストレベル3(TL3)
- トラストレベル4(TL4)
- 購読者(カスタムグループ)
これらの免除グループは、14日間のチェックを完全にスキップします。
2.2 対象カテゴリ
- 新規トピック試行:
- ユーザー(制限グループに属する)がカテゴリAまたはBで新しいトピックを作成しようとしたときにトリガーされます。
- 最後のトピックチェック:
- システムは、ユーザーがカテゴリA、B、またはCで作成した最後のトピックをチェックします(Cは「非表示」または「コンプライアンス」カテゴリ)。
注意: カテゴリCは、ユーザーのトピックが削除/非表示/コンプライアンスのために移動された状況を捕捉するために含まれています。ユーザーが過去14日以内にカテゴリCでトピックを作成した場合も、クールダウンの対象となります。
2.3 14日間クールダウンロジック
- ユーザーの最も最近のトピック(A/B/Cのいずれか)が14日以内に作成された場合、AまたはBでの新規トピック作成をブロックします。
- 14日以上経過した場合、許可します。
時間計算
- 残りの時間を日数と時間で表示します(例:「残り3日12時間」)。
- 分や秒を表示する必要はありません。
2.4 ブロックと下書き保存
2.5 将来の柔軟性
- 追加カテゴリ:
- 現在、A、B、Cのみが設定されています。
- 将来的にこのクールダウンからカテゴリを追加または削除する必要がある場合は、システムまたはプラグインが大幅なコード変更なしに拡張可能であることを確認してください。
- 異なる期間:
- 14日間の期間は、プラグインの設定で構成可能にできます(7日、30日などが必要な場合)。
- 動的なグループ割り当て:
- 免除グループの追加または削除(例:「購読者」を追加したり削除したりする場合)はサポートされるべきです。
3. まとめ
- 制限グループ(TL0、TL1、TL2、または免除グループに属していないユーザー)は、カテゴリAまたはBで別のトピックを作成する前に14日間のクールダウンの対象となります。
- 免除グループ(管理者、モデレーター、TL3、TL4、「購読者」)は、制限なく投稿できます。
- システムは、カテゴリA、B、またはC(ソフト削除または非表示を含む)での最も最近のトピック作成をチェックします。それが14日以内に作成された場合、新しいトピックはブロックされます。
- エラーメッセージ: 日数/時間で残りの時間を表示し、コミュニティルールへのリンクを表示します:
- 下書き: ブロックされた場合、ユーザーの投稿は下書きとして保存され、送信ボタンは無効になります。
- この仕様は、将来的に追加のカテゴリや異なる期間に拡張できます。
何か提案があれば教えていただけると幸いです!
「いいね!」 1
pfaffman
(Jay Pfaffman)
4
それがまさに私が考えていたことです。私の解決策は、それらがそれらのカテゴリに投稿することを許可するグループから削除することです。これにより、投稿できないことがすぐに明確になり、投稿の仕組みを変更する特別なコードは必要ありません。
「いいね!」 3
なるほど、あなたの解決策が理解できました。
そのアプローチは単純に見えるかもしれませんが、以下の点が懸念されます。
-
閲覧権限 vs. 投稿権限
- 現在、TL1(またはそれ以上)のユーザーは、カテゴリAおよびBで閲覧と投稿の両方が可能です。
- 14日ルールに違反したユーザーをTL1から削除すると、閲覧権限も失ってしまいます。しかし、私たちは彼らを投稿からブロックしたいだけで、閲覧からブロックしたいわけではありません。
-
グループの分割が必要
- 「閲覧はできるが投稿できない」シナリオを解決するには、複数のサブグループを作成する必要があります。
- TL1 limited – AまたはBで閲覧と返信は可能ですが、トピックの作成はできません。
- TL1 full – 閲覧、返信、トピックの作成が可能です。
- ユーザーが14日ルールに違反した場合、TL1 fullからTL1 limitedに移動させることになります。これはより複雑に思えます。
-
自動化の複雑さ
- グループを分けたとしても、クールダウン期間が終了したら、ユーザーを自動的に「full」グループに戻す必要があります。
- これは、14日期間がいつ終了するかを計算し、TL1 limitedからTL1 fullにユーザーを再割り当てするロジック(例:スケジュールジョブやカスタムコード)を実装する必要があることを意味します。
- プログラマーではないため、このような複雑な自動化を自分で処理する自信がありません。
言い換えれば、特定のグループからユーザーを削除することで投稿ロジックを直接変更することを回避できるかもしれませんが、追加のグループと複雑なルールが生じます。私たちは14日間だけ投稿を制限したいのであって、閲覧権限やその他の特権を制限したいわけではありません。
何か提案やアイデアがあれば、どうぞよろしくお願いします。Discourse APIやn8nのWebhookを介して統合を試みましたが、コーディングの経験が限られているため、非常に困難でした。