Page MenuHomePhabricator

Split 'protect' right in two distinct permissions (instead of using '$wgCascadingRestrictionLevels')
Open, Stalled, LowPublic

Description

It is better that we split 'protect' right rather than using '$wgCascadingRestrictionLevels':

1- 'protect': Change protection levels
2- 'editcascadeprotected': Edit cascade-protected pages (exactly like 'editsemiprotected' and 'editprotected' rights)

Change protection levels and edit cascade-protected pages are two different concepts.


Version: 1.24rc
Severity: enhancement

Details

Reference
bz69607

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 3:33 AM
bzimport set Reference to bz69607.
bzimport added a subscriber: Unknown Object (MLST).
Calak created this task.Aug 15 2014, 2:08 PM

And what makes you feel 'editprotected' would be inappropriate for this purpose? Cascading protections are still protections, not something different level of protection.

Because 'editcascadeprotected' can be temporary.
For example now (August 16) you can not edit "Wikipedia:Selected anniversaries/August 16" on en.wikipedia, but you can edit it on other days.
So 'editprotected' is not like 'editcascadeprotected'; a user with 'editcascadeprotected' right should not be able to edit all protected pages like 'editprotected' right.

If you can edit cascading-protected pages, you can protect arbitrary pages by transcluding them in cascading-protected pages. This makes it equivalent to protect anyway, so there's no reason to split the rights. WONTFIX. (And I think this is also a duplicate of something, though I'm not sure which offhand).

MGChecker reopened this task as Open.Jul 18 2016, 12:36 PM

Just ran across this again in discussion on enwiki: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(policy)#RFC:_Proposal_to_allow_Template_Editors_the_ability_to_indirectly_edit_the_Main_Page

I reject the "WONTFIX" argument that YES, editcascade can have a side affect of allowing included pages to inherit the protection - this could be desirable for some projects. More importantly, it would prevent removal or alteration of protection not needed for editing.

Xaosflux changed the task status from Open to Stalled.Oct 14 2017, 2:36 PM

Chiming in at the invitation of Xaosflux. If I understand the technicalities correctly, this unbundling could address a fairly frequent matter of contention, and improve the ability of some of en.wiki's most dedicated contributors to fix serious and visible issues.

ALSO: I too reject the WONTFIX argument. If unbundled, the ability to edit cascade protected pages would be handed to a few trusted users who do not have the ability to protect pages in the normal way. If they used this user-right to bypass that restriction, it would logically be grounds for immediate removal of said user-right. Any tool is open to abuse; it is up to the community to forestall and address any such abuse.

The idea of the wontfix argument is that it's technically possible to protect any pages by editing cascade protected ones. However, while this might be theoretically true, I think there's some distinction in practice:

  1. If I have an cascade protected main page, in practice I won't use this to protect anything that isn't on the main page – it would be disruptive. It's something else than doing individual protection decision.
  2. You can finally combine protection levels and cascade protection in a useful way (as someone who can protect pages usually also can edit all protected pages.) This way, you could imagine a main page cascade protected to be editable just by a trusted user group (with its own protection level), while most other cascade protected pages stay on sysop level.

This isn't a purely academical topic, but has really valuable papplication in a wide variety of WMF- and Non-WMF-wikis. I really think we should do this.

Note that there's a more concrete discussion of this idea in T101309. Furthermore, there's a (hopefully still) working patch by me implementing this feature on a purely optional basis, meaning that somebody with the protect permission would still be able to edit cascade protected pages. Nothing would change if the new permission isn't explicitly designed to any goup (Currently, it's automatically assigned to sysop by default, but this could be turned of too)