Page MenuHomePhabricator

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


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



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).

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).

Just ran across this again in discussion on enwiki:

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'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)

BEANS-X2 rescinded a token.
BEANS-X2 rescinded a token.
Aklapper changed the task status from Stalled to Open.Nov 3 2020, 12:12 PM

The previous comments don't explain who or what (task?) exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status, as tasks should not be stalled (and then potentially forgotten) for years for unclear reasons.

Removing task assignee due to inactivity, as this open task has been assigned for more than two years (see emails sent to assignee on May26 and Jun17, and T270544). Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be very welcome!

(See for tips how to best manage your individual work in Phabricator.)