Change #1258184 had a related patch set uploaded (by Manvi Kesarwani; author: Manvi Kesarwani):

[mediawiki/extensions/CentralAuth@master] LocalRenameUserJob: Do not mark vanished users as system users

https://gerrit.wikimedia.org/r/1258184

i have uploaded a patchset can you please review my patchset .

This code exists from the very first version of vanishing (according to git blame). I believe the purpose of such code is to revoke vanished account's password and email. In T368524: Make password unusable for Vanished accounts, there are argument that we may want so for GDPR purpose. The task is later declined, but the code to revoke password and email is still there. We need to consider whether revoking password and email is good to do. If no, then we can remove such code (though password/email of older vanished users are still lost and can not be recovered). If yes, then what we need to fix is to do so without considering the user as system user. What I think is the current way to determine system users is faulty and should be fixed: see T214722#9936533 and subsequent comments.

I'm not sure what the cause of the behavior change is, but this is recent, only seems to be presenting in the last month.

Thanks for the context. I traced the “system user” flagging to LocalRenameUserJob during GlobalRenameRequest::VANISH: it was calling User::newSystemUser(..., ['steal' => true]), which turns the renamed end-user into a system account. Vanishing should rename + globally lock the account, not convert it into a system user.

I’ve removed that conversion so vanishes no longer mark the account as system. I did not change the parts of the flow related to password/email revocation here; if you want that addressed as well, please confirm and I can follow up with a separate patch. @Bugreporter

I traced the “system user” change to LocalRenameUserJob handling GlobalRenameRequest::VANISH, where it was calling User::newSystemUser(..., ['steal' => true]), which converts the renamed end-user into a system user. I removed that call so future vanishes won’t set the flag; past affected accounts may need a separate cleanup if desired. @Xaosflux

Yes, I'd think the errors should be cleaned up, is a sub-ticket needed?

Yes, if those affected accounts were already processed while the incorrect “system user” conversion was present, the data cleanup likely needs a separate sub-ticket. I’m happy to open/propose it once we confirm the exact “system user” field/criteria to target only vanished end-user accounts.

Can you say more about why this is a problem now?

I think this break the rarely used manual account un-vanish process, not to mention simply being inaccurate.

I don't think it's inaccurate… system users are defined as users who can't authenticate (don't have a password, passkey, or other login credentials), don't have an email, and don't have a "Keep me logged in" token (reference) – this is all true for vanished users. Their accounts really become system users when they are vanished. We can't change this without keeping the data that the user has asked us to delete.

As far as I know, "un-vanishing" an account requires sysadmin intervention to set an email (and then perform a password reset), at which point the account is no longer a system user. Is there some other process I don't know about? (You can just rename them back and un-lock the account, but that won't let them authenticate, since the password and other credentials are removed during vanishing.)

None of this has changed recently, so I don't understand where this request is coming from. Did we start showing the "system user" status somewhere that is confusing? Where? Maybe that should have a special case for vanished accounts?

In T420848#11739921, @matmarex wrote:

I don't think it's inaccurate… system users are defined as users who can't authenticate (don't have a password, passkey, or other login credentials), don't have an email, and don't have a "Keep me logged in" token (reference) – this is all true for vanished users.

They should have a password per previous decision (T368524).

在T420848#11739921中，@matmarex写道：

I don't think it's inaccurate… system users are defined as users who can't authenticate (don't have a password, passkey, or other login credentials), don't have an email, and don't have a "Keep me logged in" token (reference) – this is all true for vanished users. Their accounts really become system users when they are vanished. We can't change this without keeping the data that the user has asked us to delete.

As far as I know, "un-vanishing" an account requires sysadmin intervention to set an email (and then perform a password reset), at which point the account is no longer a system user. Is there some other process I don't know about? (You can just rename them back and un-lock the account, but that won't let them authenticate, since the password and other credentials are removed during vanishing.)

None of this has changed recently, so I don't understand where this request is coming from. Did we start showing the "system user" status somewhere that is confusing? Where? Maybe that should have a special case for vanished accounts?

I believe that automatically marking vanished users as system users is clearly misleading (https://meta.wikimedia.org/wiki/Meta:Requests_for_help_from_a_sysop_or_bureaucrat#c-ShuQizhe-20260322165600-CptViraj-20260322052500⁠), and in fact they are not actual system users.

I'm not sure what changed, but there is certainly a change around this date, the code referenced above may not be the cause, I don't know what the cause is.

Example user vanished on 2026-02-23: Renamed_user_63264dc96c1a21d04506e63c417f15eb

Example user vanished on 2026-02-25: Renamed user f92c12610748954403402217064c1761

New accounts are now marked:

If this value is deterministic, not set - it may be indicative that the vanish process changed (perhaps it is now removing the 'password' as well, which as was mentioned above is NOT supposed to be occurring).

system users are defined as users who can't authenticate (don't have a password, passkey, or other login credentials), don't have an email, and don't have a "Keep me logged in" token (reference)

So we should change how system users are defined. I already complained at T214722#10371896 that the current definition of system user is expensive to calculate (imagine we need to filter that in recent changes), since login credentials can be provided by a third-party.

Thank you all for the comments. Something is definitely not right. I'll make sure we investigate this.

I got to the bottom of this. It looks like the code to remove the password and other login credentials used to not work correctly, and it was recently fixed as a side-effect of a fix for a different bug (T418122), causing these accounts to be labelled as system accounts.

I started a new task with by best summary of the situation, so that we can decide this officially: T421525: Should vanishing an account remove its password and other login credentials?. If you commented here, your input is welcome.

If we decide that this is correct, we can figure out how to make it happen without labelling these accounts as "system users".

Change #1258184 abandoned by Manvi Kesarwani:

[mediawiki/extensions/CentralAuth@master] LocalRenameUserJob: Do not mark vanished users as system users

Reason:

abondon

https://gerrit.wikimedia.org/r/1258184