Page MenuHomePhabricator

Add some way to technically distinguish partial blocks and full blocks
Closed, ResolvedPublic3 Estimated Story Points

Description

Recently Russian Wikipedia got the partial block feature (see [[m:Community health initiative/Partial blocks]])

The first usage case show that it seems impossible to check if user is partially blocked and fully blocked.

Consider two actual users. 1st is partially blocked (some namespaces closed) - 2nd is fully blocked (old way). Yet from the db these are two identical cases with blockexpiry="infinity":

  1. https://ru.wikipedia.org/w/api.php?action=query&format=xmlfm&list=users&ususers=Schekinov%20Alexey%20Victorovich&usprop=blockinfo
  2. https://ru.wikipedia.org/w/api.php?action=query&format=xmlfm&list=users&ususers=Александр%20Мотин&usprop=blockinfo

My proposal is to add some extra flag that would be raised for partially blocked. So the response would be like ...blockexpiry="infinity" ocked=""... Or anything else instead of "ocked".

I have no big hope that this task will get some priority but at least wanted to point to a problem - unless I'm missing something.

Event Timeline

Neolexx created this task.Sep 4 2019, 6:19 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 4 2019, 6:19 PM
Restricted Application added a subscriber: MGChecker. · View Herald TranscriptSep 4 2019, 7:54 PM

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?

Restricted Application added a project: Platform Engineering. · View Herald TranscriptSep 4 2019, 9:30 PM
Neolexx added a comment.EditedSep 4 2019, 10:30 PM

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.

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.

MBH added a subscriber: MBH.Sep 5 2019, 12:43 AM

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).

Anomie moved this task from Unsorted to Needs Code on the MediaWiki-API board.Sep 5 2019, 2:31 PM
Niharika triaged this task as Medium priority.Sep 5 2019, 6:29 PM
Niharika set the point value for this task to 3.
Anomie claimed this task.Sep 5 2019, 6:36 PM
Anomie added a subscriber: Anomie.

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.

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

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

Neolexx added a comment.EditedSep 8 2019, 10:19 AM

(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.

mobrovac closed this task as Resolved.Sep 18 2019, 10:10 AM

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

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

Aklapper removed a subscriber: Anomie.Oct 16 2020, 5:41 PM