ユーザー削除アクションは、フラグの種類によって異なるトップレベルボタンにあります。Delete ボタンに常に「ユーザー削除」サブアクションがあるとうれしいですね。
ちなみに、手動でフラグが付けられたレビューから削除するとスクリーニングリストに URL が追加されますが、ユーザーが投稿しすぎたレビューからの削除では追加されません。
プライベートメッセージ内の投稿のフラグ付けに関連して、奇妙なことがいくつか発生しました。メッセージには2人の参加者がいます（私と、現在オンボーディング中の新しいモデレーターです）。フラグ付け機能をテストしていた際、彼女が自分の投稿をフラグ付けしました。その結果、私たちが両方とも「メッセージがスパムとしてフラグ付けされたため、編集して修正してください」という通知を受け取りましたが、投稿内でフラグ付けアクションを直接取り消すことはできませんでした。また、レビューキューにも表示されませんでした。
投稿が非表示になっている間、投稿の管理レンチアイコンを選択しましたが、何らかの理由で投稿コンテンツの背後にあり、使用できませんでした。スクリーンショットをご覧ください。
投稿を編集した際にのみ、非表示が解除されました。
したがって、以下のいくつかの問題が発生しています：
- 投稿の管理レンチメニューが正しく機能していない
- 私たち両方がモデレーター警告を受け取った
- 投稿がレビューキューに追加されなかった
- 私たち両方がモデレーターであるにもかかわらず、フラグ付けアクションを取り消すことができなかった
- モデレーターの投稿をスパムとしてフラグ付けすることは可能なのか？モデレーターが自分の投稿をスパムとしてフラグ付けすることは可能なのか？また、誰でも自分の投稿をスパムとしてフラグ付けできるべきなのか？
「いいね！」 2
ここでの改善にとても満足しています！ようやく考えを整理し、少しフィードバックをまとめられる機会ができました：
- 割り当てフィルター - 有効になっている場合、割り当て先（assignee）の追加フィルターがあると良いでしょう。報告者（reporter）のフィルターも追加できるとより良いかもしれません。
- 現在、「ユーザー」フィルターは通報された投稿の作成者で絞り込んでいますが、上記の点により少し曖昧です。
- 関連して、割り当てプラグインとの統合をもう少し改善する必要があるかもしれません。レビュー項目を割り当てても、プラグイン内の「割り当て済み」トピック一覧には表示されません。
- レポート - ここに追加すると良い項目として、日付範囲で絞り込んだり、日付範囲にわたるレビュー項目をエクスポートできる機能があります。これは、新しいモデレーターがどのようにレビューを扱っているかの過去の傾向を把握するのに役立つかもしれません。
「いいね！」 11
追加すべきもう一つの機能：再フラグされたアイテムが、投稿内容が編集または何らかの変更が加えられない限り、レビューキューに再表示されないようにする。これにより、新しいフラグアイテムは自動的に無視され、通知や投稿の非表示もできなくなる。
このアイデアの背景には、どこかのモデレーターがすでにそのフラグを確認して対応済みであるという前提がある。そのため、同じタイプの新しいフラグアイテムも同様に処理されるべきである。
ただし、上記には一点の注意点がある。新しいフラグを自動解決するのではなく、単に無視するべきだろう。なぜなら、フラグが実際に「同意して保持」として処理された場合、その処理方法をそのまま自動解決に適用してしまうと、フラグの乱用者が「同意して保持」で処理されたものを再フラグすることで、自身のフラグスコアを不当に引き上げるという意図しない副作用が生じる可能性があるからだ。
「いいね！」 9
なるほど、その点は確かにその通りですね。補足すると、私が承認した投稿が後から Akismet によってスパムとしてフラグ付けされることがよくあります。これも本来あってはいけないことだと思います。
「いいね！」 4
その通りです。必要に応じてプラグインが上記の提案を上書きできる機能は残すべきかもしれませんが、この場合、Akismet がそうすべきではないという点には同意します。これは Akismet プラグイン側の問題かもしれませんが、非常に重要な指摘ですね。
「いいね！」 5
これはプラグインの問題ですので、修正を適用します。
これについてはすでに調査を開始しています。新しいフラグを無視し、自動解決しないようにする必要があることに同意します。レビュー済みの投稿に対して再フラグ付けを試みた際にエラーメッセージを表示することを検討していました。
また、同じ理由で、ユーザーが投稿を再フラグ付けできるまで 24 時間程度待機させるべきだと考えています。
「いいね！」 12
最新の保留中の項目はすべて「すべて表示」メニューにあるため、「レビュー」タブは「トピック別」メニューではなく、その「すべて表示」メニューにリダイレクトされるべきです。
「いいね！」 5
reviewable default topics は設定されていますか？これにより、デフォルトがすべてのアイテムではなくトピックに設定されてしまいます。本来のデフォルトはすべてのアイテムであるべきです。
「いいね！」 6
「いいね！」 7
Discourse 2.4.0.beta11 Release Notes によると：
審査キューに送信される疑わしいユーザー
投稿を1件以下、トピックを1件以下しか閲覧していないが、自己紹介欄をカスタマイズした疑わしいユーザーは、現在、審査キューに送信されます。このようなユーザーはスパマーである可能性が高く、多くのユーザーは自己紹介欄を記入する前にサイトを閲覧するためです。
私たちの環境ではこの動作が発生しません。新しい疑わしいユーザーは通常通り /admin/users/list/suspect に表示されますが、審査キューには現れません。これは何らかの設定に依存するのでしょうか？
「いいね！」 1
はい、この機能は「容疑ユーザーの承認」設定に依存します（デフォルトでは無効になっています）。
「いいね！」 9
素晴らしい、今は正常に動作しています（リリースノートにこのような情報を追加すべきかもしれません）。
ただ、レビュープロセスをより迅速に進めるための小さなリクエストがあります。ウェブサイト欄にリンクを貼っていただけないでしょうか？現在、私たちはそれをコピー＆ペーストする必要があり、それが作業を大きく遅らせています。
「いいね！」 1
それはユーザーが追加したフィールドのようですね。残念ながら、それらが URL かどうかは判断できません。
「Web サイト」フィールドですか？あれはカスタムフィールドではありません（ここ Meta の場合と同じです）。他の 2 つはカスタムフィールドですが、それらをホットリンクする必要はありません。
「いいね！」 2
標準のウェブサイトフィールドがホットであるのは当然ですね。クリック数の追跡機能があればさらに素晴らしいでしょう。
テーマコンポーネントを使って、カスタムフィールドをクリック可能にできるはずです。
ダブルクリック、Control-C、Control-T、Control-V、Enter
「いいね！」 1
すいません！Meta で確認したところ、私が確認したユーザーにはウェブサイトが登録されていませんでした。さらに、そのすぐ下にある他のユーザーフィールドに混乱してしまいました。レビューを容易にするため、ウェブサイトへのリンクを追加します：
「いいね！」 12
もう少し考えてみたところ、小規模なサイトであれば24時間の冷却期間も問題ないと思いますが、大規模なサイトではユーザーがモデレーターを圧倒してしまう可能性が依然としてあると懸念しています。
フラグ付け不能な期間を可変にすること、あるいは少なくともプラグインからターゲット設定できるようにすることについて、どうお考えですか？モデレーターへの潜在的な負担を軽減できることは、すべて勝利だと考えます。
別の無関係な問題として、信頼度の高いユーザーは「モデレーター」的な権限を持っていると見なされ、単一のフラグで投稿を非表示にできる可能性があります。投稿を非表示にするための旧来の最小フラグ数オプションを維持することが望ましいかもしれません。そうすれば、コミュニティの単一のメンバーが検閲者として行動することを防げます。
「いいね！」 8
はい、多くのやり取りを経て、最低数の再導入には反対しません。ただし、@featheredtoast の顧客が他の調整を試した上で、これが本当に役立つことを確信していることを確認したいです。
@Roman、その24時間のウィンドウを設定可能にすることはできますか？
「いいね！」 7
完了しました：
high_trust_flaggers_auto_hide_posts 設定で有効または無効にできます。
cooldown_hours_until_reflag 設定（デフォルトは 24 時間）で構成できます。
「いいね！」 6