Page MenuHomePhabricator

Split protect permission into two new rights
Closed, DuplicatePublic


The definition of protect: "Change protection levels and edit cascade-protected pages (protect)" why not split edit cascade-protected pages and protect pages in two permissions?
In case of two rights required: Protect a page with cascade-protection and sysop protection, and a non sysop user with the right to edit cascade-protected pages is not able to edit this page. I already tested this with superprotect, so cascading superprotect.
The result: Sysops can't edit, and all pages which are protected by this cascade-protection are on the superprotect level, so sysops can not edit.
Greetings, Luke081515

Event Timeline

Luke081515 raised the priority of this task from to Needs Triage.
Luke081515 updated the task description. (Show Details)
Luke081515 added a subscriber: Luke081515.
Luke081515 triaged this task as Medium priority.Jun 3 2015, 9:21 PM
Aklapper raised the priority of this task from Medium to Needs Triage.Jun 4 2015, 12:32 PM

@Luke081515: Do you plan to work on a patch to fix this, or why did you set normal priority on this task?

Sorry, I clicked on the wrong field

I am not sure, but I sounds that for this use case the right "editprotected" (or "editeditorprotected") already exists.

Editing cascade protected pages is protected by user rights to normally protection, because by adding a template the user, who can edit the cascade protected page, is able to protect other pages indirectly, which is not allow.

An example:
Page A gets a cascade sysop protection
Page B is included in Page A
User with editprotected and without protect is now able to edit Page B, but not Page A
User with protect and without editprotected is able to edit Page A and Page B

In this case it is useful, that a user with editprotected und not the protect right can also edit Page A. And there is another case, were this is needed: In my testwiki, I allow sysops, to protect pages with autoconfirmed, and casacedprotection. Now a user who is able to edit normally protected autoconfirmed pages, is not able to edit the pages A&B. To give him now the possibility to edit A or B, he needs the right protect. And this is a big reason, normally normal users should not be able to protect pages.

Aklapper triaged this task as Lowest priority.Jun 15 2015, 8:48 AM

Change 286688 had a related patch set uploaded (by MGChecker):
Split editcascadeprotected permission from protect permission

MGChecker renamed this task from Split the right protect in two new rights to Split protect permission into two new rights.May 4 2016, 8:45 PM
MGChecker raised the priority of this task from Lowest to Medium.

Change 286688 merged by jenkins-bot:
Split editcascadeprotected permission from protect permission

@Legoktm: It would be nice if you give a more detailed summary why you reverted my patch. Please note my argumentation in the commit message and in a comment to your revert.

This bug conceptually doesn't make sense. Anyone who has the ability to edit cascade-protected pages has the effective ability to protect pages by including them in the cascade protected page. So it makes sense to only give it to people who only have the actual protect permission.

The use case provided in T101309#1341995, just stated it was for a testwiki. I don't think we should be adding questionable features for contrived test cases.

@Legoktm: At Gerrit, I clearly stated a non-fictional use case two times, also I summarized why it isn't the same situation to be able to do an individual protection decision for single pages and to be able to manipulate page protection in a indirect way. On many wikis, cascade protection is exclusive to the main page, and they don't want anyone except sysops to be able to protect pages. In such a situation I think it would be a reasonable decision to let other trusted users who aren't sysops edit the main page, for example to fix errors in rotating contents. Those users wouldn't abuse the cascade protection to protect individual pages outside of the mainpage – after all it would break the main page in many cases.

Furthermore, I don't see any reason to deny this functionality this use case. For someone who because of the problems you have stated don't want to give users without protect permission the permission to protect cascade protected pages, nothing changes for them, this feature is completely optional. And I don't believe a bug doesn't make sense if some wikis use hacks arund urls action parameters for years because of missing possibilities in mediawiki core that could be included with no pain for other people.