This concept page describes both how to control when an action is available and how to restrict access to such actions.
Action availability
The availability is based on the selection although specific exceptions exists. For instance not all actions operate on a selected node.
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
- whether its available when there's no selection (the root node is selected)
- 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 to be shown when there's no selection (the root node is selected)
- whether its to be shown for properties
- the node types that it should only be shown for
If no node types are specified the section is not shown for nodes.
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.
If the user does not have access we will show the action as disabled in the actionbar.
If no roles are specified on the action definition it is assumed to mean that everybody has access.
This should follow the configuration style implemented in
Appendix 1 - Actionbar behaviour before configuration
We control availability by hiding sections and disabling groups or individual actions.
Remember that the actionbar is organised in sections that contain groups that contain items. Each item is linked to an action. Actionbar -> sections -> groups -> items.
Sections can be shown/hidden.
Groups and items can be enabled/disabled.
Logic charts for current behaviour
Contacts App | S folderActions | G addActions | G editActions | S contactsActions | G addActions | G editActions |
---|---|---|---|---|---|---|
no selection or root | x | x | x | x | ||
mgnl:folder | x | x | x | x | x | |
any other node | x | x |
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 | x | |
property | x |
Security Groups/Roles | G addActions | G editActions |
---|---|---|
no selection or root | x | |
any node | x |
Security Users | G addActions | G editActions |
---|---|---|
/admin or /system | x | |
any node | x |
Assets | S folderActions | S assetsActions | A createVariant |
---|---|---|---|
no selection or root | x | ||
mgnl:folder | x | ||
any other node | x | only if node is master |
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 |
Appendix 2 - Previous notes
Problem
The action bar can take several states within one sub-app.
- In page editor, some actions are displayed or hidden according to the type of selection (page, area, optional area, component)
- This is currently handled in a dirty way:
- The action bar provides an API for showing/hiding a whole section
- Therefore the page editor sub-app defines 7 different sections, which mostly hold similar groups, and sometimes even similar (i.e. duplicated) action definitions.
- Sometimes the context sensitivity is only represented by enabling/disabling one or several actions
- Each sub-app has to reimplement the itemSelected listener to control proper enablement of actions
- Basic conditional enablement is not ensured, nor is it configurable
- One cannot easily control which actions are available (visible/enabled) based on parameters out of configuration (roles, instance)
- Conditional enablement of actions has already caused many issues before alpha1
Proposal
- Action bar definition should define two things:
- the structure: sections, groups, and all possible actions in these groups, in one single place. This ensures proper ordering of actions at all time
- the states that describe e.g. the section titles, the set of actions displayed, and potential substates. This mechanism should allow for additive composition of states (think of the use case for an optional AND editable area in page editor)
- Implementing context sensitivity then only means to configure these states properly and toggle between them.
- It is likely that context sensitivity is not handled at all at the action bar level, but rather straight on the actions.
- If so, the action bar definition is reduced to its sole structure.
- Edge case (page editor): do we provide a way to configure context-sensitive section titles?
Decision
-