Lucas_Werkmeister_WMDE added a comment.
Things we can do: - Add the protection level of the client page to the data bridge config. (We tested that protecting/unprotecting the page resets the parser cache, so this should be safe to do.) - Check `mw.config.get( 'wgIsProbablyEditable' )` <https://www.mediawiki.org/wiki/Manual:Interface/JavaScript> client-side as early as we want. If it’s `false`, we can check the protection level (previous bullet point) to estimate whether it’s due to protection or block. - Make an API call to the repo as soon as the app opens (but not before, that would be too many API calls – a. k. a. at bridge init), getting the user blocks+rights and entity protection with one call: `action=query&meta=userinfo&uiprop=blockinfo|rights|groups&titles=Item:Q1234&prop=info&inprop=protection` <https://www.wikidata.org/wiki/Special:ApiSandbox#action=query&format=json&prop=info&meta=userinfo&titles=Q1&redirects=1&formatversion=2&inprop=protection&uiprop=blockinfo%7Crights%7Cgroups>. - This, however, requires that we know the //title// of the entity page (and the `Special:EntityPage/Q1234` workaround doesn’t work here). We might have to resurrect the `repoNamespaces` client option, which currently exists but seems to be unused. - We can also split the `meta=userinfo` part out of this and add a `maxage` parameter to it, so that it will be cached client-side for an appropriate amount of time. This probably doesn’t reduce server load (the call to get the page information will likely load user rights anyways), but it reduces the response size, saving our users some network traffic. Things we can’t do: - Add whether the user is blocked or not to the data bridge config – this would be embedded in the parser cache and be shared between different IP users, where the blocked status may be different. (Hence the “probably” in the existing `wgIsProbablyEditable` variable.) The earliest point where we can make these checks is at app init – so in some cases the user may see the loading screen before being told that actually, they can’t edit. This also implies that we’re estimating permissions client-side, based on the user’s rights, blocks, and the page’s protections. If that’s not good enough, we may need to introduce an API call for checking whether a user can edit a page (effectively an interface to `PermissionManager`, though we only need `$action = 'edit'`), which currently doesn’t seem to exist. (This could be achieved by making a “null edit” to the entity – `action=wbeditentity&data={}`, which can even replace the current entity download – but that means a hit to the master DB every time the app opens.) It would seem that the Wikipedia Android app should have the same need for such an API, but it appears to estimate permissions client-side as well <https://github.com/wikimedia/apps-android-wikipedia/blob/f0650cf2357abbdcc70b06de9c6eaf98cee52305/app/src/main/java/org/wikipedia/dataclient/restbase/page/RbPageLead.java#L185-L192>. TASK DETAIL https://phabricator.wikimedia.org/T231209 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE Cc: Pablo-WMDE, jeblad, Aklapper, Lydia_Pintscher, darthmon_wmde, Michael, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
