Svoboda | Graniru | BBC Russia | Golosameriki | Facebook
BBC RussianHomePhabricator
Log In
Maniphest T273317

some users with access are unable to configure pending changes
Closed, ResolvedPublicBUG REPORT

Description

Steps to Reproduce:
Try to configure pending changes, the PC options are greyed out.
When trying via the API, an access denied error is returned as well (see below)

Actual Results:

{ "error": { "code": "stabilize_denied", "info": "Permission denied.", "*": "See https://en.wikipedia.org/w/api.php for API usage. Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes." }, "servedby": "mw1363" }

Expected Results:
The operation will succeed

Related Objects

Event Timeline

Xaosflux renamed this task from administrators are intermitintly unable to set pending changes on enwiki to administrators are intermittently unable to configure pending changes on enwiki.Jan 29 2021, 7:16 PM

In the Finnish Wikipedia a user who is in the reviewer user group with "stablesettings" right reported last night that they lost the ability to change the FlaggedRevs settings in articles. No admin has reported the same problem, but I don't know how many have tried it. The user said that they don't see the option anymore in the drop-down menu at the top of the article.

Xaosflux renamed this task from administrators are intermittently unable to configure pending changes on enwiki to intermittently users with access are unable to configure pending changes.Jan 29 2021, 8:19 PM
Xaosflux renamed this task from intermittently users with access are unable to configure pending changes to some users with access are unable to configure pending changes.

Change 660006 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/core@master] Revert "Remove usages and hard deprecate User::changeable(By)Group"

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

Change 660007 had a related patch set uploaded (by Reedy; owner: Reedy):
[mediawiki/core@wmf/1.36.0-wmf.28] Revert "Remove usages and hard deprecate User::changeable(By)Group"

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

Change 660007 merged by jenkins-bot:
[mediawiki/core@wmf/1.36.0-wmf.28] Revert "Remove usages and hard deprecate User::changeable(By)Group"

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

taavi raised the priority of this task from High to Unbreak Now!.Jan 29 2021, 10:43 PM
Reedy lowered the priority of this task from Unbreak Now! to High.Jan 29 2021, 10:47 PM
Reedy added a project: Platform Engineering.

Change 660006 merged by jenkins-bot:
[mediawiki/core@master] Revert "Remove usages and hard deprecate User::changeable(By)Group"

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

Change 660532 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/core@wmf/1.36.0-wmf.28] Revert "Revert "Remove usages and hard deprecate User::changeable(By)Group""

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

Change 660532 abandoned by Urbanecm:
[mediawiki/core@wmf/1.36.0-wmf.28] Revert "Revert "Remove usages and hard deprecate User::changeable(By)Group""

Reason:

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

Change 660532 restored by Urbanecm:
[mediawiki/core@wmf/1.36.0-wmf.28] Revert "Revert "Remove usages and hard deprecate User::changeable(By)Group""

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

Change 660532 abandoned by Urbanecm:
[mediawiki/core@wmf/1.36.0-wmf.28] Revert "Revert "Remove usages and hard deprecate User::changeable(By)Group""

Reason:

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

Change 660533 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/core@wmf/1.36.0-wmf.28] Revert "Revert "Revert "Remove usages and hard deprecate User::changeable(By)Group"""

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

Change 660533 merged by jenkins-bot:
[mediawiki/core@wmf/1.36.0-wmf.28] Revert "Revert "Revert "Remove usages and hard deprecate User::changeable(By)Group"""

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

