Page MenuHomePhabricator

Special:UserRights does not handle user right change conflicts
Closed, ResolvedPublic


If two bureaucrats both use Special:UserRights to adjust an accounts' flags, their changes do not interleave, but just over-write.

For example, if User:Foo is currently +rollbacker, and two bureaucrats each at the same time try to adjust their rights, bureaucrat A by setting Foo +sysop and bureaucrat B setting Foo +bot, User:Foo should now be +rollbacker +sysop +bot, but instead with either be +rollbacker +sysop or +rollbacker +bot depending on whether A or B hit the database first.

This is akin to edit-conflicts. And yes, a very minor enhancement. :-)

Version: 1.21.x
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:53 AM
bzimport set Reference to bz38989.

Could've sworn this was a duplicate (I've complained about it before), but I can't seem to find it.

  • Bug 47302 has been marked as a duplicate of this bug. ***

We can't rely on log times because user rights logs are not necessarily stored on the current wiki. (Interwiki user rights changes store the log entry on the wiki which the action was made, not the target wiki.)

A fairly simple solution to this is to compare the time that the form was generated against the target's user_touched. But that field could also be updated by other things the user might do. Does that sound acceptable?

Specifically to add that this issue (naturally also) occurs when stewards apply rights using the extended terminology from meta to a remote wiki, and a local rights holder applies rights on a local wiki (the remote wiki) coincidentally.

Related URL: (Gerrit Change I75996605885c1b5300da8ad7b03c48560450a0c4)

I didn't get around to finding ways to (where possible) automatically resolve such conflicts, but this has now been merged anyway.

  • Bug 60738 has been marked as a duplicate of this bug. ***

Seen again as bug 60738 (now a dupe of this), reopening

Which I can't reproduce, but we're assuming it's due to the cache

Change 110869 had a related patch set uploaded by Alex Monk:
Clear user cache before checking userrights conflict

Change 110869 merged by jenkins-bot:
Clear user cache before checking userrights conflict

As the given patch will reload the user groups from master, it should solve the issues.