Deactivated users are sometimes not being deactivated

Product Support

AI-generated summary

Nacho_Caballero reported an issue where users appeared deactivated in staff logs but remained active, able to log in and send messages. This occurred sporadically across multiple deactivation attempts, including via API, with no reactivation logged. Nacho_Caballero noted that users could be “deactivated twice” without intervening reactivation, and suspected unlogged activation—possibly via DB manipulation, though ruled out as the sole admin. simon clarified that this is expected behavior: when a deactivated user attempts to log in, Discourse sends a “Confirm your new account” email, which, when clicked, reactivates the account. This has been longstanding behavior. simon recommended using “suspend” instead of “deactivate” for intended lockout. Nacho_Caballero confirmed the mystery was solved and closed the thread.

1

I haven’t found a way to reproduce this issue, but over the past month I’ve noticed two instances where a user was supposedly deactivated (as seen from the staff action logs) but not actually deactivated (the user could still log in).

For example, this one was “deactivated” 29 days ago, but was able to send me a private message today (the only other staff actions after the deactivation are “check email”)

CleanShot 2022-08-31 at 07.19.41@2x
CleanShot 2022-08-31 at 07.19.41@2x2534×538 117 KB

This is the other one (a different staff member was able to “deactivate” the same user again 4 hours later without a previous reactivation):

CleanShot 2022-08-31 at 07.38.24@2x
CleanShot 2022-08-31 at 07.38.24@2x2288×522 99.7 KB

I’m on 2.9.0.beta9

2

This issue is still ongoing (it happens several times a month). Has anyone else noticed it?

This is the controller code

The StaffActionLogger is working correctly, but I’m wondering if something in the User.deactivate method might be failing.

What the errors have in common is that they’re coming from API requests. This is what I typically use:

PUT https://<MY_SITE>/admin/users/<USER_ID>/deactivate

Api-Username:<ADMIN_USER>
Api-Key:<KEY>

data: {context":"/admin/users/<USER_ID>/<USER_NAME>"}

I always get “success: OK”

Is there any other log I could check out or thing I could try?

I’m on 2.9.0.beta11

4

This is still happening sporadically. For example, this user was initially “deactivated” on August 23, but I just noticed now that they were still active and actually deactivated them.

How can a user be deactivated twice (without a reactivation in between)?

2024-09-23-discourse-bug
2024-09-23-discourse-bug3100×1166 275 KB

I have a daily task that runs a query to check for this situation. It returned nothing yesterday and this one user today, so what seems to be happening is that the user was correctly deactivated on Aug 23, but it somehow got activated yesterday (without it being logged anywhere).

Is it possible to activate a user (via API or UI) and not leave a trace? I’m assuming this could only happen by modifying the database directly, which I’m certain I didn’t do (I’m the only admin).

5

This can happen. All a deactivated user needs to do to re-activate their account is to attempt to login to the site, then click the link in the activation email that’s sent to them.

When a deactivated user attempts to login they will see this modal:

20240922_23h02m09s_grim
20240922_23h02m09s_grim858×550 53.4 KB

Discourse will send them a “Confirm your new account” email:

20240922_23h06m08s_grim
20240922_23h06m08s_grim925×324 30.4 KB

After clicking the link in the email, the user will be logged into Discourse.

This has been the behavior for as long as I can remember. I don’t think it’s a bug, but I could be wrong about that. Sending a “Confirm your new account” email to a user who already has an account seems a little off.

Edit: to get the behavior you are looking for, you probably want to “suspend” the user instead of deactivating them.

6

Mystery solved! Thanks, Simon. You can close this thread.