Page MenuHomePhabricator

Investigate options to get block and protection info from remote repository
Closed, ResolvedPublic

Description

  • Ask in TAIM about creating API endpoint (in core) for whether a user is allowed to edit a page (incl. protection and block status)

Event Timeline

Michael created this task.Nov 6 2019, 12:08 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 6 2019, 12:08 PM

endpoint (in core) for whether a user is allowed to edit a page (incl. protection and block status)

+1, sounds like a good idea if there is not already a collection of APIs that can be tied together to do that.
*will have a quick look*

Looks like what you want might already exist

action=query
prop=info (in)

intestactions and intestactionsdetail

Yup, that looks like exactly what we want.

No idea why the Wikipedia app doesn’t use this.

Actually, this doesn’t tell us what the protection level is, and it looks like it might not distinguish between regular and cascading protection either… as far as I know, we want those distinctions for the messages :/

Actually, this doesn’t tell us what the protection level is, and it looks like it might not distinguish between regular and cascading protection either… as far as I know, we want those distinctions for the messages :/

I would hope that shouldn't be too hard to add :)

Indeed, looks like a reasonably extensible format.

It looks like all of the code needed for changes is in the nice new PermissionManager.php in core

Result of investigation by @Matthias_Geisler_WMDE and me:

It looks like all of the code needed for changes is in the nice new PermissionManager.php in core

So this is a bit odd. PermissionManager doesn’t directly return usefully structured objects such as the blockinfo you see in the API response; it returns an array of message key and params. ApiBase::errorArrayToStatus() can then be used to turn this array back into a more useful object, reconstructing a blockinfo object via ApiBlockInfoTrait::getBlockDetails(); ApiQueryInfo calls errorArrayToStatus() for this effect.

We could add something similar for protectioninfo, but it doesn’t really seem necessary. If we add errorformat=raw to the API request, the response for protected pages is more useful:

{
    "code": "protectedpage",
    "key": "protectedpagetext",
    "params": [
        "editprotected",
        "edit"
    ]
},

{
    "code": "cascadeprotected",
    "key": "cascadeprotected",
    "params": [
        1,
        "* [[:Cascading protected page]]\n",
        "edit"
    ]
},

The code/key tells us what kind of protection we’re dealing with; the parameters contain the other information: for regular protection, the right you need to perform the action and the action you wanted to perform; for cascading protection, the number of pages from which the protection cascaded, the list of such pages, and the action you want to perform. We should be able to analyze these errors in our JS code and translate them into our own messages; if we encounter anything unknown, we can fall back to “show whatever error message the API intended”, by making another API request to parse wikitext like {{int:cascadeprotected|1|* [[:Cascading protected page]]|edit}}.

As for blockinfo, one thing that it doesn’t contain is the “intended blockee”. However, as far as we could tell, in current MediaWiki this is always the current user (specifically, $block->getTarget(), which for IP autoblocks is the blocked IP and not the user that the real block targeted), so if we really want to display it, we can get it by adding meta=userinfo to the same API request that gives us the block info, and then use the resulting user name as the “intended blockee”. (There is a Phabricator task for adjusting the intended blockee in case of autoblock, T58227.)


In conclusion: the API request we want to make is

  • action=query
  • titles=item title
  • prop=info
  • intestactions=edit
  • intestactionsdetail=full
  • meta=userinfo
  • errorformat=raw

Plus the usual formatversion=2, and probably a suitable uselang. If response.query.pages[0].actions.edit is not empty, we can’t edit, and the array elements tell us the reason(s), which we can then format ourselves (though we haven’t yet decided how; see T235154#5640545).

Matthias_Geisler_WMDE closed this task as Resolved.Tue, Nov 26, 10:56 AM
Matthias_Geisler_WMDE moved this task from Peer Review to Done on the Wikidata-Bridge-Sprint-10 board.