The delete user action is found under different top level buttons depending on the type of flag. It would be nice if the Delete button always had a delete user sub action.
And btw, URLs are added to the screened list if you delete from a manually flagged review, just not from user posted too fast reviews.
I just had some odd things happen relating to flagging of a post in a personal message. Two people are in the message (myself and a new moderator I am in the process of onboarding). We were testing out flagging, and she flagged one of her own posts. Both of us received the notification that our message was flagged as spam and that we should edit and fix it, and neither of us could directly reverse the flagging action directly in the post. It also did not show up in the review queue.
While the post was hidden, I selected the post admin wrench but was unable to use it because it was somehow behind the post content. See screenshot.
Only when I edited the post did it get unhidden.
So… several issues:
I’ve been loving the improvements here - I’ve finally had a chance to collect my thoughts and accumulate a bit of feedback about this:
追加すべきもう一つの機能：再フラグされたアイテムが、投稿内容が編集または何らかの変更が加えられない限り、レビューキューに再表示されないようにする。これにより、新しいフラグアイテムは自動的に無視され、通知や投稿の非表示もできなくなる。
このアイデアの背景には、どこかのモデレーターがすでにそのフラグを確認して対応済みであるという前提がある。そのため、同じタイプの新しいフラグアイテムも同様に処理されるべきである。
ただし、上記には一点の注意点がある。新しいフラグを自動解決するのではなく、単に無視するべきだろう。なぜなら、フラグが実際に「同意して保持」として処理された場合、その処理方法をそのまま自動解決に適用してしまうと、フラグの乱用者が「同意して保持」で処理されたものを再フラグすることで、自身のフラグスコアを不当に引き上げるという意図しない副作用が生じる可能性があるからだ。
なるほど、その点は確かにその通りですね。補足すると、私が承認した投稿が後から Akismet によってスパムとしてフラグ付けされることがよくあります。これも本来あってはいけないことだと思います。
その通りです。必要に応じてプラグインが上記の提案を上書きできる機能は残すべきかもしれませんが、この場合、Akismet がそうすべきではないという点には同意します。これは Akismet プラグイン側の問題かもしれませんが、非常に重要な指摘ですね。
これはプラグインの問題ですので、修正を適用します。
これについてはすでに調査を開始しています。新しいフラグを無視し、自動解決しないようにする必要があることに同意します。レビュー済みの投稿に対して再フラグ付けを試みた際にエラーメッセージを表示することを検討していました。
また、同じ理由で、ユーザーが投稿を再フラグ付けできるまで 24 時間程度待機させるべきだと考えています。
最新の保留中の項目はすべて「すべて表示」メニューにあるため、「レビュー」タブは「トピック別」メニューではなく、その「すべて表示」メニューにリダイレクトされるべきです。
reviewable default topics は設定されていますか？これにより、デフォルトがすべてのアイテムではなくトピックに設定されてしまいます。本来のデフォルトはすべてのアイテムであるべきです。
Discourse 2.4.0.beta11 Release Notes によると：
審査キューに送信される疑わしいユーザー
投稿を1件以下、トピックを1件以下しか閲覧していないが、自己紹介欄をカスタマイズした疑わしいユーザーは、現在、審査キューに送信されます。このようなユーザーはスパマーである可能性が高く、多くのユーザーは自己紹介欄を記入する前にサイトを閲覧するためです。
私たちの環境ではこの動作が発生しません。新しい疑わしいユーザーは通常通り /admin/users/list/suspect に表示されますが、審査キューには現れません。これは何らかの設定に依存するのでしょうか？
はい、この機能は「容疑ユーザーの承認」設定に依存します（デフォルトでは無効になっています）。
素晴らしい、今は正常に動作しています（リリースノートにこのような情報を追加すべきかもしれません）。
ただ、レビュープロセスをより迅速に進めるための小さなリクエストがあります。ウェブサイト欄にリンクを貼っていただけないでしょうか？現在、私たちはそれをコピー＆ペーストする必要があり、それが作業を大きく遅らせています。
それはユーザーが追加したフィールドのようですね。残念ながら、それらが URL かどうかは判断できません。
「Web サイト」フィールドですか？あれはカスタムフィールドではありません（ここ Meta の場合と同じです）。他の 2 つはカスタムフィールドですが、それらをホットリンクする必要はありません。
標準のウェブサイトフィールドがホットであるのは当然ですね。クリック数の追跡機能があればさらに素晴らしいでしょう。
テーマコンポーネントを使って、カスタムフィールドをクリック可能にできるはずです。
ダブルクリック、Control-C、Control-T、Control-V、Enter
すいません！Meta で確認したところ、私が確認したユーザーにはウェブサイトが登録されていませんでした。さらに、そのすぐ下にある他のユーザーフィールドに混乱してしまいました。レビューを容易にするため、ウェブサイトへのリンクを追加します：
もう少し考えてみたところ、小規模なサイトであれば24時間の冷却期間も問題ないと思いますが、大規模なサイトではユーザーがモデレーターを圧倒してしまう可能性が依然としてあると懸念しています。
フラグ付け不能な期間を可変にすること、あるいは少なくともプラグインからターゲット設定できるようにすることについて、どうお考えですか？モデレーターへの潜在的な負担を軽減できることは、すべて勝利だと考えます。
別の無関係な問題として、信頼度の高いユーザーは「モデレーター」的な権限を持っていると見なされ、単一のフラグで投稿を非表示にできる可能性があります。投稿を非表示にするための旧来の最小フラグ数オプションを維持することが望ましいかもしれません。そうすれば、コミュニティの単一のメンバーが検閲者として行動することを防げます。
はい、多くのやり取りを経て、最低数の再導入には反対しません。ただし、@featheredtoast の顧客が他の調整を試した上で、これが本当に役立つことを確信していることを確認したいです。
@Roman、その24時間のウィンドウを設定可能にすることはできますか？
完了しました：
high_trust_flaggers_auto_hide_posts 設定で有効または無効にできます。
cooldown_hours_until_reflag 設定（デフォルトは 24 時間）で構成できます。
