https://gerrit.wikimedia.org/g/mediawiki/extensions/MassMessage/+/3ea6d83b7c0732c89801cc084ac9effcd0e0a1f3/includes/MassMessage.php#43

MM just calls User::newSystemUser(). Probably that core function needs a hook for CentralAuth to add it into the right tables.

Change 709211 had a related patch set uploaded (by Zabe; author: Zabe):

[mediawiki/extensions/MassMessage@master] Attach new MassMessage accounts to the global account

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

Change 715805 had a related patch set uploaded (by Umherirrender; author: Umherirrender):

[mediawiki/core@master] Call LocalUserCreatedHook from User::newSystemUser on creation

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

Change 715805 abandoned by Umherirrender:

[mediawiki/core@master] Call LocalUserCreatedHook from User::newSystemUser on creation

Reason:

May not the best way to fix this

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

Change 709211 abandoned by Zabe:

[mediawiki/extensions/MassMessage@master] Attach new MassMessage accounts to the global account

Reason:

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

This problem affects everything using User::newSystemUser(), so I'll rephrase the task.

I think we should just add a new hook inside User::newSystemUser() and have CentralAuth implement it. it may be a bit ugly, but other options seem uglier.

Some considerations from the other task:

In T214722#10906451, @Tgr wrote:

What if the central account does not exist yet? What if it exists but isn't a system user (and you are using the steal flag)? We don't even have an isSystemUser() equivalent for central users.

In T214722#7347220, @Tgr wrote:

Flow does this manually (in TalkpageManager::getTalkpageManager()) by creating a system user and then calling CentralAuthUser::attach( <wiki id>, 'admin' ).

In T214722#9936533, @Bugreporter wrote:

In proposed account vanishing procedure in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/1050675/3/includes/GlobalRename/GlobalRenameUser.php we used User::newSystemUser() with the steal option to make an account unusable. However it will also make the user displayed as system user (isSystemUser) in various places. (The DisableAccount extension already did revoke user's access this way, though it is was not installed in any SUL wikis before undeployed from Wikimedia.)

In T214722#9937981, @Bugreporter wrote:

An alternative solution is to reopen T212720: System users should be in a dedicated user group, which at least provides a better way to detect system accounts than the current one.

More comments copied from merged tasks:

In T214722#8845922, @Bugreporter wrote:

I propose that we can introduce a new user name format for system user names. For example the abuse filter blocker can be named User:@abusefilter-blocker in every wiki, and a localized named (stored in a MediaWiki message) can be shown in page history, recent changes and logs.

Since @ is not a valid character in new user name there are little risk of conflicts with existing users. There are no conflict with interwiki user name either (which always have a (.+)@([^@]+) format). Such accounts can safely be connected to SUL automatically.

In T214722#10371896, @Bugreporter wrote:

In additional of the issues I described above, I do not believe the current way to detect system users (T212720#5661680) is a "cheap" one. Imagine if we need to filter out edits of system users from recent changes, we must query whether a user is system user one by one. In many cases, login credentials can be provided by an external system that may be another database (e.g. CentralAuth), or not MySQL at all. So it is not possible to join it with recent changes.

Change #1312054 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] user: Add SystemUserCreated hook to User::newSystemUser()

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

Change #1312055 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/CentralAuth@master] Attach system users to CentralAuth via SystemUserCreated hook

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

I was thinking of going the other way and adding a newSystemUser method (with create/steal options) to CentralIdLookup. When stealing existing user accounts, it could iterate through all accounts and call revokeAccessForUser(). That way, callers would have to specifically opt into getting a global account. Not sure if that's better or worse... in the long term, probably worse, there doesn't seem much point in asking for a non-global system user.

Not sure how the transition would work, though. We currently have a bunch of unattached system users. Next time something calls User::newSystemUser(), that account will be globalized, and all others will remain detached (at least for callers not using the steal flag). That seems like a confusing situation. CentralIdLookup::newSystemUser() could automatically attach the local account if it's a system user account and a central system user account by the same name exists; with the hook approach, I'm not sure what would be the right place to do that.

In T275931#12139242, @Tgr wrote:

Not sure how the transition would work, though. We currently have a bunch of unattached system users. Next time something calls User::newSystemUser(), that account will be globalized, and all others will remain detached (at least for callers not using the steal flag).

I don't think that's the case with my proposed patches. If there are any unattached users, the new local system user is not globalized (which is not great, but we already have this problem today, T111686), and existing local users turned into system users with the steal flag are never globalized.