Different ACL for sub pages
As an enhancement to Hierarchical ACL feature (coming in v1.6), allow a page to have a different set than those inherited by its subpages.
Explanation
While the Hierarchical ACL feature is extremely useful as is, I think that it's missing a very important component. As I've started planning to actually use it in our wiki, I keep running into the same issue: The ACL that I want to apply to all of a page's subpages is not necessarily the ACL that I want to be used by that parent page.
I've run into a number of actual usage cases where this is true, and have since thought up some others. But to be brief, I'll supply just one easy-to-understand case, and let the reader's imagination take it from there...
Example
Think of a page like MoinMoinbugs, which is parent to a whole lot of subpages. Now consider that you want to allow full editing on all of the subpages, but have encountered the need to prevent users from editing the MoinMoinBugs page itself.
(You could avoid the issue altogether by disabling the acl_hierarchic setting altogether, but I'm assuming that the feature is wanted in the wiki...)
The hierarchical ACL will let you set the "default" rights for all of the subpages at once, to anything you want, but this is done by setting the #acl on the MoinMoinBugs page. This means that if MoinMoinBugs is set to restrict the write permissions, those same permissions will apply to all subpages and prevent anyone from filing any bug reports. will require editing the ACL on each subpage in order to override this. This manual editing of all subpages is the sort of thing that the hierarchical ACL was meant to prevent.
OK, one more quick example... You may want to have a restricted area where the front (parent) page is visible by all, but all of the subpages can be seen only by a select group of people.
Conclusion: there is no workable way to have a page with one set of rights, and still specify a different set of default rights for all of its subpages.
Solution
Allow parent page to specify the rights that apply to itself, independently from the default rights that it specifies for all of its subpages.
Implementation
Add #subacl processing instruction to specify child pages rights. In resolving the ACL of a subpage, the #subacl value will be returned if it exists, and #acl if not. The presense of #subacl will in no way affect the page where it appears.
Example setup for MoinMoinBugs:
## MoinMoinBugs #acl CoreTeamGroup:read,write,delete,revert All:read #subacl: All:read,write,delete,revert
Rights checking order:
- acl_rights_before
- sub page #acl
- parent page #subacl or parent page #acl
- rest of parent pages...
- acl_rights_default (only if there was no page acl?)
- acl_rights_after
Self ACL entry
An additional special entry (like "Self") could be provided to include the contents of the page's #acl line, much like Default will insert the contents of acl_rights_default.
Example setup:
#acl FooGroup:read,write All:read #subacl: BarGroup:read,write Self ## -> "BarGroup:read,write FooGroup:read,write All:read"
Discussion
IMHO it is a bit asymmetric and ugly. I do not know this kind of approach in other ACL systems either ... How about a page rename to get the page out of the hierarchy? Or move all subpages one level down ... -- AlexanderSchremmer 2007-07-16 11:01:19
- What I would consider more asymmetric and ugly is making the user abandon a logical page hierarchy, that makes sense, or do some other workaround, just so the ACL works acceptably. That's the tail wagging the dog, IMO.
Perhaps this does not come up in common security schemes because file systems have both files and directories, each of which can have their own permissions. The permissions on a directory "A" are inherited its subdirectories, but the documents in directory A have their own permissions (which do not affect any of directory A's child directories). With this wiki, however, each page acts as both a document and a directory, so without doing something special (as I'm proposing), there is no way to separate the "document" permissions, used for the page itself, from the "directory" permissions, which get inherited by subpages. The hierarchical ACL as implemented would be analogous to a file system that would not allow any file to alter the security rights inherited from the directory where it resides. -- SteveDavison 2007-07-16 17:56:42
The old acl behavior is much better for such use case, which is very common in my wikis. I guess it is a common to have more restrictive acl on a central page, and less restrictive acls (or None) on the sub pages. I'm not sure about the proposed #subacl implementation - but it looks simple and clear. -- NirSoffer 2007-07-16 11:35:32
New Proposal
OK, forget my original proposal. I have a new one that is way better. It has less effect on the current implementation and is much more clearcut. A couple of illustrations...
Original Proposal
In the above-described scheme, the inheritance chain has to choose between #acl and #subacl at every level. And the decision of whether the #subacl should act as a root, or inherit from the current page or the parent page, is a bit muddy.
New Proposal
The new scheme... First ignore that there is any concept of "local acl". The ACL for each page, and hierarchical ACL, works just as it would now.
So here's the extension. Picture each page as both a document and a directory that contains all of its subpages, and itself (its page contents). The #acl line on a parent page is interpreted as the ACL for the "directory", so it applies to both the parent page and all its subpages. Now consider that you want the parent page to have different rights than the default for its tree. This would be accomplished by adding a second line to the parent page, let's call it #localacl, that is processed before the "tree" #acl.
This essentially treats every page as a peer to its subpages. But this is not all that weird, because this is a valid way of interpreting how the current implementation works ... (wherein the subpages are allowed to override the inherited ACL, but the parent page cannot 
). In this proposal, the only difference between the parent page and the subpage ACL is that any subpage can override the inherited ACL by specifying an #acl line of its own; the parent page, however, already contains an #acl line for its tree, so an additional line (#localacl) is needed in order to differ from the tree's default.
Finally, the formula for processing hier ACL would be [ #localacl ] + #acl + parent #acl + grandparent #acl . . . Considering that this simply requires a concatenation (only once per chain), and that the current hier ACL already uses a concatenation technique, it should be a very simple, straightforward change.
I'm sure I could have explained it simpler, but hopefully this works. Anybody see any holes in the logic? -- SteveDavison 2007-07-17 07:54:51