Le 22.6.2008 18:44, « Voice of All » <jschulz_4587(a)msn.com> a écrit :
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'.
See Werdna's message.
Also, people with editprotected can edit a protected page, provided cascade
is not used.
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?
Maybe with a hook? :)
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?
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