Before doing so in my opinion we need to:

1. Find all currently unattached accounts and rename or merge them (this is basically doing SUL finalisation again, but in a much smaller scale).
2. After this, we can treat all accounts as mergable - i.e. local accounts not linked to CentralAuth will be automatically attached to global user (if global user does not exist, one will be created); this will also resolve T275931: Have new MassMessage system users be automatically attached to CentralAuth. Unattached local accounts does not work with SUL3.
3. Remove code that deals with unattached accounts; and also remove the feature to merge account (since it will be completed automatically).

Note: Currently stewards (and formerly bureaucrats) can rename local users. Currently they will become unattached; After this task, renamed local users will be automatically attached to new global account.

Note 2: When locally renamed users become unattached (which is the current situation), the MergeUser special page and centralauth-merge right is still useful. They should not be removed for now.

In T367968#9908254, @Bugreporter wrote:

Before doing so in my opinion we need to:

1. Find all currently unattached accounts and rename or merge them (this is basically doing SUL finalisation again, but in a much smaller scale).

Just going to cross link that not all unattached accounts *can* be attached/merged, c.f. T235446 - I don't know about other people's accounts, but I know that https://meta.wikimedia.org/wiki/Special:CentralAuth/DannyS712_(T235446) was created as an unattached local account because otherwise I was unable to login on that wiki at all

In https://phabricator.wikimedia.org/diffusion/ECAU/browse/master/includes/CentralAuthPrimaryAuthenticationProvider.php$243, CentralAuth will reject login for central users if the local account is not attached. Since I propose to get rid of "unattached account" concept, we would remove this check completely. In addition the AutoMigrate logic in line 221-241 will also become useless.

Also CentralAuth currently check whether a local account is attached by maintaining a localnames table which stored all (potentially unattached) local user names, and compare it with a localuser table which only store attached users. The localnames table should be removed and any usage should be moved to localusers table.

Note the current usages of localnames table (other than maintanence scripts and tests) are limit to one single class: CentralAuthUser, of which localnames is used 5 times:

• storeMigrationData: write to localnames can be safely removed
• doListUnattached: drop the whole function (unattached users will not exist anymore)
• addLocalName, removeLocalName and updateLocalName: drop the function and all usages.

In T367968#9908268, @DannyS712 wrote:

In T367968#9908254, @Bugreporter wrote:

Before doing so in my opinion we need to:

1. Find all currently unattached accounts and rename or merge them (this is basically doing SUL finalisation again, but in a much smaller scale).

Just going to cross link that not all unattached accounts *can* be attached/merged, c.f. T235446 - I don't know about other people's accounts, but I know that https://meta.wikimedia.org/wiki/Special:CentralAuth/DannyS712_(T235446) was created as an unattached local account because otherwise I was unable to login on that wiki at all

For this case, it is more likely that there are somehow no record in localuser table, so CentralAuth treated such user as "unattached". Removing the isAttached check will make login successful, but may cause other problems for codes rely on localuser table. A simple way is attach the account when a CentralAuthUser object is created. I am not sure whether it causes other issues (e.g. CentralAuthUser object may be created on GET request and it may be problematic if we do database write), or whether it will fix data inconsistency for accounts that did not login in normal way after SUL finalization (including T275931). We should guarantee new local users created in any way (including new system user) are connected to SUL though.

Closing as duplicate for now; but may be reopened if the target task is declined.

In T367968#9916294, @Bugreporter wrote:

Closing as duplicate for now; but may be reopened if the target task is declined.

In the future please remember to close the newer task as a duplicate of the older task instead of the other way around

In T367968#9916307, @DannyS712 wrote:

In T367968#9916294, @Bugreporter wrote:

Closing as duplicate for now; but may be reopened if the target task is declined.

In the future please close the newer task as a duplicate of the older task instead of the other way around

In the new task I proposed a different solution, so I leave the old (current) one for reference in case the new one got declined.