[pmwiki-users] Hierarchical permissions

The Editor editor at fast.st
Wed Jan 31 06:05:08 CST 2007


On 1/30/07, The Editor <editor at fast.st> wrote:
> Wow, maybe this will be easy after all...  By jove I think I've solved it...
>
> I'll try the
> solution suggested above later, when I'm a bit less tired, and see if
> it doesn't in fact work.  If so--I should be finished with Hg!
>
> Cheers,
> Dan


Well, it seems to work as expected.  Later I'll update the test site
and release the recipe.  Two points however.

1) Actually, with the Hg permissions, it may not work *exactly* as
some might expect.  For example if you are on
Kingdom-Animal-Canine.Dog, and you have a groupattributes edit setting
at Kingdom-Animal, it will require that password to edit your current
page.  But if you have a different view password at
Kingdom-Animal-Canine for example--that group attributes page will be
used and it won't look Kingdom-Animal for anything.  Likewise, if you
have an attr password at Kingdom, Kingdom-Animal won't incorporate
that.  Or to put it differently, you cannot set an admin password in
one group, a edit password in a child level, and a read password in a
grandchild level.  If you did, you'd only get the grandchild
attributes.

So basically you have to think about repeating any settings at lower
levels if you want them to carry on down the hierarchy. Hg uses the
first group attributes page it finds and ignores any other ones up the
chain.  Easy enough to live with I suppose.

Of course, default passwords set in config files seems to work as
normal, and attributes set for specific pages should not be affected
either.  I have not thoroughly tested this, just ran a couple quick
tests--successful.

2). In the process, the thought crossed my mind we do have two options
for dealing with hierarchical config files.  Currently, if you are at
Kingdom-Animal-Canine, it looks for Kingdom-Animal-Canine.php first,
then Kingdom-Animal.php, and then Kingdom.php (and then default.php).
As soon as it finds one, it uses it and stops its search.  So only one
file is ever used (much like the group attributes pages).

It could be rewritten however (a bit of a pain) to include if it
exists Kingdom.php first, then include Kingdom-Animal.php and then
Kingdom-Animal-Canine.php third, each one overwriting any settings in
earlier ones.  This might be more what people expect, and makes some
things easier.  That is, with the current system you have to repeat
config settings in child config files.  I hesitate to do this however,
as I can it making debugging problems far more complex.  And at least
for starters, we should perhaps keep it simple...

Anyone have any opinions on this?

Cheers,
Dan



More information about the pmwiki-users mailing list