Page History
This concept page describes both how to control when an action is available shown 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 sizeselected item.
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)
- and whether its available 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.
Q: 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?
...
- any node types the action should only be available for
If no node types are specified the action is available for all nodes.
Action availability is determined/evaluated by ActionExecutor and implemented in AbstractActionExecutor.
Q: Should ActionExecutor.isAvailable() take a JCR item or Vaadin item? Actions are passed a Vaadin item.
Access control
Determining wether the current user has access to an actions 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
| Jira | ||||
|---|---|---|---|---|
|
Mixins can also be used in node types.
Configuration and naming
Two proposal, either using the term restrictions or the term availability. Proposal 2 is used.
Default values need to limit the amount of configuration necessary.
Proposal 1 - Restrictions (implemented)
| ||
|---|---|---|
if (roles.empty || item.role in roles) && ((item is null && root) || (item.isProperty && properties) || (item.isNode && (nodeTypes.empty || item.nodeTypes in nodeTypes))
Proposal 2 - Availability
| Property | Meaning | Default value |
|---|---|---|
| availability.root | Action is available for root if true | false (not available) |
| availability.properties | Action is available for properties if true | false (not available) |
| availability.nodes | Action is available for nodes if true | true (available) |
| availability.nodeTypes | Action is available if empty or selected node is one of the node types in list | empty (available) |
| availability.access.roles | Action is available if empty or current user has one of the roles | empty (available) |
| availability.rule | Action is available if empty or rule.isAvailable() returns true | empty (available) |
if (roles.empty || item.role in roles) && ((item is null && root) || (item.isProperty && properties) || (item.isNode && nodes) || (item.isNode && (nodeTypes.empty || item.nodeTypes in nodeTypes)) && (rule is null || rule.isAvailable(item))
Proposal commentary
The term gets a bit confusing, restrictions.root sounds like it makes the action available for only root. But its really available for root AND by node types.
Rules
To allow use of advanced logic in the access evaluation without making the configuration too complicated and confusing, a new interface AvailabilityRule is introduced. The interface defines just one boolean isAvailable(javax.jcr.Item item) method. The availability definition can have a rule subnode, where the implementing class is defined (as the class property). If the rule is defined, the result of the isAvailable method is used in a logical conjunction with the result of the default availability definition evaluation.
The implementing classes may define their own configuration. The classes are in the info.magnolia.ui.api.availability package and in magnolia-ui-app-pages package.
Some proposed rules:
IsDeletedRule- returns true only if the item has been marked for deletion (i.e. has the mgnl:deleted mixin node type).IsNotDeletedRuleAllRulesRule- works like an AND operator, meaning all the other rules in this configuration must be satisfiedAllNodeTypesRule- as the default availability nodeTypes configuration uses disjunction (OR) to evaluate, this rule will return true only if the node has all the node types (e.g. mixins) defined in the rule configuration.ActivationStatusRule- according to its configuration, the rule will return true only if the item has / has not been yet activated, alternatively if it has been (not) changed since the last activation.PageHasSubPages
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.
If more than one section applies the first one is used. Example use case: in the Pages app, the pageDeletedActions section has a stricter rule (these actions are available only for deleted nodes) than the pageActions section (these actions are available for any nodes). Therefore, the pageDeletedActions section must be first.
Selecting the section to show and evaluating the restrictions/availability is done in BrowserSubApp.updateActionbar(), extending classes can override this method to implement their own behaviour.
Configuration and naming
Proposal 2 (Availability) is used.
Proposal 1 - Restrictions (implemented)
| ||
|---|---|---|
if (item is null && root) || (item.isProperty && properties) || (item.isNode && (nodeTypes.empty || item.nodeTypes in nodeTypes)
Proposal 2 - Availability
| Property | Meaning | Default value |
|---|---|---|
| availability.root | Section is shown for root if true | false (not shown) |
| availability.properties | Section is shown for properties if true | false (not shown) |
| availability.nodes | Section is shown for nodes if true | true (shown) |
| availability.nodeTypes | Section is shown if empty or selected node is one of the node types in list | empty (shown) |
| availability.access.roles | Section is shown if user has one of the defined roles | empty (shown) |
| availability.rule | Section is shown if empty or rule.isAvailable() returns true | empty (shown) |
if (item is null && root) || (item.isProperty && properties) || (item.isNode && nodes) || (item.isNode && (nodeTypes.empty || item.nodeTypes in nodeTypes) && (rule is null || rule.isAvailable(item))
Proposal 3 - Restrictions, meanings inverted
| ||
|---|---|---|
Proposal commentary
The term restrictions seems to make more sense here since we're only gonna pick one. It's more about excluding the one not to shown.
Appendix 1 -
...
Actionbar behaviour before configuration
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
Problem
The action bar can take several states within one sub-app.
...
Overview
Content Tools