[pmwiki-users] Ideas: Group-based user permissions

Christopher Dant cdant at virsa.com
Thu Sep 22 09:54:56 CDT 2005

> Wow, thanks for the detailed spec!  This gives me a bit to work with.
> I haven't had a chance to review it in much detail, but I did 
> want to quickly comment on the last section (which was also 
> mentioned in an earlier email)...


> Pm

Agreed, the burden of creating the associations between users and
content just shifts from users to wikigroups. This seems to be a very
light burden however, since I'm using wikigroups to partition the
content. For example: each time we contract with a new partner
organization (which will be relatively infrequent) those new users will
gain access to the existing shared wikigroup(s) plus a new one we create
exclusively for them. We won't add new shared wikigroups, we'll add new
content to the existing one (since we're using it as a 'secure
container' not as a category of information).

I have to agree with you entirely on this one: "...the majority of
authorization systems I've encountered associate the authorizations with
the resource to be protected, and not with the entities attempting to
access the resource." A better model might be group membership.

Would it be interesting to consider a new special page in each
wikigroup, members? Like MyGroup.Members or MyGroup.RecentChanges. This
page could be admin-restricted by default, and could be used to manage
the group membership list.

I think defining a new "group:" permission would work just fine. It
sounds like "group:abc" might be an instance of the broader concept of
custom permissions. What did you think of my definition of "permission"
as: (basic list item | extended list item), permission state, permission
period? Particularly permission period, since this would make it
possible to automatically "time out" access permissions.

As I read your 'off-the-wall ideas' I realized that my central issues
are not implementation so much as permissions themselves and managing
groups of people. In the final analysis, from a day-to-day admin
perspective, it's being able to see and change the current permissions
on groups of users at once, rather than one by one.


More information about the pmwiki-users mailing list