In T161859#10478521, @Ladsgroup wrote:

Sounds good to me. One thing we can also do:

The script ignores accounts where the SUL name and the Developer name are the same.

That mostly should be handled by my merge now but there are still users that have the same username but with different emails and are connected to each other via bitu (that means my work above has not force attached them). We could extract the list and force connect them. Do you think that'd be okay?

I had forgotten that your first pass at these accounts only migrated those where the confirmed emails matched on both sides. I can make a list of accounts where the SUL name from LDAP and the Developer name are the same easily. I think I can also filter that list to remove accounts that are already in centralauth_p.localuser with lu_wiki='labswiki' without a lot of extra steps. I guess I should also harvest mappings from Striker where ldapname = sulname too for completeness.

Thank you! When I get the list, I will force attach them.

In T161859#10484235, @Ladsgroup wrote:

Thank you! When I get the list, I will force attach them.

See /data/project/wikitech-sul-migration/unattached_matching_sul-20250122.txt for a list of 675 usernames that can be force attached to SUL. These names are:

• claimed via LDAP, Striker, or both with the same Developer account and SUL account name
• currently present in labswiki_p.user.user_name (filters out a lot of Striker created Developer accounts that have never been attached to wikitech)
• currently absent from centralauth_p.localuser.lu_name where lu_wiki='labswiki'

Process to (re)create the list:

$ ssh bd808@mwmaint2002.codfw.wmnet
$ cd projects/striker
$ ./db.sh --batch -e 'SELECT ldapname FROM labsauth_labsuser WHERE sulname IS NOT NULL AND ldapname = sulname ORDER BY ldapname' > striker-sul-same-unfiltered-$(date +%Y%m%d).tsv
$ exit
$ scp bd808@mwmaint2002.codfw.wmnet:projects/striker/striker-sul-same-unfiltered-$(date +%Y%m%d).tsv .
$ scp striker-sul-same-unfiltered-$(date +%Y%m%d).tsv dev.toolforge.org:/data/project/wikitech-sul-migration
$ ssh dev.toolforge.org
$ become wikitech-sul-migration
$ webservice python3.11 shell
$ ./py311-venv/bin/python3 names_match.py | ./py311-venv/bin/python3 exclude_attached.py > unattached_matching_sul-$(date +%Y%m%d).txt
$ ./py311-venv/bin/python3 exclude_attached.py striker-sul-same-unfiltered-$(date +%Y%m%d).tsv > unattached_matching_sul_from_striker-$(date +%Y%m%d).txt
$ cat unattached_matching_sul_from_{ldap,striker}-$(date +%Y%m%d).txt|sort|uniq > unattached_matching_sul-$(date +%Y%m%d).txt

I haven't figured out what's exactly causing this but some of the users don't have a corresponding SUL account. For example WMDE Cyn exists in wikitech but I can't find the same user name in SUL: https://meta.wikimedia.org/wiki/Special:CentralAuth/WMDE_Cyn

In T161859#10488676, @Ladsgroup wrote:

I haven't figured out what's exactly causing this but some of the users don't have a corresponding SUL account. For example WMDE Cyn exists in wikitech but I can't find the same user name in SUL: https://meta.wikimedia.org/wiki/Special:CentralAuth/WMDE_Cyn

https://meta.wikimedia.org/w/index.php?title=Special:Log&logid=56988981 renamed that SUL account to Cynthia Makonyango (WMDE). I was able to figure this particular one out because the mapping came from LDAP where we capture both the SUL account name and the SUL account id. It can also be seen from https://meta.wikimedia.org/wiki/User:WMDE_Cyn.

I can update the data fetched from LDAP to resolve current SUL account names through centralauth_p.globaluser.gu_id mappings to account for SUL renames.

Striker unfortunately doesn't store the SUL id so we would have to do something else to resolve SUL renames in that dataset. It should be possible though to at least put them in a separate list of the names that are not currently in centralauth_p.globaluser.gu_name.

