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.