[pmwiki-users] Hierarchical permissions

[The Editor]

On 1/31/07, Patrick R. Michaud <pmichaud at pobox.com> wrote:
> On Thu, Feb 01, 2007 at 07:17:08AM +1100, Kathryn Andersen wrote:
> > On Wed, Jan 31, 2007 at 07:05:08AM -0500, The Editor wrote:
> > > 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.
> >
> > Yes. the latter is what I would have expected/hoped for with
> > hierarchical groups, otherwise there doesn't seem much point, since you
> > don't gain from higher-up settings if you have to repeat them for every
> > lower-down config file.
>
> It's not true that config settings have to be repeated in every
> lower-down configuration file -- it's easy enough to do with
> include_once().  For example, to have Kingdom-Animal-Canine.php
> start with Kingdom-Animal.php's settings, place the following
> at the beginning of Kingdom-Animal-Canine.php:
>
>    include_once('Kingdom-Animal.php');

Great idea!  Good reason #1 to leave it as is, then.

> There's a strong reason why PmWiki loads the child configurations
> before the parent ones, and that's because it's far easier to
> prevent something from loading/happening than it is to "undo" the
> effects after something has loaded/happened.
>
> For example, suppose I want to load a customization in
> every page in the XYZ group except for XYZ.MainPage .  If XYZ.php
> is loaded before XYZ.MainPage.php, then I have to either put
> code into XYZ.php that says "perform the customization except for
> XYZ.MainPage", or I have to figure out some code in XYZ.MainPage.php
> to undo the effects of any customizations that were made in XYZ.php.
>
> However, if XYZ.MainPage.php loads first, it has a chance
> to make additional configuration settings before XYZ.php
> is loaded, including the possibility of avoiding the
> customization altogether.  And a single include_once()
> statement can get the other behavior.
>
> (This is especially true when using SDV()  (set default value)
> to set configuration variables only if they aren't already set.
> If the per-group customization is done first, then the
> per-page customization cannot specify defaults but can only
> explicitly override already set values.)

Good reason #2 to leave it as it is.  Thank Pm!  I hadn't thought
about either of these--but they make good sense to me...

Of course, it could be argued we do the includes of group config files
from child group on up to parent group, but then we lose the advantage
Kathryn was hoping for of making the settings hierarchical (ie
inheritable).  So as neither an up-down or down-up approach is really
very helpful, we should just stick with the current "first one you
find" approach

On Wed, Jan 31, 2007 at 03:58:11PM -0500, The Editor wrote:
> > I'm especially hoping for feedback from Pm on which option he would
> > prefer, as I'm not sure all the implications of loading multiple
> > config pages into a page.

> PmWiki already loads multiple config files for a given page.
> See http://www.pmwiki.org/wiki/PmWiki/WikiCascades .

Ah yes, very useful page.  Sorry I didn't see it first. For the sake
of those interested, the Hg recipe I just released should work exactly
like PmWiki, that is, there is no change to the following order:

      $FarmD/local/farmconfig.php        # farm-wide settings
      local/config.php                   # field/wiki settings
      local/$Group.$Name.php             # per-page settings
      local/$Group.php                   # per-group settings

The only change is that the last setting will be the first Group.php
file Hg finds up the chain, relative to the current location.  The
farm, field, and page config files should not be affected as far as I
can tell...

> > PS.  Does anyone recall if PmWiki normally includes both Group.php and
> > Group.Name.php into a page when both exist, or just the latter?  Hg
> > should probably do the same, shouldn't it?

> It includes both, unless Group.Name.php sets $EnablePGCust to zero,
> which tells scripts/pgcust.php to stop loading any more
> configuration files.

Well, good, I guess I did it correct then.  Hg sets EnablePGCust to
zero, then loads the page config file, and then afterwards, runs its
routine to find the first hierarchical group config page.  But I guess
in light of reasons one and two above, this isn't really a convincing
argument for making the group config files inheritable.

And lastly, though Pm didn't mention it specifically--I think we will
be getting people confused if multiple subgroup config files are
getting included.  I really am cautious about opening that kind of
complexity up to users...  There will be enough challenge just keeping
track of individual subgroup config files!

Cheers,
Dan

PS.  Thanks Pm for the input.  Very helpful.  Did you have any plans
to use the Hierarchical Groups cookbook page?  If not I'll keep this
script parked there.