Following up on the renamed global account issue @Ladsgroup identified in T161859#10488676, I updated the process of extracting a SUL username from LDAP to use the wikimediaGlobalAccountId data and then resolve that gu_id value to the appropriate gu_name via centralauth_p.globaluser. I also made an exclude_missingsul.py script to remove unknown centralauth_p.globaluser.gu_name values from a pipeline.

/data/project/wikitech-sul-migration/unattached_matching_sul-combined-20250125.txt - 593 usernames that can be force attached to SUL.

I also now have a list of 82 accounts where the SUL name claimed in Striker no longer exists, presumably as the result of a SUL rename or very rarely an account merge. I am going to attempt to manually resolve these to produce another tsv of wikitech->SUL renames that we can do when we get to that bulk step.

IIRC accounts auto-created by the LDAP integration had their emails marked as verified even though nothing verified them in the first place as Striker doesn't verify emails but LdapAuthentication trusted the mail written to LDAP. So you should not auto-merge based on a "verified" mail alone.

In T161859#10494959, @taavi wrote:

IIRC accounts auto-created by the LDAP integration had their emails marked as verified even though nothing verified them in the first place as Striker doesn't verify emails but LdapAuthentication trusted the mail written to LDAP. So you should not auto-merge based on a "verified" mail alone.

Agreed. I believe we only considered automerge for accounts where both username and email matched across labswiki.user and centralauth.globaluser. The other lists we are working on take linkage data from the OAuth assertions created by Striker and Bitu. My comments in T161859#10482456 may be worded in a way that makes this confusing; sorry if that was the case.

In T161859#10494973, @bd808 wrote:

Agreed. I believe we only considered automerge for accounts where both username and email matched across labswiki.user and centralauth.globaluser.

Have you verified that there's no way to access the SUL account state if you have pre-merge session data for a local Wikitech user?

Otherwise for SUL users without an identically-named Wikitech account, in theory someone could've created an imposter developer account via Striker, log in to that on Wikitech, wait for the automatic merge to be done, and then they'd have access to a SUL account that isn't theirs.

wait for the automatic merge to be done

Please note that when a local account is merged to SUL account, its local email will no longer be considered (whether the SUL account has verified email or not), see https://phabricator.wikimedia.org/diffusion/ECAU/browse/master/includes/CentralAuthHooks.php$382. Ditto for password. So this can not be used to take over an existing SUL account.

Updated timeline published on Wikitech and announced to wikitech-l and cloud-announce mailing lists:

• https://wikitech.wikimedia.org/wiki/News/2024_Migrating_Wikitech_Account_to_SUL#Timeline
• https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/thread/GXMCSJWUNN4O7UMXEAFNSKUUCO7KRTLV/
• https://lists.wikimedia.org/hyperkitty/list/cloud-announce@lists.wikimedia.org/thread/GXMCSJWUNN4O7UMXEAFNSKUUCO7KRTLV/

I now have a script at mwmaint2002.codfw.wmnet:/home/bd808/projects/wikitech/2025-02-04/rai.py that can read a TSV data file of (old, new) username pairs and use that data to rename the Wikitech account, attach the renamed account to the matching SUL account, and leave a talk page message letting the user know that the rename and attach have been completed. I have tested this script by renaming and attaching Wikitech accounts belonging to @dduvall and @yuvipanda.

$  cat yuvi.tsv
Yuvipanda       YuviPanda
$ ./venv/bin/python3 rai.py -v --rename yuvi.tsv
2025-02-06T17:36:47Z INFO    : Renaming Yuvipanda → YuviPanda
2025-02-06T17:37:08Z INFO    : Attaching YuviPanda

https://wikitech.wikimedia.org/w/index.php?diff=2268053

I will be using this script and the data files described in T161859#10478032, T161859#10486660, and T161859#10494955 to do bulk rename and attach work on 2025-02-10 as planned at https://wikitech.wikimedia.org/wiki/News/2024_Migrating_Wikitech_Account_to_SUL#Timeline.

