「ユーザー承認必須」の通知が、既存ユーザーによって誤ってトリガーされる

ここ数週間、問題のある(禁止された)ユーザーが不快または不適切なユーザー名でアカウントを作成していました。これを防ぐため、「スタッフは、すべての新規ユーザーアカウントがサイトにアクセスする前に承認する必要があります。」という設定をオンにしました。この設定により、確かにすべての新規アカウントの承認が必要になります。

しかし、非常に迷惑なことに、数時間ごとに、この設定が有効になるずっと前に、数か月または数年前に参加した古いユーザーの「承認待ちのユーザー」という通知が届きます。

通知をクリックすると、次のように表示されます。

承認(または拒否)待ちの新規ユーザーサインアップがあります。レビューしてからアクセスしてください。

しかし、「レビューしてください」をクリックしても、何も表示されません。

レビューするアイテムはありません。

admin/users/list/new のリストを検索すると、一部のユーザーが実際に「未承認」と表示されていることがわかります。これらの「未承認」ユーザーの間には、設定が切り替えられる前に作成されたという事実以外に、共通点を見つけることができません。一部のユーザーは「プライマリメール:未確認」であり、他のユーザーは確認済みです。

手動で各ユーザーを承認しようとしましたが、何百ページもスクロールする必要があり、リストを「未承認」でフィルタリングする簡単な方法が見つかりません。

既存のすべてのユーザーを「承認済み」としてマークする簡単な方法はありますか? または、少なくともこれらの古いユーザーに関する通知が送信されないようにすることはできますか?

「いいね!」 2

これにまだ苦しんでいますか?

結局、意を決してユーザーリスト全体を(「承認済み:いいえ」を持つものを手動で探して)スクロールし、各プロフィールに入力して個別に承認しました :sweat:

「いいね!」 2

私は同じような挙動に気づき、その理由を見つけたと思います(これらのユーザーがレビューキューに表示されない理由ではなく、そもそも承認されなかった理由です)。

私の理解では[1]、「must_approve_users」を有効にすると、設定が有効になる前に作成されたほとんどのユーザーは承認されるはずです。

これはほとんどのユーザーで機能しましたが、一部のユーザーは承認済みとしてマークされませんでした。

Data Explorer Query
SELECT
  id as UserID, approved
FROM
  users
ORDER BY id
UserID Approved
1 true
3 true
8 true
10 false
11 false
12 false
13 true

レビュー可能なテーブルを見ると、チャットメッセージのターゲットIDと一致するユーザーIDを持つユーザーが承認されていないことがわかります。

Data Explorer Query
SELECT id, target_id, target_type
FROM reviewables
ORDER BY target_id
id target_id target_type
6 9 ChatMessage
7 10 ChatMessage
8 11 ChatMessage
9 12 ChatMessage
1 2901 Post
2 2909 Post
5 2991 Post

ターゲットIDがあり、そのターゲットタイプが「user」以外である場合、ユーザーが承認されないのはバグだと思います。


  1. 私はプログラミングスキルをほとんど持っていません ↩︎

「いいね!」 3