Jukka Zitting wrote:
> You could create a special ACL entry for record #0 that would be used
> when creating new toplevel records.
Ah, so ID 0 is not normally used anywhere? Then ID 0 just volunteered to
be the
table root ID.
I'm trying to get straight what will need to be done for the ACLs. Here
are the fields
I think will be relevant:
** article:
If an article doesn't have an ACL 'up' will be used to find the nearest
parent that
does, cascading back to the table root ACL. Cascading to host is not an
option because
pages may "belong" to more than one host.
what does 'topic' refer to? The topic the article belongs to? But what
does 'up' mean,
then? And do we want to cascade via the 'up' link or the 'topic' link?
We can set up additional ACL entities for author, creator, revisor,
approver and locker
if we want to. Not really useful for ACL entries on resources
themselves, but
very useful for cascading (so you can give creators modify permission in
a whole
tree of articles without having to assign each article an ACL). Since
ACL entities
are not bound to actual table fields, this would work even if we cascade
from article
to the topic tree.
** element, file, page element, preference, member:
do we want to cascade to another table (element->style,
file->article(->topic),
page element->page, preference->person, member->group) or the
[element|file|page element|preference|member] table root?
** grp, host, style:
will field 'owner' still be present, or replaced by the ACL?
** page:
Same argument as for article: special entity 'author'.
** person:
Same argument as for article: special entity for 'self' and 'creator'
** topic:
Cascade to 'up' then topic table root. We may want to drop 'owner'.
Special
ACL entities 'creator' and 'revisor'.
Bye,
Emile
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
