There are multiple current instances where users
- Cannot proceed with an action, because they are not perceived as having rights that they are indeed assigned
- Can proceed with an action, despite not having the rights needed
There are multiple current instances where users
|Open||None||T234743 User rights validation is sometimes malfunctioning (with FlaggedRevs only?)|
|Open||None||T233561 Pending changes: autoreview randomly fails|
|Open||None||T234744 Enwikibooks: Rollback intermittently limited to administrators|
|Resolved||Huji||T249643 Restore the "reviewer" group for fawiki|
I believe that this is indeed the case, and is found more generally than in just flagged revs:
I created this parent task to better track the general investigation into why this is. My instinct would be that https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/refs/heads/master/wmf-config/InitialiseSettings.php isn't being property parsed, and thus that rollback remains with admins only be default, etc.
But… it didn't. The caching code (for /tmp on the appservers) has been moved around and changed format away from serialised PHP, but we've not added any new caching. It's definitely possible that the config output is wrong, but it seems very odd that it'd be unstable and flake between different outcomes (the entire point of the work is to reduce the amount of live code and so chances for inconsistencies).
Failure to load flaggedrevs.php seems very alarming, yes.
A similar issue happened to me today while deploying this change. After I synced this change, about half the appservers (correctly) believed that $wgGEHomepageSuggestedEditsRequiresOptIn was false on cswiki, and the other half believed it was true. I checked one appserver that was returning the wrong responses, and I found that its copy of InitialiseSettings.php was correct, but running var_dump($wgGEHomepageSuggestedEditsRequiresOptIn) from eval.php returned the wrong result. I re-ran scap sync-file wmf-config/InitialiseSettings.php and that fixed it. Unfortunately I did that pretty early on, before looking at the JSON files in the cache directory in /tmp, so I wasn't able to investigate further.
Based on Manual:$wgExtensionFunctions: This variable is an array that stores functions to be called after most of MediaWiki initialization is complete. Note however that at this point the RequestContext is not yet fully set up, so attempting to use it (or equivalent globals such as $wgUser or $wgTitle) is liable to fail in odd ways. If you need to use the RequestContext, consider the BeforeInitialize and ApiBeforeMain hooks instead.
However, configuration in file wmf-config/flaggedrevs.php was wrapped to function which is called from wgExtensionFunctions hook in commit 606310e502abc426a9f0b1a6cffd31aeb3d1e1c5 at Jun 24 and if $wgDBname is randomly not set up then FR config running with defaults in those cases. This could be reason for T237191 too. (ping @Reedy}
Probably. Or making these things worse.
The problem presumably happens when things load with the default config, and don't get overridden to turn off the rights
As has been said before, extensions should have sane defaults. But how do you set sane defaults for an extension as complex as FlaggedRevs, which has N different modes that it can be configured
But if we look at other bugs under this one... Rights being assigned by the default FR config, and then being removed at an arbitary time during wmf-config running... And we know complex array configs don't work well with extension registration
Ideally we strip out, and/or turn off most of the config out of FlaggedRev's extension.json (and document?).. And then set the config in flaggedrevs.php... And then strip out most of that into IS anyway? Because most of it is the same as IS...
$wgDBname is definitely set before flaggedrevs.php is even loaded
The fact Roan has seen this with non FR is slightly concerning, but maybe slightly a good thing - it's not "just" FR... If it is the problems in FR and wmf-config for FR being exacerbated by the config rewrite?
I am getting a permission error response if I try to mark pages for translation on mobile (mobile site, to be precise).
I get an permission error which says
The action you have requested is limited to users in the group: Translation administrators. even though I am a translation administrator on Mediawiki.org
I was able to reproduced this bug on both Beta Commons and Mediawiki.org where I have translation administrator rights.
This can be still explained with a configuration race condition. At some time times, FlaggedRevs site-specific configurations arent loaded so it is running with defaults. (ie. there is default user groups like "editors" etc)
Problem likely started when FR config was moved to an extension function in summer 2019. And also as catrope noticed it maybe not just to be Flagged revs configuration problem. So it is just more visible with a current configuration where the config is inside extension function.
Okay, maybe. But, from what I can see there is no timeline mentioned anywhere. I'll take it that means there is no timeline on this and/or no one is working on fixing this atm?
Edit: Nemo is a member of the project and you are added as a default subscriber for phab tasks, I don't know who else I can ask.
It's not, I just mean that it's ridiculous to have OS and CU and not be able to do pending changes. I've been given the pending changes rights since posting here, it will be interesting to see if that makes a difference. On the other hand, I was able to do pc yesterday.
@DougWeller, I'm a bit lost in your comment. On enwiki at least, accepting pending changes is part of the (review) permission, this is included in the "administrators" (sysop) group and the "pending changes reviewers" (reviewer) group. I can't see what this has to do in the least with oversight and even further from what it would have to do with checkuser. It is very certainly possible to be a member of both the CU and OS group and not have access to "review" just as you wouldn't have access to many other functions.
I believe what Doug Weller is trying to say is that enwiki oversighters are all admins and admins on enwiki hold the "review" permission. And yet sometimes there is a permission error for oversighters. Which is a bug as it shouldn't happen to users who have the "review" permission via their usergroup.
OK, so I think it is confirmed that this has nothing at all to do with OS, which you absolutely can be a member of without being a member of sysop and has no nested review permissions; so this is still the original problem, that sometimes people with review permissions (such as reviwers and sysops on enwiki) are intermittently failing.
This sometimes happens to me too. Either the review interface doesn't appear, or I get an error message about a lack of permission if it appears and I use it. This time, at "Tyler1" on enwiki. A pending changes reviewer has kindly reviewed the sysop edits, but shouldn't have had to. I wonder if the bug can be circumvented by adding a sysop to the pending changes reviewer group.
I, and at least two other folks on fawiki, are experiencing this bug too. On fawiki, we don't have the "circumventing" workaround explained above. Is there anyway I/we could help with resolving this?
See https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/master/wmf-config/flaggedrevs.php line 252 for the enwiki config, you also have to readd reviewer in fawiki.
Similar group already exists in fawiki and it's the same 'patroller' group that you mentioned in the other ticket. Enwiki just decided to name the group 'pendingchanges reviewer' maybe because patroller is used for something else there. The relevant internal rights are: review and autoreview which allow reviewing others and automatic self-reviewing. Both groups have them common besides other ancillary ones not related to FR extension. The settings are defined in /wmf-config/flaggedrevs.php configuration file
It's not the same, @Ammarpad . reviewer is the default group used by FlaggedRevs, fawiki unsets it and instead assigns reviewer rights to patroller. If you're not using the default reviewer group, the workaround does not work, even if you give identical rights to another group, and no way to currently explain this behaviour.
I am talking about the internal review and autoreview rights that the groups share in common. I did not mention 'reviewer' group in my comment. The rights I mentioned are what the default group also have (in addition to others), so unless flaggedrevs.php is not being loaded or loaded very late they should behave the same.