If one wanted to write a plugin specific to the Review Queue (new users)
Is there a few hints you guys can provide on the getting started side of things?
End goal I want to provide a 3rd option to new users from Delete, Delete and Block I want a 3rd Custom option that will do other things.
I have looked through the getting started with plugins topic and that’s’ all well and good just looking on pointers on how to hook into the Review Queue
This is an interesting use case and I’d like to help you get it working.
Actions for reviewable types are returned from the build_actions method.
What I’d recommend is having your plugin open the ReviewableUser class and alias the build_actions method. In your version, get the actions from the method you aliased, then add your new action to the delete bundle.
That should work, although you might end up with some hacky looking code. I’d suggest once you get it working to post it here and we can see if we can tidy it up, and perhaps add internal APIs to help out improve it further.
Robin さん、
現在、Discord OAuth プラグイン（https://meta.discourse.org/t/discord-oauth2-plugin/67174）の PR を作成中です。主な目的は、Discourse に Discord ユーザーの情報をより多く保存することです。自動化された承認機能を実装している ReviewableUser モデルを活用して、既存の機能を維持しようとしています。
現在の実装では、新規ユーザーのレビューが非同期で開始されるため、そのようなレビューが作成されているかを確認し、クリアする必要があります。
しかし、非常に奇妙な Ruby エラーが発生しており、あなたがこのエラーに遭遇したことがあるかどうかわかりません。
コードは以下の通りです：
def after_create_account(user, auth)
super
data = auth[:extra_data]
if !user.approved && data[:auto_approve]
user.approved = true
user.approved_by_id = Discourse.system_user.id
if reviewable_user = ReviewableUser.find_by(target: user)
reviewable_user.set_approved_fields!(user, Discourse.system_user)
end
end
end
ReviewableUser.find_by が実行されるとすぐに、以下の例外が発生します：
*** NameError Exception: wrong constant name #<Class:0x000056134e417870>::DiscordAuthenticator
Ruby のスキルが向上していると思っていたのですが、なぜこのようなことが起こるのかがわかりません。
パスの問題でしょうか？いくつかの require を試しましたが、問題が雪だるま式に大きくなってしまいます。
これはコアコードの他の部分で見られる類似のパターンと非常に似ています。何かご助言があれば、大変感謝いたします！
必要であれば、リポジトリはこちらです：discourse-plugin-discord-auth/plugin.rb at master · merefield/discourse-plugin-discord-auth · GitHub
その常に表示されるエラーはあまり情報提供になっていませんね！これはおそらく Rails エンジンと名前空間に関係していると思います。試してみたい簡単な方法は、先頭に :: を付けて ::ReviewableUser とすることです。これにより、エンジン内ではなくルート名前空間を使用するようになります。
また、このコードは reviewable API に対してやや古めかしいようです。以下のように書くべきでしょう：
if !user.approved && data[:auto_approve] && reviewable = ::ReviewableUser.pending.find_by(target: user)
reviewable.perform(:approve, Discourse.system_user)
end
そのエラーは解消されました。以前、Class が見つからなかったため、定数として扱われていたのでしょうか？とにかく、これで解決しました。素晴らしい、本当にありがとうございます！これで先へ進めます！
私が以前に以下のようにしていた理由：
user.approved = true
user.approved_by_id = Discourse.system_user.id
を
reviewable.perform(:approve, Discourse.system_user)
としたのは、レビューキューへの追加が非同期であるためです。ジョブ内では、approve が false の場合のみレビューが作成されます（discourse/app/jobs/regular/create_user_reviewable.rb at 888e68a1637ca784a7bf51a6bbb524dcf7413b13 · discourse/discourse · GitHub
if user = User.find_by(id: args[:user_id])
return if user.approved?
@reviewable = ReviewableUser.needs_review!(
target: user,
created_by: Discourse.system_user,
reviewable_by_moderator: true,
payload: {
username: user.username,
name: user.name,
email: user.email
}
)
レビューエントリの存在をチェックした後でジョブが実行されるリスクはありませんか？
その結果、レビューエントリが存在しないように見えますが、ジョブは実行を待っている状態です。その後、ジョブが実行されてレビューエントリが作成され、そのコードが既に実行済みのため、それをクリアする機会を逃してしまいます。
これは潜在的なレースコンディションでしょうか？
レビューエントリをチェックする前に approved を true に設定すれば、この問題は解決します（これ以降は依存関係によりレビューが作成されることはありません）。
私はコードをテストする際にこの問題に遭遇しました。開発環境では動作しましたが、本番環境では異なる順序で実行されたために失敗しました。
なお、このユースケースをサポートするように設計されていないことは承知していますが、特別な状況（例えば、Discord プラグインのように、信頼されたギルドのメンバーである場合など）で新しいユーザーを自動的に承認できるようにすることは、プラグインにとって重要だと考えます。
確かに、レビュー対象レコードは非同期で作成されるため、この状況では問題となります。ログイン時にユーザーが作成されると、承認レコードが存在しない可能性があるからです。
より良い解決策としては、この状況ではレビュー対象を作成しないようにすることですが、そのためにはコア部分の変更が必要になります。以下のような動作が可能です：
skip_approval: true のようなフィールドを返すRobin さん、ありがとうございます。はい、その通りです。
現時点では、直接 API アクセスが削除される前に修正が必要であることを承知の上で、私の回避策を採用しました。
チーム側で、ユーザーの approve 書き込みアクセスが削除される前に、これを優先して対応する意向はありますか？
この変更は、私が直近に提出した PR がなくても、Auth Discord Login プラグイン内の現在の信頼された Guild の自動承認機能を壊すと考えています。@featheredtoast
もしその変更が実装されるのであれば、私の PR をその変更に対応するように更新することに喜んで協力します。
すぐには削除する予定はありません。永久にこれに依存するつもりはありませんが、当面は問題ないはずです。
キューは見やすく、「トピック別グループ化」も便利です。
ただし、私の知る限り、投稿をまとめて選択して処理する方法はありません。各投稿を個別に処理する必要があります。
まとめて選択して処理できれば、本当に時間を節約できるのですが！
素晴らしい機能追加だと思います。正直なところ、フラグキューには以前から一括操作が存在しなかったため、これは後退ではありません。
また、「停止」のような操作は、複数の行に対して行うと少し奇妙に感じられます。意味をなすためには、基本的な操作に限定する必要があります。
小さな問題が見つかりました。承認が必要なカテゴリに投稿があり、レビューキューに表示されています。投稿者が間違ったカテゴリに投稿してしまったため、レビューキューからカテゴリを変更しようとしたのですが、移動先のカテゴリには特定のタグが必須であり、そのタグは新しいカテゴリにのみ制限されているのに、レビューキュー内の投稿はまだ元のカテゴリ（そのタグを許可していない）にあると認識されているため、行き詰まってしまいました。投稿を承認した後にカテゴリとタグを変更するのは簡単ですが、これは修正すべき問題のように思えます。
これは修正されるべきものだと理解していますが、URL が依然としてスクリーニングリストに追加されていません。おそらく実際には問題ないでしょう。スクリーニング済み URL のアクションは「何もしない」となっていますから。ただ少し奇妙ですね。
正しいバージョンにアップグレードされたことを確認させてください。onebox 対応ではない場合や内部の場合は、スクリーニングされるはずです。
はい、v2.4.0.beta2 +66 です。次回発生したら、その投稿のコピーを作成します。
はい、「レビューキュー」で「ユーザーを削除」をクリックした後、メールアドレスとIPアドレスはスクリーニングリストに追加されましたが、URLは追加されませんでした。投稿内容は以下の通りです：
世界No.1の学術的ライティングサービスプロバイダーであるMyassignmenthelp.comで、オンラインの[学術的ライティングサービス](https://myassignmenthelp.com/uk/academic-writing-service.html)をご希望の方へ。学生向けに幅広いサービスを提供するプロの学術的ライティングサービスで、最良の価格を実現しています。
私の記憶では、URL は自動的にスクリーニング済みリストに追加されたことはありませんでした？まあ、追加されているようです。自分のインスタンスを確認したら、いくつかの URL が載っていました；)
ああ、思い出しました。それらは実際には何もしません。情報提供のみのものです。
そのドメイン名を監視単語リストに追加して入力不可にできますが、ご自身で設定する必要があります。
そのため、URL に自動アクションが適用されなくても、スパム投稿を把握できるようにするため、それらを監視リストに追加していただけると幸いです。なお、モデレーターはレビューキューを利用できますが、監視ワードの追加はできない（と思います）。
いくつかのUXに関するフィードバックです：レビューキューが私の設定を記憶してくれたら嬉しいです。私たちはモデレーターチームで活動しているため、個人的には新しいフラグを優先的に表示したいと考えており、ソート基準を「作成日時」に設定していますが、この設定が維持されません。
それは悪い提案ではありません。幸いなことに、現在は回避策があります。検索フィルターはクエリ文字列（URL）に保存されるため、フィルターをブックマークしておけば、いつでもその状態に戻ることができます。
