Last modified: 2013-05-16 23:38:26 UTC
It should be possible to use cascading protection with non-"sysop" protection level. Right now there's a hard-coded check in WikiPage that prevents that, as (quoting a comment above it) "[o]therwise, people who cannot normally protect can "protect" pages via transclusion". While this is a good point, it is really a policy issue rather than code one in some cases. And if this is a concern, we could have a global named, say, $wgCascadingProtectionLevels that would default to array('protect', 'sysop'). For example, I think that it really should be possible for the 'editor' protection level that's currently enabled on pl.wiki (bug 46990) (there's a similar one on pt.wiki, see bug 39652). This is a FlaggedRevs-related permission (able to mark pages as "checked") automatically granted to semi-trusted users. The practical use case: we want to lower the protection level of the main page of the Polish Wikipedia to 'editor' while keeping the cascading behavior. Protecting all of the subpages manually is unfeasible, as these are automatically cycled every day, and should be fully editable while not displayed on the main page.
Related URL: https://gerrit.wikimedia.org/r/60695 (Gerrit Change I5f8bcc899b46d466161894606cd27bf3b8624bd0)
$wgCascadingRestrictionLevels it is. I5f8bcc89.
Merged.
Quoted from commit message: > This is necessary, because if any protection could be > cascading, users could who cannot normally protect pages could > "protect" them by transcluding them on protected pages they are > allowed to edit. Please elaborate on this, especially with regards to the following part of the change: @@ function buildCleanupScript() { - global $wgRestrictionLevels, $wgOut; + global $wgRestrictionLevels, $wgCascadingRestrictionLevels, $wgOut; - - $cascadeableLevels = array(); - foreach ( $wgRestrictionLevels as $key ) { - if ( User::groupHasPermission( $key, 'protect' ) - || $key == 'protect' - ) { - $cascadeableLevels[] = $key; - } - } + + $cascadeableLevels = $wgCascadingRestrictionLevels; It now no longer verifies that the values in cascadeable levels are names of user groups that have the "protect" right. Doesn't that cause a situation exactly like the one you appear to be trying to prevent? Also, from looking at the code, contrary to the commit message it is not hardcoded to 'sysop'. On the contrary, it is dynamically constructed based on wgRestrictionLevels and filtered to only include groups that have the 'protect' right. If I'm reading the use case explained in this bug and in the commit message correctly, it seems that this is already possible without this change. Re-opening with 1.22 milestone to prevent forgetting about this before release. Feel free to re-close.
btw, I see now that WikiPage::doUpdateRestrictions did hardcode the values during an edit attempt. However ProtectionForm did not.
> @@ function buildCleanupScript() { > ... > + $cascadeableLevels = $wgCascadingRestrictionLevels; This is only used to build the client-side list of protection levels which can be cascading; skins/common/protect.js uses it to disable/enable the checkbox when appropriate. (In reply to comment #4) > Quoted from commit message: > > This is necessary, because if any protection could be > > cascading, users could who cannot normally protect pages could > > "protect" them by transcluding them on protected pages they are > > allowed to edit. > > Please elaborate on this Let's assume the default settings, with the minor change that 'autoconfirmed' protection can be cascading. You protect [[A]] as autoconfirmed, cascading. An autoconfirmed user transcludes {{:B}} on [[A]]; now [[B]] is protected as well, despite the user not having the rights to protect it, and non-autoconfirmed users can't edit it anymore nor undo the protection. I think that this can be handled on the policy level instead of on the application level, at least for some semi-trusted groups. That's what this change accomplishes. > If I'm reading the use case explained in this bug and in the commit > message correctly, it seems that this is already possible without this > change. No. The point is to be able to enable cascading protection for some cases *in spite of* this flaw I explained above, Use case: fully protected main page with recursively semi-protected embedded parts. (There is currently no interface for this, but you can get around it using some clevel transclusion and cascading protection hacks. The schema apparently supports such dual protection, though.)
(Re-resolving if everything's clear now.)
