Last modified: 2014-02-02 18:20:02 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T40989, the corresponding Phabricator task for complete and up-to-date bug report information.
First Last Prev Next    This bug is not in your last search results.
Bug 38989 - Special:UserRights does not handle user right change conflicts
Special:UserRights does not handle user right change conflicts
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.21.x
All All
: Low enhancement (vote)
: ---
Assigned To: Alex Monk
:
: 47302 60738 (view as bug list)
Depends on:
Blocks: SWMT 60738
  Show dependency tree / graph
 
Reported: 2012-08-02 22:21 UTC by James Forrester
Modified: 2014-02-02 18:20 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description James Forrester 2012-08-02 22:21:42 UTC 
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. :-)
Comment 1 Chad H. 2012-08-02 22:23:23 UTC 
Could've sworn this was a duplicate (I've complained about it before), but I can't seem to find it.
Comment 2 Alex Monk 2013-04-17 16:07:50 UTC 
*** Bug 47302 has been marked as a duplicate of this bug. ***
Comment 3 Alex Monk 2013-04-17 16:41:16 UTC 
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?
Comment 4 billinghurst 2013-04-21 22:44:30 UTC 
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.
Comment 5 Gerrit Notification Bot 2013-04-21 22:50:11 UTC 
Related URL: https://gerrit.wikimedia.org/r/60229 (Gerrit Change I75996605885c1b5300da8ad7b03c48560450a0c4)
Comment 6 Alex Monk 2013-05-01 22:24:47 UTC 
I didn't get around to finding ways to (where possible) automatically resolve such conflicts, but this has now been merged anyway.
Comment 7 Alex Monk 2014-02-02 17:04:59 UTC 
*** Bug 60738 has been marked as a duplicate of this bug. ***
Comment 8 Alex Monk 2014-02-02 17:05:30 UTC 
Seen again as bug 60738 (now a dupe of this), reopening
Comment 9 Alex Monk 2014-02-02 18:07:32 UTC 
Which I can't reproduce, but we're assuming it's due to the cache
Comment 10 Gerrit Notification Bot 2014-02-02 18:08:46 UTC 
Change 110869 had a related patch set uploaded by Alex Monk:
Clear user cache before checking userrights conflict

https://gerrit.wikimedia.org/r/110869
Comment 11 Gerrit Notification Bot 2014-02-02 18:17:56 UTC 
Change 110869 merged by jenkins-bot:
Clear user cache before checking userrights conflict

https://gerrit.wikimedia.org/r/110869
Comment 12 Marius Hoch 2014-02-02 18:20:02 UTC 
As the given patch will reload the user groups from master, it should solve the issues.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.

Navigation
Links