Mentioned in SAL (#wikimedia-operations) [2021-02-01T10:39:40Z] <urbanecm@deploy1001> Synchronized php-1.36.0-wmf.28/includes/user//User.php: Fixing T273317 T273296 (duration: 00m 58s)

Mentioned in SAL (#wikimedia-operations) [2021-02-01T10:41:04Z] <urbanecm@deploy1001> sync-file aborted: Fixing T273317 T273296 (duration: 00m 12s)

Mentioned in SAL (#wikimedia-operations) [2021-02-01T10:42:14Z] <urbanecm@deploy1001> Synchronized php-1.36.0-wmf.28/includes/: Fixing T273317 T273296 (duration: 01m 01s)

Pchelolo claimed this task.
Pchelolo added subscribers: Urbanecm, Pchelolo.

Ive created followup tasks T273510 and T273511 that would allow us to fix the issue properly and unrevert it. According to @Urbanecm in T273296#6791634 this is not resolved.

Not sure if same problem, or related problem - from T275017 -
*Edits made by some editors with autoaccept access are not being autoaccepted

(follow-up to T275017#6846089) I just checked with an enwiki admin, and they managed to configure pending changes. Is this still an issue?

The problem wasn't presenting as "no admin" can do this - it was "some admins" can't do this - and it seemed to for some reason be sticky to the ones that couldn't. Did you get confirmation from someone that recently had the failure?

Not sure if same problem, or related problem - from T275017 -
*Edits made by some editors with autoaccept access are not being autoaccepted

Could you fill a new task, as it appears to be a separate issue (at least it has separate symptomps)? Please also include some diffs to (recent) edits that were not autoaccepted, while they should be.

[...]
The problem wasn't presenting as "no admin" can do this - it was "some admins" can't do this - and it seemed to for some reason be sticky to the ones that couldn't. Did you get confirmation from someone that recently had the failure?

No. I added a comment to the VPT post you linked, there doesn't seem to be any reply so far. A handful of admins managed to change PC recently through, see https://en.wikipedia.org/wiki/Special:Log/stable.

OK there seem to be 2 issues here:

  1. Some edits by some users with autoaccept access are not being autoaccepted
  2. Some users (admins) with access to configure pending changes are not able to configure pending changes

This is certainly trickier in that it is not always failing for everyone. When the admins reporting the problem had it occur, other admins were still able to do it.

I am an extended confirmed user editor on wikipedia. On Michael Rosen, which is pending changes protected, my 8 Feb edit https://en.wikipedia.org/w/index.php?title=Michael_Rosen&type=revision&diff=1005571365&oldid=1005008162 was automatically accepted but those of 19 Feb were not e.g. (the first one) https://en.wikipedia.org/w/index.php?title=Michael_Rosen&type=revision&diff=1007735566&oldid=1007730996. The edit history shows the issue more clearly: https://en.wikipedia.org/w/index.php?title=Michael_Rosen&action=history I have not had this problem before.
The issue is the same for all pending changes protection articles which I have subsequently edited e.g.
https://en.wikipedia.org/w/index.php?title=2008_Mumbai_attacks&action=history

I am an extended confirmed user editor on wikipedia. On Michael Rosen, which is pending changes protected, my 8 Feb edit https://en.wikipedia.org/w/index.php?title=Michael_Rosen&type=revision&diff=1005571365&oldid=1005008162 was automatically accepted but those of 19 Feb were not e.g. (the first one) https://en.wikipedia.org/w/index.php?title=Michael_Rosen&type=revision&diff=1007735566&oldid=1007730996. The edit history shows the issue more clearly: https://en.wikipedia.org/w/index.php?title=Michael_Rosen&action=history I have not had this problem before.
The issue is the same for all pending changes protection articles which I have subsequently edited e.g.
https://en.wikipedia.org/w/index.php?title=2008_Mumbai_attacks&action=history

This sounds to be a different case than (partial?) unability to configure pending changes. Can you create another task for that, please?

Change 666587 had a related patch set uploaded (by Daniel Kinzler; owner: Daniel Kinzler):
[mediawiki/extensions/FlaggedRevs@master] Run setup from MediaWikiServices hook.

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

Can someone retest this please? I think that some of the recent changes in wmf.33 might have fixed the problem.

In response to Pchelolo, I just tried to edit [[Bobbi Billard]] and my edit was not automatically accepted.

In response to Pchelolo, I just tried to edit [[Bobbi Billard]] and my edit was not automatically accepted.

Yup it didn't do it when it should. I have now manually accepted it which did work for me.

Courtesy link: https://en.wikipedia.org/w/index.php?title=Bobbi_Billard&action=history

Can someone retest this please? I think that some of the recent changes in wmf.33 might have fixed the problem.

Which changes do you have in mind?

I can see how https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/666587 could fix this, but that hasn't been merged yet.

T273510 and T273511 might have moved PermissionManager instantiation late enough to avoid this problem and get back to status quo - very unstable and can break at any moment, but working.

Change 666587 merged by jenkins-bot:

[mediawiki/extensions/FlaggedRevs@master] Run setup from MediaWikiServices hook.

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

Presumably this was fixed by the changes indicated in T273317#6886636? I can't reproduce it and I'm sure if the pending protection interface were broken completely, as the task description states, we would have heard a lot more about it in the three months since opening the task.