Page History
This concept page describes both how to control when an action is available and how to restrict access to such actions.
| Table of Contents |
|---|
...
Action availability
The availability is based on the selection although specific exceptions exists. For instance not all actions operate on a selected node. For redo/undo we will enable/disable based on the undo history size.
Both in the actionbar and in the context menu we want to show actions as enabled or disabled. We do not want to replicate the configuration in both places. Therefore we will configure it on the actions themselves.
On the action definition we need to be able to specify
- the node types the action is available for
- whether its available when there's no selection (the root node is selected)
- and whether its available for properties
- any node types the action should only be available for
If no node types are specified the action is available for all nodes.
Actionbar appearance
The actionbar should only show one section at a time. The section to show depends on the selected node. Therefore we need to configure:
...
- whether its available to be shown when there's no selection (the root node is selected)
- and whether its available to be shown for properties
...
Q: We currently toggle show/hide on sections based on the node types. Is this desirable? It has the effect of actions moving around when the selection changes.
A: We never want to show more than one section at a time. The contacts app should be changed to behave this way.
- the node types that it should only be shown for
If no node types are specified the section is not shown for nodesQ: Do we want to hide a section if all its actions are disabled? What if the user is not authorized to use any of the actions does it then make sense to hide the section?
A: Based on the answer above we should never hide a section because that would make the actionbar empty.
Access Control
Determining wether the current user has access to an action should be based on roles. We need to configure the required roles on the action definition.
...
This should follow the configuration style implemented in
| Jira | ||||
|---|---|---|---|---|
|
Appendix 1 - The current availability and actionbar behaviour
We control availability by hiding sections and disabling groups or individual actions.
...
| Configuration App | G addingActions | G duplicateActions | G activationActions | G importExportActions | A addFolder | A delete |
|---|---|---|---|---|---|---|
| no selection or root | x | |||||
| any node | x | x | x | x | unless mgnl:contentNodex | |
| property | x |
| Security Groups/Roles | G addActions | G editActions |
|---|---|---|
| no selection or root | x | |
| any node | x |
...
| Pages | A delete | A preview | A edit | A export | A activate | A deactivate | A activateRecursive |
|---|---|---|---|---|---|---|---|
| no selection or root | |||||||
| any selection | x | x | x | x | x | x | only if no sub pages |
Configuration proposal (rejected)
on each level, section, group, action, we need to configure three things:
| Name | Type | Default | Description |
|---|---|---|---|
| noSelection | boolean | false | available when no selection or not |
| nodeTypes | node | node with subnodes for each node type | |
| properties | boolean | false | available for properties or not |
if no constraints are configured for an action it takes the decision of the containing group, otherwise it takes its own decision
there is no way to configure availability for all node types
there is still a need for custom logic, like for checking activateRecursive, which is fine, because its unusual, but for undo/redo there ALWAYS has to be a custom check
...
Appendix 2 - Previous notes
...
Overview
Content Tools