# Suspend from Review Queue
**URL:** https://meta.discourse.org/t/suspend-from-review-queue/225660
**Category:** Feature
**Tags:** review-queue
**Created:** [April 29, 2022, 12:42pm UTC](https://meta.discourse.org/t/suspend-from-review-queue/225660 "2022-04-29T12:42:52Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@davemaxwell](https://meta.discourse.org/u/davemaxwell)
#### Post date: [April 29, 2022, 12:42pm UTC](https://meta.discourse.org/t/suspend-from-review-queue/225660/1 "2022-04-29T12:42:52Z")
Would it be possible to add the ability to add the ability to silence/suspend users from the review queue?
We get a decent amount of spam traffic from sites because our community has been posted on those SEO forums as one that has friendly link policies (AKA not no-follow) even though we’ve been no follow pretty much since the concept came to fruition. The spam traffickers come in waves, some automatically spamming, some waiting an extensive period, some doing call/response spamming. Some even come in teams, I guess in the hopes that we’ll miss a couple and they’ll get the little bit of non-existent link juice.
Because of the various types of spamming, we’ve found it more beneficial to have as much documentation and tracking in place for us, which make the delete/block (which we would need to use due to SSO). But the lack of documentation (there is a minor info popup but nothing visible on the log record itself) makes it harder to keep an eye out for the spammers, and also to deal with those who may be accidentally marked as spammers (we are human after all). So we end up manually suspending the users, approving the posts, then deleting them.
If we could have the “take action” button which shows up on the flag spam process, there would be consistent behavior in the spam fighting process, and also allow the most visibility for patterns of problematic users.
---
### Author:  [@davemaxwell](https://meta.discourse.org/u/davemaxwell)
#### Post date: [August 7, 2023, 12:47pm UTC](https://meta.discourse.org/t/suspend-from-review-queue/225660/3 "2023-08-07T12:47:42Z")
I **REALLY** hate to be one of those “bumpers” but I would like to bring this back up for people to reconsider.
We get a lot of spam…a lot. There are days it can push 15-20 spam messages in an hour. So we’ve been forced into using the delete user method because otherwise it’s a 4-5 step process - approve, go to post, flag, take action (if it’ll let you take direct action, otherwise go to queue and take action). All the while hoping that a community member doesn’t flag the “approved” post, making more work for us.
But now we’re running into an issue where our staff is human. Once in a blue moon, a valid user will get deleted because their post looked bogus but was legit.
And there is no undelete user functionality, at least that I can find. Nor is there a clean way to SEE the deleted users other than to go through the log, which means looking at the info popup for each and every deleted user (or export the log and find the user that way).
So we’re dealing with a “which devil do you want to live with” scenario - double or triple the moderation time, or saddle the support staff with having to deal with valid customers who inadvertently get deleted because their posts toe too close to the line.
Note: I know there is the reject post functionality in the review queue, but that doesn’t deal with the users, so it’s a double edged sword because the users can come back, and there’s nothing in the queue which would indicate someone’s had rejected posts before…
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [August 7, 2023, 1:02pm UTC](https://meta.discourse.org/t/suspend-from-review-queue/225660/4 "2023-08-07T13:02:46Z")
Which method accounts for most of the spam arriving in your Review Queue?
I think if it’s flagged by Akismet there’s the ‘suspend’ option in the ‘Yes’ dropdown:
And I think it’s also there for community-flagged ones as well:
Is there one we may have overlooked?
---
### Author:  [@davemaxwell](https://meta.discourse.org/u/davemaxwell)
#### Post date: [August 7, 2023, 1:12pm UTC](https://meta.discourse.org/t/suspend-from-review-queue/225660/5 "2023-08-07T13:12:11Z")
> [@JammyDodger](#):
>
> Which method accounts for most of the spam arriving in your Review Queue?
Most of ours comes from the “New user typed their first post suspiciously fast, suspected bot or spammer behavior”
THOSE posts have approve post, delete post and the delete user functionality. I’m asking that we get the same features as the other two queues which has the option to suspend the user. Could be added as a dropdown on the reject post.
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [August 7, 2023, 1:23pm UTC](https://meta.discourse.org/t/suspend-from-review-queue/225660/6 "2023-08-07T13:23:42Z")
Ah, yes. That one inherits the ‘Approval’ buttons rather than the Flag ones as it’s classified as a Queued Post/Topic:
I think as that setting is specifically to catch out potential bots and spammers it would be good to have the same/similar options as the Akismet one for consistency.
Personally I’m in the ‘delete’ spammers camp 🙂 but I know of a couple of sites who prefer to suspend instead, and if the option is there for the others I think it should be included for this one as well (if possible).
---
### Author:  [@boltronics](https://meta.discourse.org/u/boltronics)
#### Post date: [August 8, 2023, 4:50am UTC](https://meta.discourse.org/t/suspend-from-review-queue/225660/10 "2023-08-08T04:50:28Z")
Here is an example screenshot showing the problem:
I’ve had a quick look through the code. It looks like those user actions are added around [here](https://github.com/discourse/discourse/blob/0c88bf341ae8362da92a704c44d8297cf090d43c/app/models/reviewable_queued_post.rb#L50) in a `ReviewableQueuedPost` class method, where the class extends `Reviewable` that provides `delete_user_actions()`.
Labels come from [here](https://github.com/discourse/discourse/blob/0c88bf341ae8362da92a704c44d8297cf090d43c/config/locales/server.en.yml#L5222-L5229), and we already have labels for `reject_and_suspend` that are used in the `ReviewablePost` class for example (which also extends `Reviewable`).
I don’t know Rails very well, but I get the impression that it would not be much work to add a “Reject and Suspend user” right on that page between “Approve Post” and “Delete User”.
This option would help prevent us from occasionally causing a user to have a bad day.
---
### Author:  [@davemaxwell](https://meta.discourse.org/u/davemaxwell)
#### Post date: [August 8, 2023, 11:52am UTC](https://meta.discourse.org/t/suspend-from-review-queue/225660/11 "2023-08-08T11:52:28Z")
> [@boltronics](#):
>
> I don’t know Rails very well, but I get the impression that it would not be much work to add a “Reject and Suspend user” right on that page between “Approve Post” and “Delete User”.
To be fair (this isn’t something I thought to share with Boltronic) but we intentionally hide the reject post button because all it does is delete the post - there’s no logging that goes along with it - or there wasn’t when we hid the button (I’d be glad to reshow it if it at least logs it).
But if a similar approach is done with the delete user button where a reject post and a reject post/suspend user option is added, that would work as well, and behavior would be consistent between buttons.
---
### Author:  [@JammyDodger](https://meta.discourse.org/u/JammyDodger)
#### Post date: [August 8, 2023, 12:03pm UTC](https://meta.discourse.org/t/suspend-from-review-queue/225660/12 "2023-08-08T12:03:35Z")
> [@davemaxwell](#):
>
> or there wasn’t when we hid the button (I’d be glad to reshow it if it at least logs it).
I believe the ‘user typed too fast’ ones are saved for the Review Queue records now. 👍
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [July 31, 2026, 8:14am UTC](https://meta.discourse.org/t/suspend-from-review-queue/225660/13 "2026-07-31T08:14:21Z")
Better late than never? 😅
>
>
> Previously, suspect-user reviewables ("user needs approval" flags) and queued-po…st reviewables could only be resolved by deleting the user or rejecting the post outright — a reviewer mistake on an automated false positive was irreversible, and sites with no-deletion policies had to resolve the flag and then manually suspend the user from their admin page. Requested in \[meta t/408891\](https://meta.discourse.org/t/408891) and \[meta t/225660\](https://meta.discourse.org/t/225660).
>
> This change adds guardian-gated \*\*Silence user\*\* / \*\*Suspend user\*\* resolutions to both queues via a shared \`build\_penalty\_actions\` helper, using the same penalize-modal flow the flagged-post and review-every-post queues already use (staff log linked back to the reviewable). Along the way it:
>
> \- hides penalty actions that are already active everywhere (previously a resolve-then-409 dead end), and fixes the penalize modal's unawaited \`before()\` race so the penalty is only applied once the reviewable action succeeded;
> \- narrows the rejected-user \*\*scrub\*\* affordance to records whose identity snapshot is the last remaining copy (user deleted, or renamed/anonymized after a failed deletion), admin-gated to match the endpoint;
> \- shows an active penalty (localized end date and reason) on the reviewable user card, so it's clear why a penalty option is absent;
> \- preloads \`anonymous\_user\_master\` on the queue since the new \`silenced?\` gates would otherwise lazy-load it per row;
> \- rewrites the action descriptions in one consistent voice.
>
> \