I discovered a pretty big issue today following some bug reports with reviewing users. I was creating the “Reviewable” for a user when the user was created, not when they activated their account. Users can’t be approved until their accounts are active so you’d just see a “Reject” button which was confusing. This commit should fix it:
The commit also creates the reviewable asynchronously. Besides being slightly faster for the user activating their account, it gets around a nasty issue of a nested database transaction that I couldn’t recover from
@eviltrout Issue still exists, after updating I have the new Settings. but still corrupted notifications are still around if a user is approved from the admin screen.
This G+ import site still has users that are listed as approved and they are active, and they are showing up in the queue with only a reject. (I don’t think that they should be marked as active since they have bogus email addresses.
I deactivated all the users with gplus.invalid email addresses, but those users are still in the queue with reject only. Is there some way that I can just empty the queue and let sidekiq fill it up again?
Looks like I found a bug. When creating a new topic with restricted tags, they are for some reason removed when sent to the review queue. And when an admin tried to edit the post for approval, he gets the following message:
@eviltrout
ok it appears to be working ok now after another upgrade last night. However I still have the old notifications that were incorrect.
Can we get some instructions on how to clear these out?
Thanks!
Nice work Robin - I look forward to seeing it completed (any chance of building an an email notification system as well please?)
Not sure if these have already been mentioned but we’re experiencing these issues:
tags are getting stripped from new topics that go in the queue - so we have to add them while in the queue
tags from categories that require specific tags do not show in the approval queue edit tag box at all (had to edit category to remove requirement then add after approval)
sometimes when clicking approve it says that it can’t because of a ‘update conflict’
sometimes the red notification does not show when there’s an item in the queue
sometimes the red notification does not disappear after you or someone else has approved all queued items (you have to refresh the page for it to go)
Would it be possible to add an option to enable/disable moderators/admins to be notified of pending users? In our forum only the founder and lead-admin handles pending users. Would it be possible to make a setting that omits the rest of the staff from these notifications? The red circle isn’t going away after looking at it and this is pretty distracting. It constantly looks like something got flagged and we need to do something about it.
I have a bit of a unique situation with the new review queue. On our discourse the “must approve users” setting is enabled. If a user looks good, they get approved, no problem. If a user does not get approved, we delete the user.
A new user came in with the review queue, and they were then deleted as usual.
The entry in the review queue is still there, and won’t go away. Also, we are receiving messages from system that notify us that 1 flag is waiting to be handled. In that message there is a link that says “Please review them”. Clicking that link goes to a 404/error page.
Not exactly sure what to do about this, but hoping it will just magically fix itself in the next update.
@Apreche you almost certainly just have to update your discourse, as I have fixed things your post mentions. I suspect we will be releasing a new beta shortly with all the fixes (although if you have the review queue you are likely on tests-passed already and can update at will.)
Our feedback is probably small fry but my team miss the “Reply” to flag option. Enforcement of our rules depends often on legal semantics, the ability to ping the mods into a conference room of sorts was very useful in dismantling the flag, building a mod response we agree and understand and then enforce forwards.
Even with my latest transaction fixes to update the “Needs Review” count, I found cases where it was not being updated. Presumably this is because the message bus was not firing or somehow got interrupted.
I remembered the old flags page had a system to update the flag count manually every time you visited it, so I copied that idea to the new queue:
I was able to fix these by using the following Query… I do not recommend anyone do this but this was the only way to dismiss those 3 “corrupted” records
I got the id’s from the HTML Source for those 3 items, worked fine. Thanks @eviltrout this is fantastic now specially with the UD fields shown
update reviewables set status = 2 where id in (108,109,112);
I fixed a couple of issues related to tagging today. There was a regression where queued posts were not being set up with the tags properly. Also following some feedback from @awesomerobot I added the ability for flagged posts to show any tags they might have too.
This is not strictly related to the new review center, but I’ve found that the UX is sometimes a little confusing as can mean both ‘remove post’ and ’ keep post’ depending on the reason for moderation. (same for ).
I’m seeing an issue that has not been mentioned yet. Admins can see the Flagged Posts history extending back in time, including flagged posts from before the Review Queue was implemented. But Moderators can only see Flagged Posts entered after the Review Queue was implemented- i.e. the past couple weeks.
Moderators need to see the history to identify repeat offenders and maintain consistent standards.
(This is based on a small sample of two admins and one moderator; it’s possible there is another cause for the behavior, but my hypothesis seems the most likely cause.)
One more minor issue we are still getting The old user pending green notification even after we’ve handled anything pending.
It doesn’t dismiss it until you manually do it
When a post requires approval for user typed too fast and you select Delete User, there’s no longer a post rejected entry created in the log with the content of the post.
can mean both ‘remove post’ and ’ keep post’ depending on the reason for moderation. (same for 
).