Mentioned in SAL (#wikimedia-operations) [2025-02-10T17:31:50Z] <bd808@mwmaint2002> Wikitech: SUL attached 593 accounts with matching names claimed via Striker or Bitu (T161859)

Mentioned in SAL (#wikimedia-operations) [2025-02-10T17:40:34Z] <bd808@mwmaint2002> Wikitech: Renamed and attached 57 of 82 accounts claimed via Striker where the SUL account was renamed after claiming (T161859)

Mentioned in SAL (#wikimedia-operations) [2025-02-10T18:03:34Z] <bd808@mwmaint2002> Wikitech: Renamed and attached 234 of 385 accounts claimed via Bitu (T161859)

Change #1118561 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[operations/mediawiki-config@master] Remove special-casing of CentralAuth for labswiki

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

I have a set of accounts that errored out in renaming attempts on 2025-02-10 because the OAuth claimed SUL account name is already in use locally on Wikitech. For a number of these it looks like the migration process led to some folks accidentally creating a new local account with their desired SUL account name after the October 2024 auth config changes. For others the account that is in the way of renaming is an older account. In either case the fix will be to rename the conflicting local account from $USER to $USER~labswiki and then continuing with the rename and attach as was done with the other accounts. This is functionally the same process that was used to resolve naming collisions during the 2015 Single User Login finalisation project for the movement's content wikis.

For a number of these it looks like the migration process led to some folks accidentally creating a new local account with their desired SUL account name after the October 2024 auth config changes.

So we should not remove special casing until all accounts are migrated to SUL.

Mentioned in SAL (#wikimedia-operations) [2025-02-11T00:59:44Z] <bd808@mwmaint2002> Wikitech: Renamed and attached 128 accounts claimed via Striker/Bitu after usurping their SUL name (T161859)

In T161859#10537324, @Bugreporter wrote:

For a number of these it looks like the migration process led to some folks accidentally creating a new local account with their desired SUL account name after the October 2024 auth config changes.

So we should not remove special casing until all accounts are migrated to SUL.

With the batch that I just did in T161859#10537520, all of the known account claims have been processed. There are a few accounts that have been notified of possible strangeness with T386026: Decide what to do with SUL attached Wikitech accounts that Bitu associates with a different SUL account, but that is all that I know of that is left. I believe this functionally means that we have migrated all known accounts to SUL.

The remaining local accounts on Wikitech will not be force renamed with the ~labswiki suffix until the 2025-02-24 date so that someone could suddenly realize that they have been ignoring this state change since October 2024. Can you help me understand what potential good leaving the special casing proposed for removal by https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1118561 in place until then serves?

In T161859#10468972, @Bugreporter wrote:

In T161859#10467817, @bd808 wrote:

In T161859#10395581, @GTrang wrote:

It appears that Phase 2 did not actually happen on November 30 as planned. In particular, the Wikitech accounts with mismatching SUL usernames did not get automatically renamed.

@Ladsgroup and I met earlier this week to try and figure out what is left to complete the SUL migration at Wikitech and how to move that forward. We have a rough plan that needs a bit of refinement, but we should be publishing an updated timeline soon. Our plan is roughly:

• use data from Bitu, Striker, and the local and SUL user tables to rename and attach accounts that have clear linkage;
• announce changes and pause to give one last chance for folks to "claim" the connection between their Developer account and their SUL account;
• process any last minute connections made via Bitu by renaming and attaching
• rename all remaining local accounts on Wikitech that clash with an existing SUL account out of the way by appending ~wikitech (or ~labswiki depending on tooling used) to the local username
• attach all accounts to SUL (functionally this means creating SUL accounts for all unattached accounts including the ones that were renamed)
• reenable account creation/auto-attachment of existing SUL accounts

Another potential way to connect LDAP and SUL user is check if they are connected to same Phabricator account.

There are still accounts that can be attached via this way, such as https://meta.wikimedia.org/wiki/Special:CentralAuth?target=Ottomata.

Hello, I recall that in November last year, I did attach the Wikitech local account (ID: 30300) to the global account SunAfterRain (ID: 55235043). However, it now seems that the global account link has been broken and reattached to the previously abandoned Wikitech local account (ID: 13358). I believe this is a mistake. Could it be restored to its original state?

I have checked accounts of the current 20 crats. Two of them are not yet attached to SUL:

• https://wikitech.wikimedia.org/wiki/User:Jgreen = https://meta.wikimedia.org/wiki/Special:CentralAuth?target=Jgreen%20(wmf)
• https://wikitech.wikimedia.org/wiki/User:Tim_Landscheidt = https://wikitech.wikimedia.org/wiki/Special:CentralAuth/Tim.landscheidt

I will soon check all sysop account. After this I may want to check other unattached users with most edits (this requires query to Wiki Replica, so I may do it later today or in several days).

In T161859#10537548, @Bugreporter wrote:

In T161859#10468972, @Bugreporter wrote:

Another potential way to connect LDAP and SUL user is check if they are connected to same Phabricator account.

There are still accounts that can be attached via this way, such as https://meta.wikimedia.org/wiki/Special:CentralAuth?target=Ottomata.

I wrote the existing Conduit endpoints that expose the mappings, and I know that they only allow a SUL or Developer account to be mapped to Phabricator account. There is no existing API that returns a SUL mapping for a Developer account or vice versa. You are correct that there is data in a Phabricator database somewhere, but getting it out is not something I know how to do, nor is it a database I have direct SQL access to.

In T161859#10537554, @bd808 wrote:

In T161859#10537548, @Bugreporter wrote:

In T161859#10468972, @Bugreporter wrote:

Another potential way to connect LDAP and SUL user is check if they are connected to same Phabricator account.

There are still accounts that can be attached via this way, such as https://meta.wikimedia.org/wiki/Special:CentralAuth?target=Ottomata.

I wrote the existing Conduit endpoints that expose the mappings, and I know that they only allow a SUL or Developer account to be mapped to Phabricator account. There is no existing API that returns a SUL mapping for a Developer account or vice versa. You are correct that there is data in a Phabricator database somewhere, but getting it out is not something I know how to do, nor is it a database I have direct SQL access to.

@Aklapper, are you able to export such a mapping? i.e. A list of Phabricator accounts that is connected to both SUL and LDAP, and their connected accounts.

Sysops:

• https://wikitech.wikimedia.org/wiki/Special:Contributions/ADenisse-WMF - this user is renamed but not attached. What's up? @bd808
• https://wikitech.wikimedia.org/wiki/Special:Contributions/BCornwall-WMF - this user is renamed but not attached. What's up?
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Jbond = (to check, previously JBond (WMF) but LDAP account no longer linked to discontinued WMF email address)
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Jobo = https://meta.wikimedia.org/wiki/Special:CentralAuth?target=JBorun%20(WMF)
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Kormat = https://meta.wikimedia.org/wiki/Special:CentralAuth?target=SBMhaol%20(WMF) (and should be desysoped)
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Krenair - this user is renamed but not attached. What's up?
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Nskaggs = https://meta.wikimedia.org/wiki/Special:CentralAuth?target=NSkaggs%20(WMF) (and should be desysoped)
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Ottomata = https://meta.wikimedia.org/wiki/Special:CentralAuth?target=Ottomata
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Sukhbir_Singh = https://meta.wikimedia.org/wiki/Special:CentralAuth/SSingh_(WMF) (need to usurp the Wikitech account with same name)

Autopatrollers:

• https://wikitech.wikimedia.org/wiki/Special:Contributions/BBlack_(WMF) - renamed but not attached
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Daniel_Kinzler = https://meta.wikimedia.org/wiki/Special:CentralAuth/DKinzler_(WMF)
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Jdrewniak = https://meta.wikimedia.org/wiki/Special:CentralAuth?target=JDrewniak%20(WMF)
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Joal = https://meta.wikimedia.org/wiki/Special:CentralAuth?target=JAllemandou%20(WMF)
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Michael_DiPietro - (old account of VRook (WMF))
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Smalyshev = https://meta.wikimedia.org/wiki/Special:CentralAuth?target=Laboramus
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Srishakatux = https://www.mediawiki.org/wiki/Special:CentralAuth/SSethi_(WMF)
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Zfilipin = https://meta.wikimedia.org/wiki/Special:CentralAuth/ZFilipin_(WMF)

I am not sure what has happened with my account now, but it is a complete mess. Months ago I have attached my Wikitech account Aneisenigel with my SUL account Ameisenigel. Now this connection has been removed and my account Ameisenigel has been renamed to Ameisenigel~labswiki. Instead my old account Sewepb that I have not used since many years has been renamed to Ameisenigel and connected with my SUL account. Please undo this. Thanks.

By reviewing rename log some other apperent errorous matches are:

• https://wikitech.wikimedia.org/wiki/Special:Contributions/DeltaQuad is connected to SUL account "DeltaQuad" which is the previous name of "AmandaNP" and now an alternative account.
• https://wikitech.wikimedia.org/wiki/Special:Contributions/Tulsi_Bhagat is connected to SUL account "Tulsi Bhagat" which is the previou name of "Tulsi".

Both matches are assumed to come from Striker which only records SUL user names and does not take renames into account.

In T161859#10537555, @Bugreporter wrote:

@Aklapper, are you able to export such a mapping? i.e. A list of Phabricator accounts that is connected to both SUL and LDAP, and their connected accounts.

If that's wanted I can provide SQL output (SUL, LDAP, email) - please file a separate subtask assigned to me.
There are 1359 non-disabled, non-bot Phab accounts with both a SUL and LDAP account attached, per
SELECT u.userName AS phabUsername, ue.address AS phabEmailAddress, ua1.username AS sulAccount, ua2.username AS ldapAccount FROM phabricator_user.user u JOIN phabricator_user.user_email ue INNER JOIN phabricator_user.user_externalaccount ua1 INNER JOIN phabricator_user.user_externalaccount ua2 WHERE ue.isPrimary = 1 AND ue.userPHID = u.phid AND ua1.userPHID = u.phid AND ua2.userPHID = u.phid AND u.isDisabled = 0 AND u.isSystemAgent = 0 AND ua1.accountType = "mediawiki" AND ua2.accountType = "ldap";

In T161859#10537957, @Aklapper wrote:

In T161859#10537555, @Bugreporter wrote:

@Aklapper, are you able to export such a mapping? i.e. A list of Phabricator accounts that is connected to both SUL and LDAP, and their connected accounts.

If that's wanted I can provide SQL output (SUL, LDAP, email) - please file a separate subtask assigned to me.
There are 1359 non-disabled, non-bot Phab accounts with both a SUL and LDAP account attached, per
SELECT u.userName AS phabUsername, ue.address AS phabEmailAddress, ua1.username AS sulAccount, ua2.username AS ldapAccount FROM phabricator_user.user u JOIN phabricator_user.user_email ue INNER JOIN phabricator_user.user_externalaccount ua1 INNER JOIN phabricator_user.user_externalaccount ua2 WHERE ue.isPrimary = 1 AND ue.userPHID = u.phid AND ua1.userPHID = u.phid AND ua2.userPHID = u.phid AND u.isDisabled = 0 AND u.isSystemAgent = 0 AND ua1.accountType = "mediawiki" AND ua2.accountType = "ldap";

You may export the SUL-LDAP links (email not useful for now) to a paste or file. The information is public and can be viewed in Phabricator profile.

In T161859#10537957, @Aklapper wrote:

In T161859#10537555, @Bugreporter wrote:

@Aklapper, are you able to export such a mapping? i.e. A list of Phabricator accounts that is connected to both SUL and LDAP, and their connected accounts.

If that's wanted I can provide SQL output (SUL, LDAP, email) - please file a separate subtask assigned to me.
There are 1359 non-disabled, non-bot Phab accounts with both a SUL and LDAP account attached, per
SELECT u.userName AS phabUsername, ue.address AS phabEmailAddress, ua1.username AS sulAccount, ua2.username AS ldapAccount FROM phabricator_user.user u JOIN phabricator_user.user_email ue INNER JOIN phabricator_user.user_externalaccount ua1 INNER JOIN phabricator_user.user_externalaccount ua2 WHERE ue.isPrimary = 1 AND ue.userPHID = u.phid AND ua1.userPHID = u.phid AND ua2.userPHID = u.phid AND u.isDisabled = 0 AND u.isSystemAgent = 0 AND ua1.accountType = "mediawiki" AND ua2.accountType = "ldap";

I can put the list somewhere @bd808 can access

In T161859#10537757, @Ameisenigel wrote:

I am not sure what has happened with my account now, but it is a complete mess. Months ago I have attached my Wikitech account Aneisenigel with my SUL account Ameisenigel. Now this connection has been removed and my account Ameisenigel has been renamed to Ameisenigel~labswiki. Instead my old account Sewepb that I have not used since many years has been renamed to Ameisenigel and connected with my SUL account. Please undo this. Thanks.

I take care of this.

Fixed.

A list of not yet attached accounts with edit in Wikitech: P73433
Number of accounts with

• 1 edit: 1202
• 2 edits: 420
• 3-4 edits: 346
• 5-9 edits: 243
• 10-19 edits: 147
• 20-49 edits: 117
• 50-99 edits: 36
• 100-999 edits: 63
• 1000+ edits: 8

In T161859#10537549, @SunAfterRain wrote:

Hello, I recall that in November last year, I did attach the Wikitech local account (ID: 30300) to the global account SunAfterRain (ID: 55235043). However, it now seems that the global account link has been broken and reattached to the previously abandoned Wikitech local account (ID: 13358). I believe this is a mistake. Could it be restored to its original state?

So I would like to ask if it is possible to undo it?

I check what I can do about it.

In T161859#10540850, @SunAfterRain wrote:

In T161859#10537549, @SunAfterRain wrote:

Hello, I recall that in November last year, I did attach the Wikitech local account (ID: 30300) to the global account SunAfterRain (ID: 55235043). However, it now seems that the global account link has been broken and reattached to the previously abandoned Wikitech local account (ID: 13358). I believe this is a mistake. Could it be restored to its original state?

So I would like to ask if it is possible to undo it?

{{done}}

In T161859#10538605, @Ladsgroup hat geschrieben:

Fixed.

Thank you!

In T161859#10541035, @Ladsgroup wrote:

In T161859#10540850, @SunAfterRain wrote:

In T161859#10537549, @SunAfterRain wrote:

Hello, I recall that in November last year, I did attach the Wikitech local account (ID: 30300) to the global account SunAfterRain (ID: 55235043). However, it now seems that the global account link has been broken and reattached to the previously abandoned Wikitech local account (ID: 13358). I believe this is a mistake. Could it be restored to its original state?

So I would like to ask if it is possible to undo it?

{{done}}

Thanks.

edit: I found that the history of the user talk page seems a bit confusing, can you help fix it?

In T161859#10538749, @Bugreporter wrote:

A list of not yet attached accounts with edit in Wikitech: P73433

Are you attempting to add a requirement that these are all somehow dealt with other than by the current "claim your account or it will be renamed NAME~labswiki" process? If so, what is the hoped for impact of this new requirement and how would you expect it to be addressed?

Not a requirement in any way, but (after matches based on Phabricator) we can still match several of them manually.

What is an issue is some of accounts renamed by you are not yet (force) connected to SUL, such as https://wikitech.wikimedia.org/wiki/Special:Contributions/BCornwall-WMF

In T161859#10542240, @Bugreporter wrote:

What is an issue is some of accounts renamed by you are not yet (force) connected to SUL, such as https://wikitech.wikimedia.org/wiki/Special:Contributions/BCornwall-WMF

I know I missed attaching some of the early manual renames, but maybe one of my scripted runs failed to attach folks too? I just used the action api to pull a list of everyone I renamed since 2025-02-01, stripped out the ~labswiki and usurped ones, and attached them all:

$ curl -s 'https://wikitech.wikimedia.org/w/api.php?action=query&format=json&list=logevents&utf8=1&formatversion=2&leprop=details%7Ccomment%7Cuser%7Cids&letype=renameuser&lestart=2025-02-01T00%3A40%3A04.000Z&ledir=newer&leuser=BryanDavis&lelimit=max'|jq -r '.query.logevents[].params.newuser' | grep -v ~labswiki | grep -v usurped > bryandavis-renamedlog-api.txt
$ mwscript extensions/CentralAuth/maintenance/attachAccount.php --wiki=labswiki --userlist bryandavis-renamedlog-api.txt
[2025-02-12 00:54:30] processed: 375 (139.7/sec); ok: 346 (92.3%); attached: 29 (7.7%); partial: 0 (0.0%); failed: 0 (0.0%); missing: 0 (0.0%);
done.

The announced deadline of 17:00 UTC on 2025-02-24 for making Developer account<->SUL linkage claims has now passed. I have processed all of the linked accounts on Wikitech.

I also undertook a manual audit where I sorted all unattached accounts by edit count and checked the Wikitech account's user page for an obvious claim of connection to a SUL account via usage of https://wikitech.wikimedia.org/wiki/Template:Soft_redirect or just an interwiki link to a SUL account. I got through all accounts with 3 or more historic edits. There are another 1040 accounts with 1-2 edits that I have not reviewed, but at this point I feel like there are diminishing returns for everyone in my investing time in this manual process.

There are 31650 users that are not attached yet and out of those, 11237 have conflicting usernames. I'm about to mass rename them.

Mentioned in SAL (#wikimedia-operations) [2025-02-24T23:38:50Z] <Amir1> mass renaming conflicting usernames in wikitech to have "~labswiki" suffix (T161859)

The renames have finished and only these two left:

ladsgroup@mwmaint2002:~$ sql centralauth -- -e "select ln_name from localnames where ln_wiki = 'labswiki' and ln_name not in (select lu_name from localuser where lu_wiki = 'labswiki' and lu_attached_timestamp like '20%') and ln_name in (select gu_name from globaluser);"
+---------------------------------------------------------------------------------+
| ln_name                                                                         |
+---------------------------------------------------------------------------------+
| Telecommunications relay service, also known as TRS, relay service, or IP-relay |
| \＄A M-IF1015\208                                                               |
+---------------------------------------------------------------------------------+

The first one gives exception:

[8f1974a4-18bb-494c-b375-c2a189529772] 2025-02-25 12:55:29: Fatal exception of type "Wikimedia\NormalizedException\NormalizedException"

I assume because it will push it to above 255 limit.

Both are fixed now. There shouldn't be any user with conflicting username left. About to create global users for all of them.

Technically I should just run migratePass1.php but let's take a look at the code first. See if you spot something:

		$result = $dbBackground->newSelectQueryBuilder()
			->select( 'gn_name' )
			->from( 'globalnames' )
			->caller( __METHOD__ )
			->fetchResultSet();

		foreach ( $result as $row ) {

Many thanks to everyone for working on this massive project!

I ran this instead:

mwscript extensions/CentralAuth/maintenance/migrateAccount.php --wiki=labswiki --auto --homewiki labswiki --safe --userlist unattached_accounts

Which migrated accounts up to:

Email addresses match and are confirmed for: Jiinx~labswiki
CentralAuth account migration for: Jijiki~labswiki
Email addresses match and are confirmed for: Jijiki~labswiki
MediaWiki\Password\PasswordError from line 155 of /srv/mediawiki/php-1.44.0-wmf.17/includes/password/PasswordFactory.php: Invalid hash given

There are a couple of users with reversed hashes, I will see what I can do about them.

Progress:

ladsgroup@mwmaint2002:~$ sql centralauth -- -e "select ln_name from localnames where ln_wiki = 'labswiki' and ln_name not in (select lu_name from localuser where lu_wiki = 'labswiki' and lu_attached_timestamp like '20%');"
+-----------------------------+
| ln_name                     |
+-----------------------------+
| Delete page script          |
| Jijiki~labswiki             |
| MR70                        |
| Shorso~labswiki             |
| \＄A M-IF1015\2008          |
| \＄A M-IF1015\208~labswiki  |
+-----------------------------+

Delete page script may be a wider issue (for want of a better word) than just Wikitech, cf. T386790: 'Delete page script' should have a global account

Now only this left which is a different issue:

ladsgroup@mwmaint2002:~$ sql centralauth -- -e "select ln_name from localnames where ln_wiki = 'labswiki' and ln_name not in (select lu_name from localuser where lu_wiki = 'labswiki' and lu_attached_timestamp like '20%');" 
+--------------------+
| ln_name            |
+--------------------+
| Delete page script |
+--------------------+

It exists in a couple more wikis:

	Delete page script@labswiki
	Delete page script@srwikinews
	Delete page script@test2wiki
	Delete page script@testwiki

I think we are good now. Let me double check with Taavi and then deploy the last patches.

Change #1118561 merged by jenkins-bot:

[operations/mediawiki-config@master] Remove special-casing of CentralAuth for labswiki

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

In T161859#10579966, @Ladsgroup wrote:

Now only this left which is a different issue:

| Delete page script |

That is T386790: 'Delete page script' should have a global account.

Mentioned in SAL (#wikimedia-operations) [2025-02-25T17:57:10Z] <ladsgroup@deploy2002> Started scap sync-world: Backport for [[gerrit:1118561|Remove special-casing of CentralAuth for labswiki (T161859)]]

Mentioned in SAL (#wikimedia-operations) [2025-02-25T18:00:06Z] <ladsgroup@deploy2002> ladsgroup: Backport for [[gerrit:1118561|Remove special-casing of CentralAuth for labswiki (T161859)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2025-02-25T18:07:10Z] <ladsgroup@deploy2002> Finished scap sync-world: Backport for [[gerrit:1118561|Remove special-casing of CentralAuth for labswiki (T161859)]] (duration: 09m 59s)

I dropped these tables:

drop table if exists echo_email_batch;
drop table if exists echo_event;
drop table if exists echo_notification;
drop table if exists echo_target_page;
drop table if exists oathauth_users_restore;
drop table if exists ldap_domains;
drop table if exists external_user;
drop table if exists oauth_registered_consumer;
drop table if exists oauth_accepted_consumer;
drop table if exists oauth2_access_tokens;
drop table if exists oathauth_users;
drop table if exists oathauth_types;
drop table if exists oathauth_devices;
drop table if exists loginnotify_seen_net;

I had to recreate the echo tables. It should read from the x1 tables, it doesn't exist in ruwiki (I checked)

In T161859#10580886, @Ladsgroup wrote:

The last piece was https://gerrit.wikimedia.org/r/1122662 and now wikitech is fully integrated to SUL.

You should also remove all local passwords and emails (or at least confirm there are no more in local database), See T104500: Old versions of sensitive user data (email, password hashes) can remain in database indefinitely due to local and global DB not being kept in sync and T57420: Remove local wiki password hash when CentralAuth has attached account

Well-done, @Ladsgroup and @bd808! Congratulations and thanks for all your great effort in making the Wikitech SUL dream come true! Now, it's time to celebrate the new SUL reality! Goodbye Wikitech account = Developer account and hello Wikitech account = SUL account!

Mentioned in SAL (#wikimedia-operations) [2025-03-03T23:50:47Z] <Amir1> deleted local user_password from labswiki database (T104500 and T161859)