これはバグのようですが、再現方法がわかりません。
次のような通知(PM)を受け取ります。
しかし、「確認する」リンクをクリックしても、保留中のユーザーはいません。 /admin/users では、メールアドレスを検証していないユーザーがいくつか表示されます。
通知が間違った数を生成しているのか、承認待ちのユーザーが検索しても表示されないのか、あるいはメールを検証していないユーザーが承認待ちとして通知にはカウントされるが、承認にはカウントされないのか、どちらとも判断できません。
これはバグのようですが、再現方法がわかりません。
次のような通知(PM)を受け取ります。
しかし、「確認する」リンクをクリックしても、保留中のユーザーはいません。 /admin/users では、メールアドレスを検証していないユーザーがいくつか表示されます。
通知が間違った数を生成しているのか、承認待ちのユーザーが検索しても表示されないのか、あるいはメールを検証していないユーザーが承認待ちとして通知にはカウントされるが、承認にはカウントされないのか、どちらとも判断できません。
お節介かもしれませんが、allow_new_registrations はチェックが外れていますか? must_approve_users 設定が有効になっていることは明らかですが、登録が無効になっている場合にそれがどのように影響されるかはわかりません。
アカウント作成を無効にするには、登録設定が優先されると思いますが。いや、それも意味が通らないな…
おそらく当たり前のことだと思いますので、ご協力いただけると幸いです。
はい、どちらもチェックされています。一部のユーザーは登録および承認されています。問題は、通知で主張されている数と、待機中と主張されている数が一致しないことです。5人と表示されたのに、過去数日間で2人しかいませんでした。
実に奇妙です。承認リクエストが送信された(カウントされた)後に、ユーザー登録の何かが拒否されているかのようです…
レビュー済みのアイテムをすべて表示したときにレビュー済みのユーザーが表示されるか、またはスタッフログから表示されるか? ![]()
レビュー対象アイテムがすでにレビュー済みで何も表示されないというPM/リマインダーをよく受け取ります。
私が(またはサイトの所有者が)それらに対応する前に、他の誰かがユーザーを承認したことが問題だと仮定しましたが、そのように数字を合わせることができません)。
登録が承認される前に、ユーザーはアカウントを削除できますか?
わからない? そうは思わない。なぜなら、それをするにはログインする必要があるが、承認されるまでログインできないからだ(ただし、コードなどを確認したわけではない)。
バグレポートを提出する前にこのトピックを見つけたので、追加します。
要約すると、通知のクエリが間違っています。なぜなら、拒否されたユーザーもカウントしているからです。
通知:承認待ちのユーザーが16人います。リンクをクリックすると、2人しか表示されません。
通知に使用されているクエリは次のとおりです。
puts AdminUserIndexQuery.new(query: "pending", stats: false).find_users_query.to_sql
SELECT "users".* FROM "users"
WHERE (suspended_till IS NULL OR suspended_till <= '2023-11-13 11:05:23.225614')
AND "users"."approved" = FALSE
AND "users"."active" = TRUE
ORDER BY users.created_at DESC,users.username
これは、私の場合は16人のユーザーを返します。
[4479, 4472, 4456, 4446, 4443, 4430, 4302, 4291, 4206, 4199, 4178, 4168, 4131, 4061, 3677, 3642]
これらのIDをReviewablesキューに渡すと、実際に承認が必要なユーザー(ステータス0)が2人、すでに拒否されたユーザー(ステータス2)が14人見つかります。
ReviewableUser.where(type: 'ReviewableUser')
.where(target_id: ids)
.pluck(:target_id, :status)
[[3642, 2], [3677, 2], [4061, 2], [4131, 2], [4168, 2],
[4178, 2], [4199, 2], [4206, 2], [4291, 2], [4302, 2],
[4430, 2], [4443, 2], [4446, 2], [4456, 2], [4472, 0], [4479, 0]]
本日、これについて誰かが苦情を言いました。これらすべてを見つける前に、私は問題を次のように「解決」しました。
bad=User.where(approved: false);
bad.each do |user| puts "https://community.open-emr.org/admin/users/#{user.id}/#{user.username}"; end;
これは、すべてのユーザーの管理者URLを出力するため、そこで承認または削除できると思います。
したがって、これはまだバグだと思います。
ああ、そしてその後:
ids=bad.pluck(:id);
ReviewableUser.where(type: 'ReviewableUser')
.where(target_id: ids)
.pluck(:target_id, :status)
これで、次のようなものが返されます。
=> [[4610, "rejected"], [4527, "rejected"], [4643, "rejected"], [4648, "rejected"]]
それでは、これらをReviewableUserから削除する必要があるのでしょうか?
それとも、ユーザーを削除するだけですか?
モデレーター(管理者ではない)として、フィルターされていないレビューキューで拒否されたユーザーを一覧表示できました。ただし、ユーザーセクションで見つけたり、レビューキューから拒否されたユーザーのユーザーエディターにアクセスしたりすることはできませんでした。
これは、レビューキューのフィルターパラメーターです。
https://gramps.discourse.group/review?additional_filters={}&sort_order=score&status=rejected&type=ReviewableUser
したがって、モデレーターは「拒否済み」および「承認ステータスなし」のユーザーをユーザータブで見つけられるようにするか、レビューキューからユーザーエディターに移動できるようにする必要があります。