You’re right. The review queue sort error happens because there are Akismet reviewables in the database after the plugin was removed. I see two possible solutions here:
Provide a rake task to remove these rows from the database before the user decides to remove the plugin permanently.
Apply a default scope to the Reviewable class that excludes these rows if the plugin is disabled.
Does it happen when the post is waiting for review? Or after rejecting it? As I said earlier, uploads of rejected queued posts are automatically removed by the system.
I think plugin uninstallation is rare, and the default scope thing is more likely to introduce bugs.
I think it would be reasonable if we added a rake task, then put it in the README under an “uninstallation” section with instructions to execute it to remove the old records. Let’s do that!
I’ve tried disabling ‘notify about queued posts after’ by setting it to 0 and also 2000000000. I’m still getting lots of frequent ‘x items need to be reviewed’ notification messages.
The system is sending them because there are pending items in the queue. The setting you changed is for queued posts reminders, set notify_about_flags_after to 0 instead.
Thanks @Roman_Rizzi - I can confirm that modifying notify_about_flags_after to 0 stopped the notifications
Really appreciate adding the rake task for this! I’ll reinstall Akismet and run the rake task later today when traffic is at low peak, then update this post with the results.
It seems that users who are having their posts go directly to the review queue can bypass quite a few rate limits for topic and post/reply creation.
Rate limit options that seem to be bypassable:
rate limit create topic, rate limit new user create topic, max topics per day, rate limit create post, rate limit new user create post, unique posts mins, max consecutive replies.
Send topics & posts directly to review queue options:
‘approve post count’ (new users needing their first topics/posts approved) as well as the individual category options of ‘Require moderator approval of all new topics’ and most likely (I’ve only tested the new topics option) ‘Require moderator approval of all new replies’.
Ahh, I see. Thanks for the explanation. Will just share my experiences with it for reference.
Without the limits being enforced, it’s allowing new users (approve post count) to freely flood the review queue with no or minimal limits while older trusted accounts are limited by the rate limits. Except when the category options for approving all topics or replies are enabled, then older trusted users have no or minimal limits too.
It’d be quite a lot of work, but fairly achievable to approve all new topics, as well as the initial topics/posts created by new users (if rate limited), but it’s close to unviable in my case when users can flood the queue.
Anyhow, thanks a lot for the clarification that this is by design. It’s very helpful. I think that I’ll revise my strategy and disable the options which send topics or posts directly to the review queue, reserving it mainly for flagged content. Then simply moderate the rate limited live submissions after the fact, should work nicely and be more fast paced for users too.
I have recently set invite only site setting and now there is an item in the review queue generated by system for a user account, marked as Needs Approval.
The strange thing is that this is an existing (4 years old) account with multiple posts and TL2, but it has not been active lately (last post was 2 years ago), but it has logged in today, after which the review flag was raised.
I have not used the Approve User yet, and the item is still in the review queue, but it seems that the account is enabled and able to use the forum (as it should).
It seems that the review queue is identifying recently reactivated account as new account and marking it for review when invite only is set?
Edit: this also happened now for a very recent account, created only days before this setting was enabled.
I think I’ve seen this before when you switch to invite only. In some situations Discourse thinks you need to approve the user because they gained access to the site by signing up regularly. When that toggle is changed their record has no “Approved” flag set.
I’ve investigated this further, and the only thing these accounts (four in total) have in common is that they all logged in using one of the email login paths (via forgot_password or directly by email_login) after the invite_only was set.
Has there been any thoughts to adding suspend to review topics/posts flagged by Akismet? It has been suggested on our instance, simply because we’re SSO, so deleting members rarely does any good, the member can just re-login to their account on the primary provider and they are instantly logged into the forums to continue on their way. Suspending makes them work harder as they have to create a new account on the provider with a new email address.
I know, its a bit of a weird request, but one that my moderators ask about fairly frequently. Today, they manually go around the system to suspend the user, so it creates extra effort for them to do so, but is worth it because the user ultimately isn’t willing to throwaway another email address.