Page MenuHomePhabricator

"blockinfo" field from list=allusers do not reflect global blocks
Open, LowestPublic

Description

Currently ApiQueryAllUsers and ApiQueryUsers report block information only for local blocks. It would be nice if extensions implementing global blocks could/would somehow hook into these modules to provide information for non-local blocks as well.

Any such solution must not result in 5000 single-user database queries being made for something like action=query&list=allusers&aulimit=5000&auprop=blockinfo.


Original report:

(I see it as a bug but ok to call it a current API feature)

It is often needed to get a list of all participants of a given Wikimedia subproject X, filtered by different criteria: not indefinitely blocked in X, not currently blocked, registration date, number of edits etc. The most prominent use by myself - public lists of potential candidates and voters for each ArbCom elections since ca. 2012

While doing similar for Russian Wikinews I have discovered that it is highly difficult to sort out indefinitely blocked. Because "blockinfo" field reports only locally blocked but not globally blocked ("locked" in the project lingo).

Let's take Russian Wikinews and two indefinitely blocked there: Hhhggg and LskAndrew.

The last one is blocked by a local admin and it is easy to see it from blockinfo:

https://ru.wikinews.org/w/api.php?format=jsonfm&action=query&list=allusers&aulimit=1&auprop=blockinfo&aufrom=LskAndrew

https://ru.wikinews.org/w/api.php?format=jsonfm&action=query&meta=globaluserinfo&guiuser=LskAndrew

But the first one from the point of view of the AP is still here with us:

https://ru.wikinews.org/w/api.php?format=jsonfm&action=query&list=allusers&aulimit=1&auprop=blockinfo&aufrom=Hhhgg

It took sime time to find two rather convoluted solutions to that, both from a previously obtained list for a separate check for each list item:

https://ru.wikinews.org/w/api.php?format=jsonfm&action=query&meta=globaluserinfo&guiuser=Hhhggg

and then if ( 'locked' in MyJsonObject.query.globaluserinfo )

or

https://meta.wikimedia.org/w/api.php?format=jsonfm&action=query&list=logevents&letype=globalauth&letitle=user:Hhhggg@global

and then if ( MyJsonObject.query.logevents.length > 0 )

is anything more reasonnable can be proposed from the interface?

Event Timeline

Neolexx created this task.Oct 19 2018, 5:23 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 19 2018, 5:23 PM
Neolexx updated the task description. (Show Details)Oct 19 2018, 5:30 PM
Neolexx updated the task description. (Show Details)Oct 19 2018, 5:33 PM
Neolexx updated the task description. (Show Details)
MBH added a subscriber: MBH.Oct 19 2018, 5:43 PM

To further explain "anything more reasonnable" as I see it, three options:

  1. Good

Add to list=allusers new property auindefblocked. If set then that user is indefblocked irrespectively how: straight in that subproject, by a steward, by am emergency midnight Foundation meeting, anything else.

  1. Greate

To make the property blockinfo reflect any type of (b)lock info, local or global.

  1. Fantastic

All as (2) plus introduce new virtual group indefblocked so could be used with auexcludegroup. This way queries will not report thousands and thousands useless items to filter out client-side.

Anomie added a subscriber: Anomie.Oct 22 2018, 1:38 PM

Which "blockinfo" are you talking about?

  • Various error messages report blockinfo when some action is prevented due to a block. It would be up to User::getBlock() to return something appropriate.
  • meta=userinfo does basically the same.
  • list=allusers and list=users report only block info for local blocks, as these are the only ones that can be efficiently queried in bulk.
  • list=blocks similarly reports only local blocks.

I guess from your examples that you're talking about the third bullet.

  1. Add to list=allusers new property auindefblocked. If set then that user is indefblocked irrespectively how: straight in that subproject, by a steward, by am emergency midnight Foundation meeting, anything else.

There would be no point to that. If we could do that efficiently, we'd most likely already be doing #2.

  1. To make the property blockinfo reflect any type of (b)lock info, local or global.

For list=allusers and list=users, doing this would require some mechanism for making such queries efficiently in bulk. We don't want to be doing 500 single-user queries for each extension that implements global blocking of some sort.

  1. All as (2) plus introduce new virtual group indefblocked so could be used with auexcludegroup. This way queries will not report thousands and thousands useless items to filter out client-side.

Since virtual groups can't be used with auexcludegroup in the first place (only groups that are tracked in the user_groups table), that's not going to be possible either.

Anomie renamed this task from "blockinfo" field from API request do not reflect globally blocked (locked) accounts to "blockinfo" field from list=allusers do not reflect global blocks.Oct 22 2018, 1:42 PM
Anomie triaged this task as Lowest priority.
Anomie updated the task description. (Show Details)
Anomie moved this task from Unsorted to Needs details or plan on the MediaWiki-API board.
Arbnos added a subscriber: Arbnos.Oct 25 2018, 1:42 AM
Restricted Application added a project: Platform Engineering. · View Herald TranscriptMar 23 2020, 11:11 AM
Aklapper removed a subscriber: Anomie.Oct 16 2020, 5:03 PM