Last modified: 2011-03-13 18:06:01 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 T14246, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 12246 - Make rollback a user preference for non-admins
Make rollback a user preference for non-admins
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
User preferences (Other open bugs)
unspecified
All All
: Lowest enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
http://en.wikipedia.org/wiki/Wikipedi...
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-08 19:23 UTC by MZMcBride
Modified: 2011-03-13 18:06 UTC (History)
3 users (show)

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


Attachments
Something to do the trick (6.37 KB, patch)
2007-12-18 00:22 UTC, Daniel Cannon (AmiDaniel)
Details

Description MZMcBride 2007-12-08 19:23:24 UTC
With the recent uproar over rollback, a compromise solution has been discussed on en.wiki. It would allow a user preference for rollback to be an option for non-admins, which solves a couple of key issues:

  1. It puts the onus on the user. A user can't simply claim that they suddenly saw a new rollback link and didn't know what it was. Thus, sysops won't feel guilty about blocks made for rollback mis-use, which was a concern.
  2. It can be configured to only work with a certain number of edits, something that can be easily checked in the preferences section, if desired.
  3. A link could be provided (via a MediaWiki message) next to the checkbox so that users can fully understand what rollback does and what its intended use is, etc.
  4. This will allow dedicated vandal fighters access to a helpful tool while stopping a flood of rollback mis-use that would undoubtedly happen if the option were enabled and staring new users in the face.
Comment 1 Daniel Cannon (AmiDaniel) 2007-12-18 00:22:28 UTC
Created attachment 4446 [details]
Something to do the trick

I've attached a patch that will do what's requested, but I'm a little hesitant about committing it. 

My major question with this is how the default behavior of the preference should be handled. In the attached patch, a user in the group "sysop" will have the preference enabled by default, and users in any other group will have it disabled. The preference is only available to those with the rollback right--that is, users without the rollback right will never save a value for the preference, so if only sysops have the rollback right, then the promotion of a user to a sysop will cause him to gain the rollback right and to have rollback enabled until he chooses to disable it. However, if rollback is enabled for users, as is the proposal on enwiki, then promotion to sysop will not cause the preference to magically become enabled--all current sysops will not suddenly lose their rollback buttons, however.

Anyway, this seems a little dirty to me, and I'm not sure it's the best way of implementing the feature. I do, however, think that the feature should be implemented somehow and would make for an acceptable compromise.
Comment 2 Steve Sanbeg 2007-12-18 17:40:20 UTC
My thought is that it would be nice to make something more generic; then allow something like

$wgGroupPermissions['sysop']['rollback']        = true;
$wgGroupPermissions['autoconfirmed']['rollback']        = 'if-enabled';
$wgGroupPermissions['user']['rollback']        = true;

which could work with arbitrary groups/rights.

At a minimum, it could probably be done simply and with some flexibility by adding an additional right for each right you want to toggle; i.e.

$wgGroupPermissions['autoconfirmed']['rollback-preference']        = true;

Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-18 17:49:45 UTC
Special-casing sysops anywhere in the code is definitely a bad idea -- I would suggest that the updater code just set the preference default as a one-time thing, and subsequent sysops can enable it manually like everyone else.  I don't think changing $wgGroupPermissions to have non-Boolean values would be a good idea either.

Using usergroups strikes me as possibly a better way of doing this than preferences.  This could allow public viewing of who's enabled it, public logging of same, and manual addition/removal by privileged users under appropriate circumstances.  It would be nice if we had some way of blocking rollback, too, through the blocking mechanism, to deal with abuse.

The concept is generally interesting, and one I don't think is a bad one to proceed with, but the execution needs more work, IMO.

Comment 4 Brion Vibber 2007-12-18 20:05:48 UTC
This doesn't seem to make any sense to me.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links