if any page semi-protected (for confirm users), autopatrolled or editors users can't edit page. popup message say (you don't have permissions to edit this page), please solve it.
Description
Description
Details
Details
Customize query in gerrit
Related Objects
Related Objects
Event Timeline
Comment Actions
I confirm this issue on lastest version at cswiki. I tried to edit semiprotected page with sysop account, it wasn't possible. Please fix it soon.
Comment Actions
Change 313032 had a related patch set uploaded (by BearND):
Check user group memberships on protected pages
Comment Actions
@bearND Could you please add a little discussion here about what's actually going wrong (e.g., is this indeed specific to MCS, and if so, how?) and the approach you've taken to fix it? It's hard to evaluate https://gerrit.wikimedia.org/r/#/c/313031 and https://gerrit.wikimedia.org/r/#/c/313032 without a little more background. (For instance, why would the protection/editable metadata from the Action API be good enough for one loading strategy but not the other?)
Comment Actions
Marked it with Regression tag to better track changes other clients of MCS need to be aware of when transitioning from mobileview action to MCS.
Comment Actions
@Mholloway The problem is that with the highly cached responses we get from RESTBase the app doesn't get any user specific responses anymore. In the case of a semi-protected page, it would return false, no matter as what user one is logged in when the page is requested because it retrieves and stores the content in RB without any user logged in.
Instead of taking that as the truth we could consider the value of "editable" in the lead response to be "editable for anonymous users". To be able to do that we need to retrieve the group membership information for a logged in user first. Then for pages which have editable set to false we can check group memberships to see if any group a user belongs to is allowed to edit that page.
(In contrast to that, the action=mobileview api response is specific to a user. So, the editable field there would be true if the user has permission to edit the page.)
Comment Actions
Change 310220 had a related patch set uploaded (by BearND):
Hygiene: Decouple user mgmt from app and storage
Comment Actions
Change 313031 had a related patch set uploaded (by BearND):
Retrieve group membership info when logging in
Comment Actions
Change 310220 merged by jenkins-bot:
Hygiene: Decouple user mgmt from app and storage
Comment Actions
Testing on Wikipedia build 2.4.158-alpha-2016-10-13 on Samsung Galaxy SIII (Android 4.4.2). I attached below what I see when I'm not allowed to edit a page. If there's any further testing I should do such as checking another article please let me know. It looks fixed to me.
Comment Actions
Hi @Nicholas.tsg. Do you or someone there have a Wikipedia user account that has made five or more edits and has been around at least a couple of weeks?
The issue in this task is that users with accounts that meet minimum criteria should be able to edit "semi-protected" pages. Barack Obama on English Wikipedia is one example.
Before this patch, the app was not allowing logged in users with such accounts to edit semi-protected pages. This patch is to ensure they have the correct editing rights.
So, steps to QA:
- Log in with a well-established account (feel free to ask here or on IRC if you're not sure if the account you use meets the minimums)
- Go to the Barack Obama article on English Wikipedia
- Ensure the following:
- The edit pencil buttons do not show a lock symbol
- When you click an edit button, the editing activity is launched rather than the "This page is protected" dialog
Sorry this wasn't clear before. Please recheck this one and update here. Thank you!
Comment Actions
It's working for me in 2.4.158-beta-2016-10-13 for Android where I could open the edit view for w:en:Barack Obama (as opposed to earlier, when I couldn't even edit a semi-protected page on a language version where I'm an admin). Also tested saving an edit on a semi-protected page (w:sv:Barack Obama) which worked fine.
Comment Actions
This has been well tested by the dev team and others (thanks for the report, @Johan!) so let's consider it ready for signoff.