cannon.danielc wrote:

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.

Attached:

ssanbeg wrote:

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;

ayg wrote:

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.

This doesn't seem to make any sense to me.