https://bugzilla.wikimedia.org/show_bug.cgi?id=47617
--- Comment #6 from Bartosz Dziewoński <[email protected]> --- > @@ 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.) -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
