This resolves some of our ACLs issue, the biggest part of it.
We get an admin to establish separate #acls for Docs/ and Docs/Drafts,
and the children inherit them. *whew*
During all this, I considered if we even want an ACL for Docs/Drafts/.
If we don't, anyone with EditGroup can start a draft document. The ToC
at Docs/ that includes draft content need only include documents who's
writers have Done The Right Thing.
Some more information:
http://moinmaster.wikiwikiweb.de/HelpOnAccessControlLists
http://moinmoin.wikiwikiweb.de/HierachicalAccessControlList?highlight=%28...
-------- Forwarded Message --------
From: seth vidal <skvidal(a)phy.duke.edu>
To: kwade(a)redhat.com
Subject: hiearchical acl's in the wiki
Date: Thu, 25 Aug 2005 21:39:07 -0400
Hi Everyone,
I added in the hierarchical ACLs patch for MoinMoin to the instance on
fedoraproject.org.
This means if you add an acl to a page then any page which is a falls
below that location in the tree will also have that acl unless that
specific page is set otherwise.
An Example:
if
http://fedoraproject.org/wiki/Extras Has an acl that allows people
from ExtrasGroup to read and write to it, but not to delete or revert
and you made
http://fedoraproject.org/wiki/Extras/HowToUse Then HowToUse would
have the same acls as Extras.
I used this diff:
http://moinmoin.wikiwikiweb.de/HierachicalAccessControlList?action=Attach...
more or less.
-sv
--
Karsten Wade, RHCE * Sr. Tech Writer *
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/