App permissions

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 their work.

Superuser view of the app launcher Editor view of the app launcher

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.

App group

To grant permissions to an app group:

  1. Create a permissions node under the group in the app launcher layout.

  2. List the permitted roles as properties.

Example: The Tools group is provisioned to the superuser role only.

List of permitted roles

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.

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.

Advanced example: Use voters to include and exclude groups in a flexible way. The class checks if the current user has access permissions by comparing user roles and configured roles. The configured roles can be allowed or denied.

This example denies (not=true) permission to the travel-demo-admincentral role. This saves the effort of listing all roles that are permitted.

Denying group access

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.

Example: The Groovy app is provisioned to the scripter role only.

Granting permission to an app

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 info.magnolia.ui.api.availability.ConfiguredAvailabilityDefinition. The node names are different from those used in granting permissions to apps and app groups.

In this example, the Delete permanently action is granted only to superuser and demo-project-publisher roles.

Granting permission to specific roles only


DX Core



This widget lets you know where you are on the docs site.

You are currently perusing through the DX Core docs.

Main doc sections

DX Core Headless PaaS Legacy Cloud Incubator modules
6.3 beta

Magnolia 6.3 beta

Magnolia 6.3 is in beta. We are updating docs based on development and feedback. Consider the 6.3 docs currently in a state of progress and not final.

We are working on some 6.3-beta known issues during this phase.