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.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| api: add list=globalusers query | mediawiki/extensions/CentralAuth | master | +416 -0 |
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.