Change #1095997 had a related patch set uploaded (by MolecularPilot; author: MolecularPilot):

[mediawiki/extensions/CentralAuth@master] Split "unattached or doesn't exist locally" into separate states on Special:GlobalUsers

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

Change #1095997 had a related patch set uploaded (by Gergő Tisza; author: MolecularPilot):

[mediawiki/extensions/CentralAuth@master] Split "unattached or doesn't exist locally" into separate states on Special:GlobalUsers

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

Change #1095997 had a related patch set uploaded (by MolecularPilot; author: MolecularPilot):

[mediawiki/extensions/CentralAuth@master] Split "unattached or doesn't exist locally" into separate states for unattached users and those that don't exist locally (T104494)

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

Proposed new query (will integrate into getQueryInfo()):

SELECT gu_name, 
       MAX(gu_id) AS gu_id, 
       MAX(gu_locked) AS gu_locked, 
       MAX(lu_attached_method) AS lu_attached_method,
       IF(lu_name IS NULL, 0, 1) AS lu_local_exists
FROM globaluser
LEFT JOIN localuser 
    ON gu_name = lu_name 
    AND lu_wiki = <current_wiki_id>
LEFT JOIN global_user_groups 
    ON gu_id = gug_user
WHERE gu_hidden_level = <HIDDEN_LEVEL_NONE>
GROUP BY gu_name;

"unattached or doesn't exist locally" is the English version of the string centralauth-listusers-nolocal.

This was raised again in our Stewards' Noticeboard (permalink). I am not sure what'd be the best course of action for this.

In T86289#1218342, @Ekips39 wrote:

Wow, that was fast. Also, https://en.wikipedia.org/wiki/Special:Contributions/TheTalker (where the bug was first noticed) shows a block notice now. Did someone fix it?

See also T214722: Introduce global system users.

Which is a bug. QED. Thanks for referencing it!

@Legoktm once the actor migration is done it should be (relatively) straightforward to just change the rev_actor for the affected rows, right? (No longer need to account for changing both rev_user and rev_user_text. Just a thought

In T37170#1338128, @Nemo_bis wrote:

Is this superseded by T38939?

Autocreation should never be blocked as long as the global account is not locked. If a user can't autocreate accounts, *that's* the bug. IMHO.

Since I'm lurking on Phabricator - any idea how many usernames have this incorrect attribution issue that will need fixed ?

Thanks for having again a look @hoo

It's been just under a month (which appears to be a reasonable time for response). Could @Dereckson @Legoktm and @hoo please attend to this task if/when they can?

(Moving columns is a pretty standard operation that people can filter out in their prefs if they so desire, so prolly not all 55 got a notif ;) )

fwiw: 55 people just got a notification and clicked on it just to be informed that this task isn't Epic anymore but now just "other completed". worth it?

I'd like to request that the script be run again, so we can know if the number of empty accounts is increasing. Also, please see if the script catches the accounts listed at T160296. @Dereckson @Legoktm @hoo - would you be able to do that? Thanks.