I think part of this confusion could be solved if we acted upon T160666. We
have several other system users such as MediaWiki default, Maintenance
script, MediaWiki message delivery, Redirect fixer, etc. whose name is one
for all wikis, which helps identifying the account via CentralAuth and
benefits from GlobalUserPage. I feel what we have here with
abusefilter-blocker is an exception. Also, it can cause broken logs if the
abusefilter-blocker string gets modified once it has logs aasigned to the
previous account name, etc. Thanks.

Originally I didn't really agree with the rationale behind T160666, but now I think that it's actually worth going on with that. We would benefit from centralAuth, and it won't be possible for people to change the account name, or to use invalid characters inside the message, as it happened in kmwiki.
Another thing we need is some way to clearly identify system users, both backend (as discussed for instance here) and frontend, so that users don't get confused.

Two impressions from the communities:

• There was a related desysop request to the Stewards by a Spanish Wikipedia user at metawiki, but this request was turned down. Stewards did not feel responsible, and someone pointed to phabricator discussions.
• Some users in German Wikipedia have problems with the sysop flag of the abusefilter-blocker user as well, mainly at Wikipedia:Administratoren/Notizen#Benutzer:Bearbeitungsfilter and Wikipedia Diskussion:Kurier#Ein neuer Admin ist zu uns gestoßen, welch(e) Freude!. The abusefilter-blocker user is not in use at German Wikipedia (that user account was in fact created on 17 Dec 2018), as the community admins cannot define block sanctions in edit filters by some configuration settings.

In both cases, there is concern about the abusefilter-blocker user having a (symbolic) sysop flag.

Sincerely I cannot personally understand the concern, as I already said. However, we will do something to change the AbuseFilter user; from my side, I won't be able to do much these days, but I'll try to do something in 1-2 weeks or so. Removing User-notice because I already added it to T209565, together with some message samples.

Change 481549 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Move the AbuseFilter user name to a global, improve it

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

See also T212720.

Another complaint about this account at https://meta.wikimedia.org/wiki/Talk:Steward_requests/Permissions#Strange_administrator_wikiquote:de:user:Missbrauchsfilter

@Adotchar Thanks for reporting. I wrote down a message for Tech/News in T209565#4852173 and it'll be announced on Jan 7th.

In T212268#4852293, @Daimona wrote:

@Adotchar Thanks for reporting. I wrote down a message for Tech/News in T209565#4852173 and it'll be announced on Jan 7th.

I put announcement in arwiki about this issue 26 Dec 2018.

In T212268#4833518, @Daimona wrote:

We would benefit from centralAuth

We wouldn't as it is now, newSystemUser creates non-attached local users. We should probably fix that, I don't think the global user page works for non-attached accounts, and that's very useful for system users, even if having a central account on its own isn't. (Granted, we could also just change GlobalUserPage to always show for system users.)

@Tgr If we want it to be the default, yes, it should be fixed in core. For AF, the user is attached on creation (see lines 723-727).
At any rate I think the change should be to attach system users, and not to make exceptions.

In T212268#4865283, @Daimona wrote:

@Tgr If we want it to be the default, yes, it should be fixed in core. For AF, the user is attached on creation (see lines 723-727).

Oh, wasn't aware of that. It's a very Wikimedia-specific hack though. The generic approach (which might or might not blow up spectacularly; also we'd probably want something like T69936 for it, and not just in AbuseFilter) would be to create the user with AuthManager::autoCreateUser(). https://gerrit.wikimedia.org/r/c/mediawiki/core/+/481554/ is somewhat related.

@Tgr I'm sorry but I'm not sure I understood. Is it correct that, after $user = User::newSystemUser( $wgAbuseFilterUserName, [ 'steal' => true ] ); (line 720) we should do

MediaWiki\Auth\AuthManager::singleton()->autoCreateUser(
	$user,
	MediaWiki\Auth\AuthManager::AUTOCREATE_SOURCE_MAINT,
	false
);

instead of dealing directly with CentralAuth?

Yes, although maybe that should be put into newSystemUser itself.

Hm, no, actually that wouldn't work; CentralAuth refuses autocreation attempts if there is a central user by that name. Let's move this to a separate task to avoid side-tracking too much here: T214722: Introduce global system users

Change 481549 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Move the AbuseFilter user name to a global, improve it

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

Accepting the part of not making this user be a sysop. The other thing included in the patch (making it use the same name everywhere) should be delayed.

This weird sysop-like user has been lurking around for many years now. Might we finally get to the point, when we get rid of that ghost from sysop lists?

The Authority interface gives us now multiple options to solve the "not making this user be a sysop" part:

1. Use UltimateAuthority.
2. Use SimpleAuthority with sysop (needed) rights.
3. Use UserAuthority and call PermissionManager::addTemporaryUserRights with sysop (needed) rights.

So?

I think UltimateAuthority would make sense -- the idea being that we want to skip any permission checks. I think system users were one of the original use cases for UltimateAuthority, too.

Idea (kind of compromise): Remove the UserGroupManager::addUserToGroup call from the database updater (SchemaChangesHandler). The user will be created when the extension is installed but will be promoted only if the wiki decides to use the aggressive counter-features.