| • NHarateh_WMF | |
| Jul 18 2019, 3:28 PM |
| F29800814: IMG_DA00009919D0-1.jpeg | |
| Jul 18 2019, 3:28 PM |
| F29800811: IMG_A576760E46DA-1.jpeg | |
| Jul 18 2019, 3:28 PM |
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Hide edit buttons by default | mediawiki/services/mobileapps | master | +13 -0 |
This one is a bit more involved since this information may be user specific and RESTBase only stores one version for all users.
That problem has been solved in the Android app for /page/mobile-sections by looking at the editable and protection fields and comparing that with the groups the user is a member in.
Snippet of mobile-sections-lead output (e.g. https://en.wikipedia.org/api/rest_v1/page/mobile-sections-lead/Dog):
"protection": { "edit": [ "autoconfirmed" ], "move": [ "sysop" ] }, "editable": false,
We can get the protection field from the metadata endpoint (https://en.wikipedia.org/api/rest_v1/page/metadata/Dog).
Not sure if we've missed to include the editable field in the metadata output or if it was deemed redundant by the absence of protection.edit. @Mholloway: do you remember?
The main entries for the Android code are:
[1] https://phabricator.wikimedia.org/diffusion/APAW/browse/master/www/js/main.js (should probably be moved to the pagelib)
[2] https://phabricator.wikimedia.org/diffusion/APAW/browse/master/app/src/main/java/org/wikipedia/page/PageFragmentLoadState.java$452 (incl. miscPayload(), isPageEditable(), Not sure yet where this should live but would be nice to do in the pagelib as well for consistency sake.)
[3] https://phabricator.wikimedia.org/diffusion/APAW/browse/master/app/src/main/java/org/wikipedia/dataclient/restbase/page/RbPageLead.java$185 is a special case for RESTBase. It's the part that changes the editable flag from false to true if the logged in user is a member of a group mentioned in the protection.edit field.
Android JS code:
Inputs on the native side:
The native Android side is spread all over the place but I'm trying to summarize:
I'm not sure if (c) is correct or if it should affect the protected flag instead. I think one could make a case for showing the protected edit pencils in this case. Then only the protected flag would be user specific.
Long-term I think it would be more better to add it and to the mobile-html payload (together with other metadata, like the ToC) to avoid user visible changes of the edit pencils because they might change after the metadata response is loaded.
For now the proposal is to expose a simple function to setEditButtons({editable, protected}).
Clients would then determine what the values for editable and protected would be.
That client side determination is probably a combination of the protection field in the metadata endpoint response, the user logged-in state, and remote config, similar to what I outline above.
We're leaning towards initially hiding the edit buttons initially then showing them after setEditButtons is called.
The pagelib PR[1] is ready for review but we might need some server side code to make sure we start out with hidden edit pencils to avoid FoUC.
[1] https://github.com/wikimedia/wikimedia-page-library/pull/232
Change 526006 had a related patch set uploaded (by BearND; owner: BearND):
[mediawiki/services/mobileapps@master] Hide edit buttons by default
What we have right now ready to deploy:
pagelib: added Page.setEditButtons(isEditable, isProtected)
PCS server: stop showing edit pencils by default
One question remains, which is client may need to also know if the current page is a main or file page since in these cases we don't want to edit pencils to be shown either.
We can either expose a few additional flags to the Page module or override isEditable in setEditButtons() internally to set it to false if the client set it to true but it was on a main or file page. (Maybe rename it to setEditButtonsForRegularPages() or similar?) Thoughts?
Change 526006 merged by jenkins-bot:
[mediawiki/services/mobileapps@master] Hide edit buttons by default
Do clients have a reason to care what the underlying reason is for a page not being editable (by the current user)?
@bearND the clients can be responsible for checking if it's a main page or a file page and setting the correct edit pencil state