Lucas_Werkmeister_WMDE added a subscriber: Matthias_Geisler_WMDE. Lucas_Werkmeister_WMDE added a comment.
Result of investigation by @Matthias_Geisler_WMDE and me: In T237522#5640588 <https://phabricator.wikimedia.org/T237522#5640588>, @Addshore wrote: > 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”. --- 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 <https://phabricator.wikimedia.org/T235154#5640545>). TASK DETAIL https://phabricator.wikimedia.org/T237522 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE Cc: Matthias_Geisler_WMDE, Lucas_Werkmeister_WMDE, Addshore, Aklapper, Michael, darthmon_wmde, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
