> Michael Aemisegger wrote:
>
>The context menu items are
faded with the help of _javascript_ triggers, e.g.
> see AdminTreeWebsite.prepareContextMenu(Tree,
HttpServletRequest):
>
> menuOpen.addJavascriptCondition("new mgnlTreeMenuItemConditionSelectedNotRoot(" //$NON-NLS-1$
> + tree.getJavascriptTree() + ")"); //$NON-NLS-1$
>
>The 'open page' context menu item only is active, if it is not the root node. There are a
>
> menuOpen.addJavascriptCondition("new mgnlTreeMenuItemConditionSelectedNotRoot(" //$NON-NLS-1$
> + tree.getJavascriptTree() + ")"); //$NON-NLS-1$
>
>The 'open page' context menu item only is active, if it is not the root node. There are a
>bunch of predefined _javascript_
conditions in /admindocroot/js/contextmenu.js
I understand this,
and I am able to add logic in the AdminTreeWebsite class to apply my permissions
check to disable context menu items if the user is not in the "cmsPublisher"
role. This is not very granular however. This means that a
'publisher' is granted publish rights to ALL content for which they have write
privileges. Also, it means that in order to be a publisher, you MUST also
be able to edit the content. I want to implement a more granular and
flexible solution in which permissions are applied at the tree node level just
like the other permission sets (read, write, deny). What I am having
difficulty finding is where in the source code the permissions are evaluated for
adding these _javascript_ conditions.
Any insight into
how this handled?
-KG
