Oh there is a way to do this on ApiQueryUserInfo but not with ApiQueryUsers. It looks like the later is not using the ApiBlockInfoTrait like the former is.

If we implement the same logic there, in the user list, then the API would return a blockpartial property which is a boolean that indicates if the block is partial or sitewide (whatever it says in the database).

@Neolexx I want to understand the use case better - are you using this query for an external tool?

I want to understand the use case better - are you using this query for an external tool?

First we have an official (in user settings) and rather popular gadget "Strike out names of blocked users" (for personal pages and links) [[w:ruВикипедия:Гаджеты/Зачеркнуть заблокированных]]. With style gradations for temporary blocked and infinitely blocked. The gadget relies mostly on its own lists - to not extra bother API with queries. Yet the lists are periodically updated by API queries. And currently it breaks the automation because you either support a separate list manually - or need to add nearly an A.I. level logic to sort out new way blocked and old way blocked.

Also I support lists of ArbCom potential candidates and electors [[w:ru:Участник:Neolexx/АК-28/voters|like this]] where blockinfo is used to filter out.

Also there is "notify me of any current elections" template that pings each subscriber. It is served by [[w:ru:Обсуждение участника:Bot of the Seven|a daiy daemon]] And currently the daemon is instructed do not ping indefinitely blocked.

So yes, I see quite a lot of reasons to be able to have it automated via API queries without manual lists. So far we have exactly one "new way blocked" so like no big deal. It will be a dozen of them - it becomes a hassle. It will be a hundred of them - it becomes an annoying hassle. Programmatically I mean.

In T232021#5466316, @dbarratt wrote:

Oh there is a way to do this on ApiQueryUserInfo but not with ApiQueryUsers.

And meta=userinfo query (if you mean that) applies only to the current user - so namely a tool to get extended info about yourself and yourself only. So rather useless for the job.

In T232021#5466785, @Neolexx wrote:

And meta=userinfo query (if you mean that) applies only to the current user - so namely a tool to get extended info about yourself and yourself only. So rather useless for the job.

I understand. I wasn't attempting to imply that was a viable work-around, only that this is something that is done in other endpoints, so it seems reasonable to add it to this one (and I was actually surprised it wasn't already).

In T232021#5469164, @Anomie wrote:

Probably it was done that way to avoid the possibility of thousands of individual SELECTs to load the blocks one at a time.

Ah. That is fine to make it a single query like Special:BlockList does, but it ought to reveal blockedpartial in the same way as userinfo. :)

Change 534661 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/core@master] API: Use ApiBlockInfoTrait in ApiQueryUsers and AllUsers

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

(update) It seems that currently there is a way to check partial blocks by a 3rd party - through list=blocks query where boolean partial will be set then. For the test case (obviously it's JSON for practical things, I'm using xmlfm just for visual convenience here): https://ru.wikipedia.org/w/api.php?action=query&format=xmlfm&list=blocks&bkusers=Schekinov%20Alexey%20Victorovich

So it is partial here and it will be blockedpartial when and if implemented for other queries. But it's OK, as long as all flag name variants are known to developers so to know what to check against.

Change 534661 merged by jenkins-bot:
[mediawiki/core@master] API: Use ApiBlockInfoTrait in ApiQueryUsers and AllUsers

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