Gadget-markblocked.js puts blocked users names in strikeout style. This is incredibly useful. Unfortunately, it doesn't handle globally locked users, apparently because there's no efficient way to check a set of users to see which ones are glocked, using the current API.
See this thread on enwiki for background, and suggestions for how it might be implemented.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T399291 Epic: API Rate Limiting Architecture | |||
| Resolved | • matmarex | T424846 Use a more efficient API in mark-locked.js user script and similar scripts/gadgets | |||
| Resolved | Dragoniez | T261752 Add an API module to display status of multiple globally locked users | |||
| Resolved | BUG REPORT | Dragoniez | T425859 InvalidArgumentException in list=globalusers API module with gusprop=rights | ||
| Resolved | PRODUCTION ERROR | Dragoniez | T426033 PHP Warning: unserialize(): Error at offset 0 of 13 bytes (in CentralAuth) |
Might not be needed once T237505: Globaluserinfo API module should allow getting data for more than one user at once allows using CentralAuth's api for this
There is list=globalallusers which mirrors list=allusers but provides central user information, and similarly for list=userinfo / list=globaluserinfo, but there is no list=globalusers to match list=users. Adding that as a separate endpoint seems nicer than trying to hack it into globaluserinfo.
I think I tentatively could try taking a stab at this, though I will likely need a good bit of guidance. The API I have worked out currently would take users/userids and a multiparam of existslocally and locked. Its return schema would then be the same as list=allusers with the requested properties. Hidden users (if auth'd to see that) would get a hidden: true flag in their response.
I'm intentionally keeping the properties that can be requested limited since that's always something that can be added onto in the future while keeping backwards compatibility. (Most notably, I'm not including global groups as it looks like when using GlobalUserSelectQueryBuilder you can't easily get the groups of the requested users all in one query, and I'm not totally sure the best way to approach fixing that. Another probably nice property would probably be account attachment status which could include local blocks, I think?)
Probably the only thing I'm very unsure on right now is tests since it seems like CentralAuth doesn't have any API-specific tests, unless I'm missing somewhere obvious, and I'm not sure if there's any examples of an APIQuery that's tested via PHPUnit or something?
CentralAuth's test coverage is pretty bad, but core has plenty of similar examples. You subclass your test class from ApiTestCase and then use doApiRequest() for a simulated API request.
Ah! Thank you, that works great. The only issue I'm running into is testing if a user is attached locally—it seems that no matter what I do (via TestUser or CentralAuthTestUser), they're never actually made to be local according to CentralAuthUser::existsLocally. I assume there's just some method that I'm missing here, though I suppose it doesn't help that I don't really know the difference between an account being attached and it existing locally. (I think the latter is that the user simply exists in that wiki's DB but I could be wrong.)
Edit: Figured it out! The user creation hooks were being skipped because I'm using getMutableTestUser, so localusers was never getting updated. I just needed to add an addLocalName call.
Change #1182253 had a related patch set uploaded (by Perryprog; author: Perryprog):
[mediawiki/extensions/CentralAuth@master] api: add list=globalusers query
You can either set up the CentralAuth services for CentralIdLookUp and PrimaryAuthenticationProvider (you can look at how other tests do it) - there is no way to have different defaults for CentralAuth tests and for core tests which run when the CentralAuth extension is installed, so by default we just disable most CentralAuth stuff for tests (via DevelopmentSettings.php overrides).
Or you can use CentralAuthTestUser to create your test users (gerrit 1176315 makes that more convenient to use - not merged yet, but you can just steal the relevant part), that works regardless of what authentication services are configured.
The second approach is less structurally sound but much easier. Testing CentralAuth APIs with CentralAuth actually not enabled as an authentication provider etc. sounds iffy, but actually it surprisingly rarely becomes a problem.
Hm—I might not be following completely. What I have right now is one usage of CentralAuthTestUser (though I think maybe not strictly necessary now that I think about it) in order to have a non-locally existing user. The rest of the users are then made with getMutableTestUser when I then call CentralAuthUser::getPrimaryInstance on and then register, attach (to current wikiId), and insert into localnames (also for current wikiId). This seems to work okay, unless there's a subtlety that I'm missing.
Moving back to WMP triage for re-assessment. Gadget-markblocked.js is currently making hundreds or even thousands of API requests when visiting a discussion page, which can trigger API rate limits and prevent further API use (e.g. for discussion tools) until the counter resets. This seems like a serious issue since that gatdget is popular with wiki admins. Providing a better API would fix that problem.
User:GeneralNotability/mark-locked.js is the one that is popular with English Wikipedia administrators.
I have a draft patch for this that's about 60% complete and has been sitting in my local repo for months. Now that this task has become more important because of the recent update to rate limits, I'll prioritize working on it (hopefully this weekend).
Change #1282288 had a related patch set uploaded (by Dragoniez; author: Dragoniez):
[mediawiki/extensions/CentralAuth@master] API: Introduce list=globalusers
Change #1182253 abandoned by Bartosz Dziewoński:
[mediawiki/extensions/CentralAuth@master] api: add list=globalusers query
Reason:
Superseded by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CentralAuth/+/1282288
Change #1282288 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@master] API: Introduce list=globalusers
The change can be tested on the beta cluster. For example: https://en.wikipedia.beta.wmcloud.org/wiki/Special:ApiSandbox#action=query&list=globalusers&gusprop=locked|registration&gususers=CarmaHawk8294|Kellee6805|Loren85996441374
I'll schedule a deployment to production wikis for Monday: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20260511T1300
Change #1285462 had a related patch set uploaded (by Bartosz Dziewoński; author: Dragoniez):
[mediawiki/extensions/CentralAuth@wmf/1.47.0-wmf.1] API: Introduce list=globalusers
Change #1285462 merged by jenkins-bot:
[mediawiki/extensions/CentralAuth@wmf/1.47.0-wmf.1] API: Introduce list=globalusers
Mentioned in SAL (#wikimedia-operations) [2026-05-11T13:38:44Z] <lucaswerkmeister-wmde@deploy1003> Started scap sync-world: Backport for [[gerrit:1285460|Prevent username registration if the username previously existed (T196386)]], [[gerrit:1285461|Prevent username registration if the username previously existed (v2) (T196386)]], [[gerrit:1285462|API: Introduce list=globalusers (T261752)]], [[gerrit:1285761|list=globalusers: Avoid querying group permissions with empty group list (T
Mentioned in SAL (#wikimedia-operations) [2026-05-11T14:04:32Z] <lucaswerkmeister-wmde@deploy1003> matmarex, lucaswerkmeister-wmde: Backport for [[gerrit:1285460|Prevent username registration if the username previously existed (T196386)]], [[gerrit:1285461|Prevent username registration if the username previously existed (v2) (T196386)]], [[gerrit:1285462|API: Introduce list=globalusers (T261752)]], [[gerrit:1285761|list=globalusers: Avoid querying group permissions with empty group
Mentioned in SAL (#wikimedia-operations) [2026-05-11T14:18:07Z] <lucaswerkmeister-wmde@deploy1003> Finished scap sync-world: Backport for [[gerrit:1285460|Prevent username registration if the username previously existed (T196386)]], [[gerrit:1285461|Prevent username registration if the username previously existed (v2) (T196386)]], [[gerrit:1285462|API: Introduce list=globalusers (T261752)]], [[gerrit:1285761|list=globalusers: Avoid querying group permissions with empty group list (
@matmarex Thanks for the backport!
The details of the new API module can now be viewed at https://www.mediawiki.org/w/api.php?action=help&modules=query+globalusers