Le 21.6.2008 5:17, « aaron@svn.wikimedia.org » aaron@svn.wikimedia.org a écrit :
Revision: 36519 Author: aaron Date: 2008-06-21 03:17:35 +0000 (Sat, 21 Jun 2008)
Log Message:
- Revert r36478; I don't see the point in this cryptic code
- Restore r36273 as explain on mailing list
Modified Paths:
trunk/phase3/includes/Article.php trunk/phase3/includes/ProtectionForm.php trunk/phase3/includes/Title.php
The problem is that if you want to introduce a new protection level (e.g. userrights to allow only bureaucrats to edit that page) and that all groups that have this right also have the "protect" right (wich is correct if you give bureaucrats the protect right), then you should be able to use cascade protection for this level. Note that the protection level should be an right, and not a group (execpt for "sysop" kept for b/c) and it's why there's an loop on $wgGroupPermission (see also Simetrical's message on brion's revert of r36273). This code only allows cascade with the protect level, for a normal install, it works as expected, but for custom levels (as I mentionned before), it doesn't work as only can have cascade on one level so I really don't see the point to have "protect" hardcoded in that check.
--ialex
Yes, my original change was to account for it as a right.
My problems with this change is: 1) Some of the code should perhaps be moved to another function rather than embedded as it was. Things just looked reeeally funky ;) 2) If I, say, set the page to 'oversight' only, and give Oversights 'protect', that's nice, but last time I checked, anyone else with the protect right, like Sysops could just unprotect and edit it. Also, how would that work with 'editprotected'? This is a problem with any permission "above" 'protect'. 3) The nature of the code. I don't like it iterating through the permissions array. What about extensions/live hacks that alter rights and such? 4) Even for levels "lower" that 'protect', if all groups that have it must also have 'protect', why not just grant those groups a new right, and use that?
That said, I'm not sure how useful this is, at least as it is.
Alexandre Emsenhuber wrote:
Le 21.6.2008 5:17, « aaron@svn.wikimedia.org » aaron@svn.wikimedia.org a écrit :
Revision: 36519 Author: aaron Date: 2008-06-21 03:17:35 +0000 (Sat, 21 Jun 2008)
Log Message:
- Revert r36478; I don't see the point in this cryptic code
- Restore r36273 as explain on mailing list
Modified Paths:
trunk/phase3/includes/Article.php trunk/phase3/includes/ProtectionForm.php trunk/phase3/includes/Title.phpThe problem is that if you want to introduce a new protection level (e.g. userrights to allow only bureaucrats to edit that page) and that all groups that have this right also have the "protect" right (wich is correct if you give bureaucrats the protect right), then you should be able to use cascade protection for this level. Note that the protection level should be an right, and not a group (execpt for "sysop" kept for b/c) and it's why there's an loop on $wgGroupPermission (see also Simetrical's message on brion's revert of r36273). This code only allows cascade with the protect level, for a normal install, it works as expected, but for custom levels (as I mentionned before), it doesn't work as only can have cascade on one level so I really don't see the point to have "protect" hardcoded in that check.
--ialex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Jun 23, 2008 at 2:44 AM, Voice of All jschulz_4587@msn.com wrote:
- If I, say, set the page to 'oversight' only, and give Oversights
'protect', that's nice, but last time I checked, anyone else with the protect right, like Sysops could just unprotect and edit it. Also, how would that work with 'editprotected'? This is a problem with any permission "above" 'protect'.
This is not possible. You need to be able to edit a page to change its protection level.
Le 22.6.2008 18:44, « Voice of All » jschulz_4587@msn.com a écrit :
Yes, my original change was to account for it as a right.
My problems with this change is:
- Some of the code should perhaps be moved to another function rather
than embedded as it was. Things just looked reeeally funky ;)
- If I, say, set the page to 'oversight' only, and give Oversights
'protect', that's nice, but last time I checked, anyone else with the protect right, like Sysops could just unprotect and edit it. Also, how would that work with 'editprotected'? This is a problem with any permission "above" 'protect'. See Werdna's message. Also, people with editprotected can edit a protected page, provided cascade is not used.
- The nature of the code. I don't like it iterating through the
permissions array. What about extensions/live hacks that alter rights and such? Maybe with a hook? :)
- Even for levels "lower" that 'protect', if all groups that have it
must also have 'protect', why not just grant those groups a new right, and use that? IMO, cascade is not meant to be used for levels lower that 'protect'.
That said, I'm not sure how useful this is, at least as it is.
There was an user yesterday on IRC complaining that he can't use anymore cascade protection on his custom levels.
Checks to allow cascade protection can be moved to something like Article::getRestrictionLevelsWithCasacade() that call a hook at its end.
--ialex
wikitech-l@lists.wikimedia.org