Last modified: 2014-06-30 21:38:45 UTC
It would be good to have an option to disable cascading protection in a specific namespace in certain cases. For example: If it was wanted to create a new "special group only namespace", then cascading protection on pages in that namespace would be fruitless or counter-productive. The ability to add something like: $wgAvailableRights[] = 'editmyarea'; $wgGroupPermissions['*']['editmyarea'] = false; $wgGroupPermissions['myarea_editor']['editmyarea'] = true; $wgGroupPermissions['sysop']['editmyarea'] = true; function myareaAddNamespaces( &$list ) { $list[NS_MYAREA] = 'MyArea'; $list[NS_MYAREA_TALK] = 'MyArea_talk'; return true; } $wgNamespaceProtection[NS_MYAREA] = array( 'editmyarea' ); $wgNamespaceCascade[NS_MYAREA] = false; Would allow the extension to create a new userright that would be given to a new usergroup and sysop for a new namespace that can be inclusively edited by any editor with the new right or sysops and ignore cascading protection. I could see this used for extensions like [[mw:Extension:Widgets]] or [[mw:Extension:Scribunto]] and likely others.
This is really vague. Do you mean that if a page in another namespace is cascading-protected, and transcludes one in a cascading-disabled namespace, the page in the cascading-disabled namespace won't be protected? That doesn't make a whole lot of sense to me.
Doesn't that defeat the purpose of cascading protection, if some items included in the cascade-protected page aren't protected by the cascading protection?
Yes, the transcluded page from the new namespace would not be cascade protected. They wouldn't need to be because only sysops and the select group allowed to edit in that namespace could edit there. In the Widgets example, it would allow widget editors to edit any Widget, regardless of where it was transcluded. This allows for editors that can edit any widget, but don't have to be sysops that can delete, protect, avoid rate limits and other things in sysop package but aren't needed for editing widgets.
This would allow template editors to edit templates and modules that happen to be cascade protected (because they are transcluded on a cascade protected page). It wouldn't prevent templates or modules from still being fully protected, but would reduce collateral damage from cascading protection.
The whole point of cascading protection is its "collateral damage". Setting this on Template, Module, or any other namespace that isn't restricted via $wgNamespaceProtection would be a disaster.
(In reply to Jackmcbarn from comment #5) > The whole point of cascading protection is its "collateral damage". Setting > this on Template, Module, or any other namespace that isn't restricted via > $wgNamespaceProtection would be a disaster. The whole point of the Template editor group is to allow a handful of select editors to not be affected by collateral damage protections.
If you want that, you do it by letting that group edit cascade-protected pages, not by turning off cascading protection for everyone (which this would do).
(In reply to Jackmcbarn from comment #7) > If you want that, you do it by letting that group edit cascade-protected > pages, not by turning off cascading protection for everyone (which this > would do). You can't let the group just edit cascade protected pages without letting them edit all protected pages including fully protected. This would not turn off cascade protection for everyone, just for those users in that group for those namespaces.
Nothing much has changed here. If you don't want things cascade-protected, then don't use cascading protection. There's little point in repeating yourself. I see no point in trying to make some users being able to ignore cascading protection, that's the mistake that was made with the old "editprotected" right before I fixed it.
