Page MenuHomePhabricator

Don't offer meaningless protection levels (e.g., move=autoconfirmed with moves restricted to autoconfirmed)
Open, LowPublicFeature


When decreasing the protection level, a page is sometimes saved with "move=autoconfirmed" only, which has no effect since move is restricted to autoconfirmed users (on Wikipedia). It's an inconvenience for maintenance activities and it confuses bots. So when a page is saved with "move=autoconfirmed" only, could it be read as an unprotection by mediawiki?

Version: unspecified
Severity: enhancement
See Also:



Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:30 PM
bzimport set Reference to bz16791.
bzimport added a subscriber: Unknown Object (MLST).

matthew.britton wrote:

Better still, change the interface so that move=autoconfirmed isn't even an option (move protection really only needs to be a checkbox, 'sysop' or nothing, on wikis without additional levels).

ayg wrote:

This might require some fairly tricky logic to pull off in the general case. I really don't think we want to write specific hacks for particular permissions setups, although admittedly the protection system is full of those as-is . . .

I thought about this somewhat after it was brought up on enwiki's village pump. The main issue is that it requires the software to "know" the hierarchy of protection levels. Protection levels are technically based on rights, not groups. The 'sysop' in $wgRestrictionLevels is treated as 'protect'. I guess what you'd have to do is look up all the groups that have a given permission (such as 'move') and then you'd need some logic to determine if the requested configuration (move=autoconfirmed) is equivalent to or less restrictive than the default. Since restrictions can have separate expires, this would also need to be checked whenever a permission expires.

The other option is redoing the protection config variables. Instead of having separate $wgRestrictionTypes and $wgRestrictionLevels, have a combined $wgRestrictions or something with a format like
$wgRestrictions = array('edit'=>array('autoconfirmed', 'sysop'), 'move'=>array('sysop'));
though the protection form and any other uses of the protection types/levels variables would have to support both config options for backwards compatibility, which could potentially be ugly.

ayg wrote:

Yeah, that's the basic problem: how do you figure out if one right implies another? What happens, for that matter, if a sysadmin changes $wgGroupPermissions -- suddenly all protections of a given type should vanish?

It might make more sense to allow *manual* specification of a certain type of protection that should be prohibited. So you could do something like

$wgProhibitedRestrictions['move'][] = 'autoconfirmed';

to achieve the desired effect, say. You might need to fiddle with the UI considerably to make this work nicely, though.

It would probably be better to change the semantics of $wgRestrictionLevels to allow separate arrays for each action, as in:

$wgRestrictionLevels = array(

'edit' => array( '', 'autoconfirmed', 'protect' ),
'move' => array( '', 'protect' ),


(I _think_ PHP arrays are sufficiently flexible that we could support both the current and the proposed syntax, or even a mixture of the two, with the same variable. The alternative, of course, would be to introduce a new config variable and deprecate $wgRestrictionLevels.)

ayg wrote:

Yeah, that would be a better syntax.

"move" might be added or removed from any group in the future, and such a change shouldn't have to require page level protections be adjusted again.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:01 AM
Aklapper removed a subscriber: wikibugs-l-list.

It would probably be better to leave the semantics of $wgRestrictionLevels as is, but allow a new setting, $wgActionRestrictionLevels, allowing to set overrides for actions defined in $wgRestrictionTypes. For configuration used on enwiki, it might be as follows:

$wgRestrictionLevels = [ '', 'autoconfirmed', 'extendedconfirmed', 'templateeditor', 'sysop' ];
$wgActionRestrictionLevels['move'] = [ '', 'extendedconfirmed', 'templateeditor', 'sysop' ];
$wgActionRestrictionLevels['upload'] = [ '', 'extendedconfirmed', 'templateeditor', 'sysop' ];

It would be nice to let Page movers move article that are move protected. If it were technically possible and the extendedmover level were only available for move protection, it might be as follows:

$wgRestrictionLevels = [ '', 'autoconfirmed', 'extendedconfirmed', 'extendedmover', 'templateeditor', 'sysop' ];
$wgActionRestrictionLevels['edit'] = [ '', 'autoconfirmed', 'extendedconfirmed', 'templateeditor', 'sysop' ];
$wgActionRestrictionLevels['move'] = [ '', 'extendedconfirmed', 'extendedmover', 'templateeditor', 'sysop' ];
$wgActionRestrictionLevels['upload'] = [ '', 'extendedconfirmed', 'templateeditor', 'sysop' ];