bingle-admin wrote:

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/CfvFwqA9

You seem to be right about protection. Only authors seem to be able to edit the page.

Amir can you paste

mw.mobileFrontend.getCurrentPage().isEditable( mw.user).done( function(r) { console.log(r); });
mw.user.getGroups().done( function(a) { console.log( a ); } );
mw.config.get( 'wgRestrictionEdit', [] );

into your console for this page and report back what it says?
I think this will give the information needed to make this bug actionable.

mw.mobileFrontend.getCurrentPage().isEditable( mw.user).done( function(r) { console.log(r); });

Object { resolve: .Deferred/</deferred[tuple[0]](), resolveWith: jQuery.Callbacks/self.fireWith(), reject: .Deferred/</deferred[tuple[0]](), rejectWith: jQuery.Callbacks/self.fireWith(), notify: .Deferred/</deferred[tuple[0]](), notifyWith: jQuery.Callbacks/self.fireWith(), state: .Deferred/promise.state(), always: .Deferred/promise.always(), then: .Deferred/promise.then(), promise: .Deferred/promise.promise(), 4 more… }
false

mw.user.getGroups().done( function(a) { console.log( a ); } );

Object { state: .Deferred/promise.state(), always: .Deferred/promise.always(), then: .Deferred/promise.then(), promise: .Deferred/promise.promise(), pipe: .Deferred/promise.then(), done: jQuery.Callbacks/self.add(), fail: jQuery.Callbacks/self.add(), progress: jQuery.Callbacks/self.add() }
Array [ "epcampus", "epcoordinator", "epinstructor", "eponline", "sysop", "*", "user", "autoconfirmed" ]

mw.config.get( 'wgRestrictionEdit', [] );

Array [ "autopatrol" ]

Okay, I can replicate it

According to your permissions you fall into the [ "epcampus", "epcoordinator", "epinstructor", "eponline", "sysop", "*", "user", "autoconfirmed" ] groups

The page is restricted so that only the autopatrol group can edit it a group which according to above you are not in.

Why does autopatrol not show up in your groups?

I assume 'sysop' is like a wildcard? It should probably either show up in 'wgRestrictionEdit'...

Smells like an issue in core...

Hmm, this seems to be a problem how we check, if your group is allowed to edit this page. While desktop checks the rights of your impliziet and explicit user groups, we are using the build in mediawiki routine User.getGroups to get the list of groups you actually belong to. The problem is, that this list includes only explicit groups, but implicit groups (e.g. that you're autoconfirmed when you're in sysop group) are missing :/

Mm.. how can we get implied groups?

Sorry, my first thought was false. getGroups already returns all effective groups for the user, which is, what we want. But now i have seen the following:
We get the restrictions for a page from our mobileview api module, which adds the protection levels here: https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/api/ApiMobileView.php#L653

Title::getRestrictions() returns an array of _rights_ the user needs to edit this page (in case of the example page above it is autopatrol, see https://he.wikipedia.org/w/index.php?title=%D7%9E%D7%99%D7%95%D7%97%D7%93:%D7%90%D7%A8%D7%92%D7%96_%D7%97%D7%95%D7%9C_%D7%9C%D6%BEAPI&uselang=en#action=mobileview&format=json&page=%D7%95%D7%99%D7%A7%D7%99%D7%A4%D7%93%D7%99%D7%94%3A%D7%91%D7%95%D7%93%D7%A7%2F%D7%91%D7%A7%D7%A9%D7%95%D7%AA_%D7%9C%D7%91%D7%93%D7%99%D7%A7%D7%94%2F%D7%90%D7%A8%D7%9B%D7%99%D7%95%D7%9F_18&prop=protection).

In Page.js we check the user _groups_ against the returned user _rights_ to see, if the user is allowed to edit the page:
https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/javascripts/Page.js#L85

This results in the following check (as an example):

if ( $.inArray( sysop, autopatrol ) > -1 ) {

(and for all other groups the user belongs to). That's a real problem: It will work until we use the standard groups and restriction levels (where the group name and the right is the same, see [[$wgRestrictionLevels]]), but not, if there are additional groups like on hewiki. If @Amire80 is able to test it: it will still not work, if you give yourself the user group "autopatrolled", because the group name is different from the right name (autopatrolled <> autopatrol).

I'm not sure, but this looks like a small security issue, too, because it's not the intended behavior of wgRestrictionLevels (e.g. what, if you give a group the name "autopatrol" but not the right autopatrol, they can edit it in MF, but not on desktop).

Change 178793 had a related patch set uploaded (by Florianschmidtwelzow):
Use user rights to check, if the user can edit page

https://gerrit.wikimedia.org/r/178793

Patch-For-Review

Thanks @Amire80 and @Legoktm I can read this again! :)

Change 178793 merged by jenkins-bot:
Let PHP check, if the user can edit a page or not

https://gerrit.wikimedia.org/r/178793

@Amire80: This fix should go out today. Can you confirm that the fix works?