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