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:
Another feature that we should add: Make it so that re-flagged items do not re-appear in the review queue unless the post content was edited or changed in some way. This should auto-ignore the new flag items, and not be able to notify or hide the post.
The idea here is some mod somewhere saw the flag already and handled it - and any new items (of the same type) would be handled the same way.
One caveat on the above, we should probably ignore any new flags rather than auto-resolving the reviewable in the same way the flag was actually handled (eg, agreed) as that might have the unintended side effect of giving flag griefers the ability to boost their flag scores by flagging things mods have resolved with agree + keep.
Great point. To add to this, I regularly approve posts that then get flagged for spam by Akismet. That probably shouldn’t happen either.
Oh yeah - Plugins should probably still have the ability to override the above suggestion if necessary, but I agree that Akismet shouldn’t do that in this case. That might be more of an Akismet plugin issue, but it is a great point.
This is a plugin issue, I’ll push a fix.
I already started looking into this. I agree we need to ignore new flags instead of auto-resolving them. I was thinking about showing an error message when someone tries to re-flag a reviewed post.
I was also thinking that users should wait for 24hs or so before being able to re-flag a post for the same reason.
Since all latest pending items are in View All menu, the Review tab should redirect us to that menu instead of the Grouped by Topic menu.
Do you have reviewable default topics set? That causes it to default to topics instead of all items which should be the default.
We just merged this feature:
According to the Discourse 2.4.0.beta11 Release Notes :
Suspect users sent to review queue
Suspect users - those who have viewed less than one post and one topic but have customized their bio - are now sent to the review queue. Such users have a high likelihood of being spammers, as most users browse the site before taking time to fill out their bio.
This doesn’t happen for us; new suspect users appear in /admin/users/list/suspect as usual, but not in the review queue. Does this depend on some settings?
Yes, the feature depends on the approve suspect users setting (disabled by default).
Great, it’s working now (perhaps this kind of info should be added to the release notes).
I do have a small request though that would help us make the review process faster: could you link the website field? Right now we have to copy/paste it, which slow us down a lot.
That looks like a user field you’ve added. Unfortunately we have no way of knowing if those are URLs or not.
The ‘Website’ field? That’s not a custom field (same as here on Meta). The other two are, but I don’t need those hotlinked.
It makes sense that the standard web site field should be hot. It would be cool if it had click count tracking.
I think you should be able to make your custom fields clickable with a theme component.
Double click, control - c, control - t, control - v, enter
My bad! I checked here on meta and the user I looked at didn’t have a website. Plus I got confused by the other user fields directly below. This will link the website for easier review:
https://github.com/discourse/discourse/commit/c954d083df8985daf3d73870b4ad07de0315fe48
After thinking about this some more, a 24h cooling-off window sounds fine for smaller sites, but I’m concerned that users may still have the ability to swamp moderators on a larger site.
What do you think about having the unflaggable window variable (or at least targetable in a plugin)? Anything we can do to lessen a potential burden on mods I’d call a win.
Another unrelated issue: highly trusted users may be seen as having “mod” powers with the ability to hide a post with a single flag. The old minimum # to hide post may still be desirable to have as an option so no single community member can act as a censor.
Yeah after a lot of back and forth I am not really against putting back in the minimum number. I would like to be sure that @featheredtoast’s customer has tried the other tweaks first and are sure this would be helpful.
@Roman_Rizzi could we make that 24h window configurable?
Done here:
Can be enabled or disabled with the high_trust_flaggers_auto_hide_posts setting.
Can be configured using the cooldown_hours_until_reflag setting (default to 24hs).
