[daisy] [JIRA] Commented: (DSY-502) Hiding linknodes from the
navigation tree.
Marc Portier (JIRA)
issues at cocoondev.org
Tue Jul 10 07:55:50 CDT 2007
[ http://issues.cocoondev.org//browse/DSY-502?page=comments#action_13239 ]
Marc Portier commented on DSY-502:
----------------------------------
Nope, but I think I understand where the confusion comes from:
"ContextDoc()" as a notation should probably change to something else since it is already in use with a different meaning. (I realize now) Maybe 'ContainerDoc()' is better?
Anyway, I have the feeling you think about this as a shorthand that would refer to the parent navigation-node of this link-node, right?
But in fact, I am looking for some syntax/notation that points to the actual containing navigation-tree-document. Like this one, could separate these link-nodes into a separate navtree, set access control on that sub-navtree to not readable for certain roles/users, and import that into the main navigation.
Or more explicitely:
suppose there is a nav-document-with-id=1-dsy
holding in its navigation-part a section like
+ docnode to id=666-dsy
+ linknode to some-url with @inheritACLFrom="ContainierDoc()"
then this inherit-attribute would be shorthand for "daisy:1-dsy" (the navtree document) and thus the linknode would be removed if the user has no _read access_ to that.
(So, it would not refer to 666-dsy. Like you stated that reference is already implicitly there indeed)
The use case for this in fact is that we want to hide link-nodes without introducing an otherwise meaningless parent-document-node.
> Hiding linknodes from the navigation tree.
> ------------------------------------------
>
> Key: DSY-502
> URL: http://issues.cocoondev.org//browse/DSY-502
> Project: Daisy
> Type: New Feature
> Reporter: Marc Portier
> Priority: Minor
>
> Navigation documents's are proper documents in Daisy that are used to build up navigation-tree's.
> Being documents they comply to the normal ACL rules, handing out read-write access to them.
> * meaning: depending on the outcome of the ACL you might not be able to 'access' and/or 'change' the navigation document on the repository
> Important though is that ACL is not controlling if a user can actually USE that navigation (this allows people to be able to 'use' the navigation in the side, and thus 'see and interact with its in page-representation' while not being able to actually access (read) the actual navigation document!)
> Note thought that in producing the navigation tree representation for a certain user there i*s* some additional ACL filtering going on: the navigation links pointing to document nodes on which the user does not have access will be filtered out.
> This way of working however makes it a bit hard to be able to remove link-nodes from the user's view of the navigation tree. Link-nodes are not associated to documents and therefore have no matching ACL rule that could ever point out that the link should be hidden for the current user.
> I would therefore propose to allow link-Nodes to specify from which Daisy document they want to inherit the ACL rule to be applied on them. This could be expressed through a inheritACLFrom attribute on the link-node. As a scpecial value for this attribute we could allow "ContextDoc()" thus pointing to the document containing the navigation-part that is holding the link-node itself. If the attribute is not set, behaviour should be as today: no filtering.
> By extension we might consider putting such kind of attribute also on import-nodes. This would allow people to split up the navigation in certain parts to be imported, and easily use the ACL rules on those different navigation-documents to affect the effective import into the nav-tree-representation in a way similar as described for the linknodes...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.cocoondev.org//secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
More information about the daisy
mailing list