Oh, I wouldn’t mind that a bit. Even if the primary action of the drop down button was Delete User, and by using the drop down you could select Suspend User instead, would be ideal. This way, assuming most are not SSO setups, there is no additional work added to them, but for those who are in this situation, have a quick way to suspend a user instead of deleting them.
3 Likes
@Roman_Rizzi do you want to add this one to your list? I see it as being useful to sites with SSO.
7 Likes
When we delete users from the review queue we get a ‘404 Not Found’ popup:
(Just updated to latest, the problem remains)
3 Likes
I’ll take a look. Are these users waiting for approval?
3 Likes
Approval + deleting users that were flagged for spamming.
2 Likes
I just realised that I’m also managing another site where this doesn’t happen and I have a sneaking suspicion that this may have to do with the Follow Plugin 
as it recently saw some changes that had to do with deleted users. @merefield what do you think?
1 Like
No idea at this stage. Can you be more specific? Log evidence?
Network tab on Browser: what’s the URL of that 404?
The only (minor) issue with the Plugin currently (that I’m aware of) is you have to delete the associated notifications if you uninstall the plugin (script in the plugin OP). That’s not related to deleted users.
1 Like
I couldn’t reproduce the issue locally either. The error message makes me think the frontend is making an ajax request to a non-existing endpoint. @bartv Could you share your browser’s network tab after performing the delete action?
I’d like to know if it looks like this:
4 Likes
Will do next time it happens 
1 Like
The plugin monkey patches the UserDestroyer, which is called when you perform the delete action from the review queue. This looks suspicious:
https://github.com/paviliondev/discourse-follow/blob/master/plugin.rb#L111
If somehow following_ids includes an invalid id, User#find will raise an exception, and the user will see a “404 Not Found” message. I recommend using User.find_by(id: ...) instead.
I can’t tell if this is what happened on @bartv site without looking inside the DB, so next time it happens, I recommend looking at the flagged user’s following_ids.
4 Likes
Thanks. That’s true and a very useful highlight.
I still would still like logs and that 404 URL confirmed.
There are probably even more ways to make this more robust.
4 Likes
Pushed: https://github.com/paviliondev/discourse-follow/commit/b523b3aee2d2f0e01934ef63131bc85e3c7caf34 thanks!
3 Likes
We merged a PR to add this action. Confirm, confirm + delete, and confirm + suspend are now bundled together:
4 Likes
I removed the Follow Plugin and my issue remained. In the rails log I see:
Started PUT "/review/6793/perform/reject_user_block?version=0" for xx.xx.xx.xx at 2020-09-03 09:45:48 +0000
Processing by ReviewablesController#perform as */*
Parameters: {"version"=>"0", "reviewable_id"=>"6793", "action_id"=>"reject_user_block"}
Job exception: undefined method `strip' for nil:NilClass
Rendering text template
Rendered text template (Duration: 0.0ms | Allocations: 1)
Started GET "/t/global-variables/331828" for xx.xx.xx.xx at 2020-09-03 09:45:48 +0000
Processing by TopicsController#show as HTML
Parameters: {"slug"=>"global-variables", "topic_id"=>"331828"}
Completed 404 Not Found in 292ms (ActiveRecord: 0.0ms | Allocations: 124598)
ActiveRecord::RecordNotFound (Couldn't find all Topics with 'id': (1185852, 1185853, 1186324, 1186929, 1191089) [WHERE ("topics"."deleted_at" IS NULL)] (found 4 results, but was looking for 5).)
lib/plugin/instance.rb:393:in `block in on'
lib/discourse_event.rb:14:in `block in trigger'
lib/discourse_event.rb:13:in `trigger'
app/models/user.rb:1567:in `trigger_user_destroyed_event'
app/models/reviewable.rb:353:in `perform'
app/controllers/reviewables_controller.rb:192:in `perform'
app/controllers/application_controller.rb:340:in `block in with_resolved_locale'
app/controllers/application_controller.rb:340:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:336:in `call'
config/initializers/008-rack-cors.rb:25:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'
The ActiveRecord::RecordNotFound line is interesting as it appears every time I try to delete a user from the review queue, and with the exact same topic ID’s.
I checked the topic ID’s and these are all posts that use the Events plugin. And sure enough, one of them has been deleted. I’m puzzled why this action from the review queue would check for these though?
@merefield seems like I’m getting back to you guys again, sorry 
EDIT: changed plugin link
3 Likes
That’s a core plugin.
1 Like
Wait, I’m using
git clone https://github.com/paviliondev/discourse-events.git
Is that not the right one (anymore?) (I think I may have linked to the wrong page there, fixing)
1 Like
CLicking it points me to the correct repo.
1 Like
Haha, no the issue wrt deleting a user from the Review Queue.
4 Likes
This is not related to a plugin, this is a core library file.
Why do you think Events is involved?
3 Likes