[pmwiki-users] Hiearchical Groups Proposal.

Stirling Westrup sti at pooq.com
Wed Oct 18 00:16:19 CDT 2006


Patrick R. Michaud wrote:
> On Fri, Oct 13, 2006 at 11:45:42PM -0400, Stirling Westrup wrote:
>> Patrick R. Michaud wrote:
>>> A couple of questions for this proposal.  (I'll probably have more, 
>>> but these are the ones that jump out at me at the moment.)
>>>
>>>  - Where are group attributes stored?  Or do we simply say that
>>>    any passwords on a page automatically apply to all of its
>>>    subpages except where overridden by a subpage?
>>>
>>>  - How do we handle GroupHeader and GroupFooter?
>> I would like to say that any passwords on a page automatically apply to
>> all its subpages except where overridden, but I also don't want to break
>> working wikis where the attributes for SomeGroup are stored in
>> SomeGroup.GroupAttributes.
> 
> One outcome of this approach is that it's not possible for a group's
> "home page" to have a different set of passwords from other pages
> in the group.  

Since I'm assuming that we'd allow a distinct 'Home' page for backwards
compatibility, they could just activate the distinct Home page for the
group. Then you could set the group passwords in the group page and set
different ones in the 'Home' page.

One would also have the option of adding an intervening page who's only
purpose is to reset the passwords. Thus one might have a publicly
readable Group page with a Group.Private subpage which restricts reading
to members, and numerous Group.Private.* pages that make use of this. I
worry that this would cause some people to start requesting 'invisible'
pages in the hierarchy so they can make it look like these are all just
Group.* pages.

If this became a major issue I could imagine having a more complex
scheme that allowed one to set multiple collections of passwords in the
page's metadata, each collection associated with a page selector of some
kind. This would allow one to set passwords for 'this page and below' or
separate passwords for 'just this page' and 'this page's children', but
I'd be reluctant to go down that route. I find the current
authentication scheme hard enough to navigate as is.

>> Ideally GroupAttributes, GroupHeader and GroupFooter would eventually be
>> migrated into the metadata for a page, and would apply to that page and
>> all its subpages. 
> 
> If GroupAttributes, GroupHeader, and GroupFooter become page metadata,
> that would seem to imply that we need a mechanism to be able to
> edit these metadata.  And presumably we should keep track of
> the history for these metadata items as well.

This would seem logical, although not all metadata would necessarily
need to have its history tracked. GroupHeader and GroupFooter might, but
I don't think GroupAttributes would. Metadata history would seem to be
something that one might want to enable on an individual case basis when
defining new page attributes, and which should probably default to disabled.

A more general metadata system might be desirable anyway, as there are
many things one might end up wanting to cache in a page and I can
imagine many recipes that might make use of such a facility.

> Not saying these can't be done, just pointing out the logical
> conclusions.

Yes. And you'll note that the metadata upgrades are not required to
implement my scheme. Its just that if my scheme were implemented it
would (I imagine) tend to make these changes seem more desirable.





More information about the pmwiki-users mailing list