I would be very careful when introducing the "locked" concept to core. As far as I'm aware, CentralAuth is the only extension that implements this feature, and even there it's meant to be a temporary (yes, I'm aware "meant to be" is a very different thing than what the current reality is) feature that will some day be replaced with proper global blocks.

Change 763328 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/core@master] WIP: Introduce UserLockManager

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

In T301910#7716194, @Majavah wrote:

I would be very careful when introducing the "locked" concept to core. As far as I'm aware, CentralAuth is the only extension that implements this feature, and even there it's meant to be a temporary (yes, I'm aware "meant to be" is a very different thing than what the current reality is) feature that will some day be replaced with proper global blocks.

It is already introduced there in the form of User::isLocked and UserIsLockedHook (and so are global blocks, cf. User::getGlobalBlock and UserIsBlockedGloballyHook). Proceeding with this task will a) refactor the existing logic a bit b) add a support for batch querying. I think that's an okay change.

A different approach would be adding an appropriate interface in te extension. That would, however, not be protected by stable interface policy by default (and thus have the same fundamental issue like hardcoding CentralAuth's schema in GrowthExperiments).

In T301910#7716252, @Urbanecm_WMF wrote:

A different approach would be adding an appropriate interface in te extension. That would, however, not be protected by stable interface policy by default (and thus have the same fundamental issue like hardcoding CentralAuth's schema in GrowthExperiments).

Extensions can opt in the stable interface policy by marking the relevant classes as @stable. I still think I prefer doing that since locks are a CentralAuth feature and not a core one.

In T301910#7716194, @Majavah wrote:

I would be very careful when introducing the "locked" concept to core. As far as I'm aware, CentralAuth is the only extension that implements this feature, and even there it's meant to be a temporary (yes, I'm aware "meant to be" is a very different thing than what the current reality is) feature that will some day be replaced with proper global blocks.

Lock currently have multiple purposes: One is to disallow editing globally (which may be replaced with appealable global blocks); Another is to lock out accounts in emergency (e.g. compromised, or rogue bots); In addition it is used to completely remove access of account (such as globally banned, or unused WMF account). Only #1 are to replaced by global blocks and only #3 are intended to be permanent.

Change 766299 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/CentralAuth@master] Add GlobalUserSelectQueryBuilder

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

Change 763328 abandoned by Urbanecm:

[mediawiki/core@master] Introduce UserLockManager

Reason:

in favour of r766299

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

Thanks for the comments everyone. I uploaded https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/766299 instead, which introduces a GlobalUserSelectQueryBuilder (somewhat based on core's UserSelectQueryBuilder).

Change 766299 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] Add GlobalUserSelectQueryBuilder

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