Concept - Action availability and access control

Summary

Actionbar -> sections -> groups -> items

sections can be shown/hidden

groups and items can be enabled/disabled

based on selected node/item (not all actions operate on a node/item)

based on roles

In page editor we enable/disable actions in the actionbar based on which permissions the current user has for the selected component/area.

In dam we enable/disable based on wether the asset is a master (this is probably outdated logic).

We typically hide/show sections based on node type - and enable/disable groups to control if edit actions or add actions should be shown. This is not always the case.

In Pages browser we show activateRecursively only if there are sub pages.

In Security app we enable/disable adding or editing actions based on if the selected node is /admin or /system. Can only edit below these nodes and only add on these nodes.

For redo/undo we will enable/disable based on the undo history size.

Logic charts for current behaviour

Availability

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

-

Access Control

Configuration Proposal

Given the base path /modules/foo-app-bar/apps/bar/subApps/browser/

 Proposal: implement context sensitivity here, on actions. This is conceptually close to template definitions availability

• An option is to use voters for both visibility and disablement of an action (see delete action).
• We may then consider a default configuration for content subApps