Hi, I have had a problem that began several Discourse updates ago, with getting notifications that a new user is waiting for approval, only to find that the review queue is empty.
This only occurs when a single user is requesting approval. If multiple people are waiting, I can see all but one in the queue - but one is always not included.
A lot of people have been unable to sign up in other words.
In a separate thread it was suggested that the multi-select plugin might be somehow involved and causing Discourse to add one to the queue length.
On balance this seems unlikely, in that something must be occurring to trigger a notification on some days and not others. Also the issue did not begin when the plugin was installed - it commenced some months later, and I can only correlate this to a discourse update (since I don’t believe any another plugins or changes have been made since)
Has anyone else experienced this? And what might the solution be?
On the off chance, @jjaffeux is it possible the “FIX: makes value parsing more resilient” amendment you made to this plugin could be implicated this issue?
Hi - I am unclear as well, Could it be both?
The issue did not start when the plugin was first installed, but began a few core updates ago. If the plugin is involved at all, perhaps there is some unintended interaction?
I can’t really test uninstalling the plugin to see if the issue continues, as it is mission critical - vetting of user sign ups is dependent on the answers they can only provide with this plug-in active (users need to make selections from a drop down list).
I guess my first recommendation here would be to wait for the “bad state” … then enable safe mode for your browser and see if the queue looks good.
If it looks good in safe mode you probably want to post on marketplace to get the plugin converted to a theme component and updated to latest patterns from Discourse.
Unfortunately, same results in safe-mode - in response to a notification of pending users, there still is one missing from the queue to be reviewed even when I visit in discourse safe-mode with all three site customization items disabled.
Thanks Sam.
Very hard to identify exact steps - I am not sure what I have done that might be unusual, and I can not pin the onset of the issue to any specific event.
In my mind the main contenders are either a Discourse update, or an update to the multi-select plugin by @joffreyjaffeux on March 14 to ‘make values parsing more resilient’.
The problem is new signups are so intermittent that weeks can go by without one, so cause and effect can be very far apart in time.
OK, that was interesting - I attempted to use my Gmail account as above, but even while going to my Gmail webpage in another browser window and waiting for the Discourse generated verification email to turn up there, I was notified via my normal administrator email address about a new sign up to review.(and queue was empty as before). I had mistyped the address so never received the email to my Gmail account, so never verified.
So unless this is a coincidence, perhaps administrator notifications are jumping the gun? Though that would not explain why EVERY notification involves exactly one missing person in the queue - presumably there will not always be a failure to verify email address by one applicant but not the rest.
** Edit
Subsequently, I corrected my Gmail address in that incognito signup window and resent the verification email - which then turned up at my Gmail browser window. I verified this using the verification url in another incognito window successfully. No subsequent notification was sent to my administrator email address, so I can only assume the first notification was indeed associated with this new sign up attempt.
Using yet another browser window, I visited the site again using safe-mode, signed in as administrator and saw the same queue still with one person to review - but this time my new test account was visible and could be approved.
To follow up - I tried again and made a new fake account via incognito window (with correct address first time) - this attempt worked as expected, and responding to the emailed administrator notification via ordinary browser window I saw there was the new user visible in queue.
I repeated with new signup via standard window, and responding to notification via standard window (no incognito or safe mode at any point) - and again all worked as it should - so the issue (or perhaps two issues - the notification to administrator even before email address verification by applicant, and the non appearance of the incomplete or completed application in the queue) was confined to the first attempt.
Again, not sure if this adds much clarity - but maybe once a first signup has been botched by the system (generating a phantom notification), subsequent signups then work ok? Maybe reverting to failure mode after enough time with no further signup activity has passed?
I suspect a migration I added around the same time as the commit you mentioned caused this issue, making some unapproved users look like they’re in the review queue and causing weird notifications.
Can you run this query on the data explorer to confirm that this is the case?
SELECT COUNT(*)
FROM users
INNER JOIN reviewables r ON r.target_id = users.id
WHERE r.type = 'User' AND r.status = 1 AND users.approved = FALSE
However my Discourse installation is currently also showing no users waiting.
I have just now created another fake account, and had the addressed verified, but as yet no notification at all has been sent to my administrator email account. Logging back in to my site as administrator, I re-ran the query, and count was again zero, but this time Discourse otherwise now reports (correctly) that there is a user awaiting review
Normally users to review notification emails to my administrator address are pretty much immediate, so I am moderately certain this one never got sent. Now almost the opposite problem!
*EDIT - I just now received a notification that TWO users were awaiting review (after an uncharacteristic delay). Still the small red icon by the hamburger menu showed the numeral ‘1’ , and clicking to review the queue showed only my own single fake user sign up from above - which I approved, and Discourse indicated no more users to review
After this I ran the query again - and count was zero.
Sorry, I realized that the WHERE clause is wrong. It should be r.type = 'ReviewableUser' instead of User.
Can you run this one instead?
SELECT COUNT(*)
FROM users
INNER JOIN reviewables r ON r.target_id = users.id
WHERE r.type = 'ReviewableUser' AND r.status = 1 AND users.approved = FALSE
Would you mind checking if your site has any unapproved users without an associated reviewable object? I’ve been trying to reproduce this bug without luck so far.
Here’s a query to do so:
SELECT COUNT(*)
FROM users u
LEFT JOIN reviewables r ON r.target_id = u.id AND r.type = 'ReviewableUser'
WHERE approved = false AND r.id IS NULL
also, try:
SELECT COUNT(*) FROM users WHERE approved = false AND active = true
Not sure if relevant, but there are a lot of posts that were imported from a defunct yahoo group that is the precursor to current forum - merged in for continuity and searchability reasons. The creators of those old posts (dating back to early 2000’s) often won’t have accounts on the current forum.
This was very interesting - how can someone have an unapproved account but be active? Unless it is me as the administrator? How can I tweak query to identify that user?
SELECT * FROM users WHERE approved = false AND active = true
The username will be a link to the user profile. After you identify it, can you share the created_at date? I’d like to know if we change something around that date.
