Magnolia 5.3 reached end of life on June 30, 2017. This branch is no longer supported, see End-of-life policy.

Page tree
Skip to end of metadata
Go to start of metadata

You can control app access by specifying a role. Members of the role can see the app in the launcher and can start the app. With this mechanism you can provision an entire group of apps in one go or individual apps. You should provision apps only to users who actually need them. This ensures that the app launcher stays clean and users find apps quickly.

Here is a comparison what superuser and editor roles see in the app launcher. The editor role only sees apps that are necessary for his work.

  

Granting permissions to an app group 

An app group contains apps that have something in common, grouped together in the App launcher. For example, the Edit group contains the Pages, Assets and Contacts apps. Each app in the group covers specific duties in content management.

To grant permission to app group:

  1. Create a permissions node under the group in the app launcher layout.
  2. List the permitted roles as properties.

In this example, the Dev app group is provisioned to the superuser role only. The name of the role property name is arbitrary but the value must be a valid role name.

Node nameValue

 modules

 

 ui-admincentral

 

 config

 

  appLauncherLayout

 

 groups

 

 dev

 

 apps

 

 devTools

 

 messages

 

 sample

 

 groovyConsole

 

 groovyScripts

 

 permissions

 

 roles

 

 superuser

superuser

If the role doesn't exist, create it first in the Security app. If you need a role just for the purpose of provisioning apps, an "empty" role is enough. The role does not need any ACLs or permissions to site URLs. To grant additional users access, assign them to the role. You can add as many role properties as you need.

Best practice

Create a new app group for your own apps, especially if you have multiple apps. This approach is better than placing your apps in the native Magnolia groups. A dedicated group gives your organization's apps an identity and makes them instantly recognizable. Remember to choose a safe app group color.

Granting permissions to an app

To grant permission to an app:

  1. Create a permissions node under the app descriptor.
  2. List the permitted roles as properties.

In this example, the Groovy app is provisioned to the scripter role only.

Node nameValue

 modules

 

 groovy

 

 apps

 

 groovy

 

 permissions

 

 roles

 

 scripter

scripter

Best practice

Provision apps only to users who actually need them. This ensures that the app launcher stays uncluttered and users find apps quickly.

Configuring action availability

Action availability is the lowest level of app access you can configure by role. Actions define what a user can do with the app.

You can configure action availability at two levels:

Action availability is provided by  ConfiguredAvailabilityDefinition . The node names are different from those used in granting permissions to apps and app groups.

In this example the Publish deletion action is granted only to superuser and demo-project-publisher roles.

Node nameValue
 modules 

 pages

 

 apps

 

 pages

 

 subapps

 

 browser

 

 actions

 

 activateDeletion

 

 availability

 

 access

 

 roles

 

 demo-publisher

demo-project-publisher

 superuser

superuser