SUL-Finalization (original) (raw)

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 = LEFT JOIN global_user_groups ON gu_id = gug_user WHERE gu_hidden_level = 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.

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?

Bugreporter renamed T111686: Attach existing system users to CentralAuth from Add accounts used by extensions to SUL to Add new accounts used by extensions to SUL.

Bugreporter renamed T111686: Attach existing system users to CentralAuth from Add accounts used by extensions to SUL for new wikis to Add accounts used by extensions to SUL.

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

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

$ mwscript extensions/CentralAuth/maintenance/deleteEmptyAccounts.php --wiki=aawiki | tee deleteEmptyAccounts.php-2018-04-04 $ grep -v PROGRESS deleteEmptyAccounts.php-2018-04-04 | wc -l 3915

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.