Page History

Summary

This concept page describes both how to control when an action is available and how to restrict access to such actions.

Availability

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 Sections can be shown/hidden.

groups 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.

The availability is based on the selection although specific exceptions exists. For instance not all actions operate on a selected node.

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

...

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

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

...

Problem

The action bar can take several states within one sub-app.

...

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/

Node name	Value
actions	-
addBar	-
addCocktail	-
editBar	-
class	info.magnolia.ui.admincentral.action.EditDialogActionDefinition
dialogName	foo-app-bar:bars
i18nBasename	foo.bar.actions.edit
icon	icon-edit
label	Edit
nodeType	foo:bar
editCocktail	-
extends	../editBar
implementationClass	org.foo.app.bar.action.EditCocktailAction
nodeType	foo:cocktail
delete	-
class	info.magnolia.ui.admincentral.action.DeleteItemActionDefinition
icon	icon-trash
label	Delete item
visible	-
voters	-
role	-
allow	-
0	admin
1	editor
class	info.magnolia...RoleVoter
type	-
allow	-
0	foo:bar
deny	-
0	foo:readonlybar
class	info.magnolia.ui...WorkbenchSelectionTypeVoter
instance	-
allow	-
0	magnoliaAuthor
class	info.magnolia...SystemInstanceVoter
op	AND
disabled	-
voters	-
multiselect	-
class	info.magnolia.ui...WorkbenchMultipleSelectionVoter
nullselect	-
class	info.magnolia.ui...WorkbenchNullSelectionVoter
rootselect	-
class	info.magnolia.ui...WorkbenchRootSelectionVoter
op	OR

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

Determining wether the current user has access to an actions should be based on roles. We need to configure the required roles on the action definition.

If the user does not have access we should show the action as disabled in the actionbar.

Page tree

Versions Compared

Old Version 7

New Version 8

Key