スパマーをレビューキューから削除する際に、中央データベースからも削除するためにウェッブフックを使用したいと考えていますが、以下のようにウェッブフックを設定してもイベントがトリガーされません。これは仕様でしょうか、それとも「ステータスが更新されたとき」という部分の理解が間違っているのでしょうか？
「いいね！」 1
「ユーザー削除」のウェブフックはトリガーされますか？
「いいね！」 3
はい、その通りです。残念ながら削除が渡されていないため、ユーザーが削除されかつIPがブロックされた場合のみ、具体的に動作させたいと考えています。
「いいね！」 1
TL0ユーザーのフラグ付き投稿について、デフォルトで画像を自動的に非表示にする機能を追加してほしいです。各コミュニティの基準に従って不適切な画像を確認し、対応する必要があることは理解していますが、オフィス環境や自宅（子供がいる場合など）で作業している場合（私自身もよくあります）、画像を非表示にできるとうれしいです。
「いいね！」 6
「レビューキューのスコアリングを必要とするバイパス」のための API は、スコアが定期的に再計算されるため、長期的には依然として不十分です。レビュー可能アイテムが作成された時点でキューが処理されないと、「強制」されたアイテムはモデレーターがそれらをレビューする前に、高フィルタリングされたリストから消えてしまう可能性があります。
おそらく、ここではスコアクエリに結合されるレビュー可能アイテムに対して、強制的なレビューを示すブール値を追加すべきでしょう。
「いいね！」 5
TL0 ユーザーの画像はデフォルトでぼかされています。これは blur_tl0_flagged_posts_media 設定を無効化することで解除できます。
これも実装済みです。force_review フラグが true に設定されている場合、最小表示閾値スコアを満たしていなくても、保留中のレビュー対象がキューに表示されます。
「いいね！」 8
@Roman - まだ返信できておらず、申し訳ありません。もしまだ参考になるようであれば、ログを抽出し、個人を特定できる情報を除去した記録を準備しました。現在は 2.6.0beta3 で稼働しています。整数範囲外のエラーはすべて同じ種類のレコードで発生しているようです。
2020-11-26 06:02:13.009 UTC [25408] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.009 UTC [25408] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17769856,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.008758', '2020-11-26 06:02:13.008758', 1333533, 4) RETURNING "id"
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.038 UTC [29728] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17725230,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.037676', '2020-11-26 06:02:13.037676', 1313715, 38) RETURNING "id"
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.052 UTC [27579] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 1533, '{"topic_title":"{private info removed}","original_post_id":17713480,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.051222', '2020-11-26 06:02:13.051222', 1314869, 237) RETURNING "id"
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.149 UTC [27554] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 180552, '{"topic_title":"{private info removed}","original_post_id":17713479,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.148264', '2020-11-26 06:02:13.148264', 1313773, 48) RETURNING "id"
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse ERROR: integer out of range
2020-11-26 06:02:13.170 UTC [28970] discourse@discourse STATEMENT: INSERT INTO "notifications" ("notification_type", "user_id", "data", "created_at", "updated_at", "topic_id", "post_number") VALUES (9, 46891, '{"topic_title":"{private info removed}","original_post_id":17760644,"original_post_type":1,"original_username":"{private info removed}","revision_number":null,"display_username":"{private info removed}"}', '2020-11-26 06:02:13.168959', '2020-11-26 06:02:13.168959', 1328670, 25) RETURNING "id"
「いいね！」 1
また、モデレーターがフラグを処理した内容でフィルタリングされた、処理済みのレビュー対象の一覧を表示する機能があると便利かもしれません。「過去に処理されたフラグ」を確認する際に「割り当て先」でフィルタリングするのは、意味的には「処理担当者」でフィルタリングすることと非常に似ていますが、実際には異なります。
「割り当て先」でフィルタリングする際に、解決済みのフラグやレビュー対象に対して「フラグを処理した担当者」を照会すべきでしょうか、それともこれは別のフィルタとして扱えるでしょうか？
「いいね！」 4
これは素晴らしい提案だと思います、@Roman - リストに追加してもらえませんか？
「いいね！」 5
Webhook と API を使用して、新規トピックをレビューキューに追加し、モデレーターがコンプライアンスを確認できるようにしています。現在、API を使って新規トピックの最初の投稿をフラグ付けしていますが、これは機能するものの、ユーザーの管理履歴を表示した際に悪い印象を与えてしまいます。ユーザーに悪印象を与えない別の方法はあるでしょうか？
「いいね！」 1
「信頼レベルが一定以上でない限り新規トピックを承認する」という設定を使えない理由はありますか？これは Discourse に標準で搭載されています。
「いいね！」 2
多くのユースケースではそれが機能すると私も同意します。私たちは複数のタググループからのタグを必須としていますが、それはDiscourseではサポートされていません。新しいトピックを承認なしで公開しつつ、時間が許す限りタグが正しいことを確認したいと考えています。
私が提案したいのは、レビューキューに任意のアイテムを配置する方法です。現在サポートされているタイプは3つあります：フラグ付き投稿、キューイングされた投稿、およびユーザーです。私たちはフラグ付き投稿を流用していますが、それは私たちが求めているものに最も近いからです。しかし、APIからのみ可能だとしても、「タグのレビュー」アイテムをレビューキューに配置できるとよいでしょう。
「いいね！」 1
やりたいことを簡単に実現する方法はありません。
最も良い方法は、新しいレビュー可能なタイプを追加するプラグインを作成し、それらを作成するための何らかのエンドポイントを用意することです。
「いいね！」 1
私は同じ問題についてここに投稿しています: https://meta.discourse.org/t/account-rejection-email/103112/11。
「いいね！」 3
APIを介して「User」型のレビュー対象をレビューキューに追加する方法はありますか？それとも、新しいユーザーを作成するコードからのみアクセス可能でしょうか？
私のユースケースは、モデレーターがポリシーに準拠しているか確認できるよう、ユーザーの更新内容をレビューさせることです。そのため、user_updated ウェブフックを用意し、更新されたユーザーをレビューキューに追加したいと考えています。
手動でポストをフラグ付けし、ネットワークトラフィックを監視することで、ポストのフラグ付け方法（/post_actions…）をリバースエンジニアリングすることはできましたが、User に対して同様の操作を行う方法はわかりません。おそらく /user_actions… のようなエンドポイントがあるのではないかと想像しています。
「いいね！」 1
現時点では、この処理を API 経由で行う方法はありません。ユーザーの更新をインターセプトしてレビュー可能なエントリを作成するプラグインを追加する必要があると思います。
「いいね！」 2
2件の投稿が新しいトピックに分割されました: 投稿承認への対応
こんにちは。レビューキューに対する建設的な批判として、このフィードバックをお送りします。
「拒否/承認」ボタンについて、曖昧さを減らすための改善が行われたことは承知しています（「投稿を承認するのか、それともフラグを承認するのか？」）。しかし、これらのステータスには依然として二重の意味があり、すでに処理されたアイテムのリストを確認する際に非常に混乱します。なぜなら、ステータスフィルターと右上のステータスは、実際には何も意味をなさないからです。以下に例を挙げます。
タイピングが速すぎるという理由でフラグが立てられた投稿を承認 → 投稿承認済み → ステータス：承認済み
不適切な投稿に対するフラグを承認 → 投稿拒否 → ステータス：承認済み
プロフィールのスパム行為でユーザーを拒否 → ユーザー停止処分 → ステータス：拒否済み
投稿に対するフラグを拒否 → 投稿はそのまま → ステータス：拒否済み
したがって、以下のステータスを区別する必要があるようです。そして、いくつかのアイテムは両方を持つ可能性があります。
- ユーザー/投稿承認済み
- ユーザー/投稿拒否済み
--- - モデレーション承認済み
- モデレーション拒否済み
ユーザープロフィールのスパマーの場合の改善提案ですが、アカウントを削除し、メールアドレスをブロックするオプションを希望します。ただし、IPアドレスはブロックしないでください。なぜなら、それらはしばしば、正規のユーザーも使用する可能性のある共有IP範囲を使用しているからです。
「いいね！」 1