Magnolia 5.4 reached end of life on November 15, 2018. This branch is no longer supported, see End-of-life policy.
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.
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:
permissions
node under the group in the app launcher layout.Example: The Tools group is provisioned to the superuser
role only.
Node name | Value |
---|---|
modules | |
ui-admincentral | |
config | |
appLauncherLayout | |
groups | |
tools | |
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.
Advanced example: Use voters to include and exclude groups in a flexible way. The info.magnolia.voting.voters.RoleBaseVoter
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.
Node name | Value |
---|---|
permissions | |
voters | |
deniedRoles | |
roles | |
travel-demo-admincentral | travel-demo-admincentral |
class | info.magnolia.voting.voters.RoleBaseVoter |
not | true |
To grant permission to an app:
permissions
node under the app descriptor.Example: The Groovy app is provisioned to the scripter
role only.
Node name | Value |
---|---|
modules | |
groovy | |
apps | |
groovy | |
permissions | |
roles | |
scripter | scripter |
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 name | Value |
---|---|
modules | |
pages | |
apps | |
pages | |
subapps | |
browser | |
actions | |
activateDeletion | |
availability | |
access | |
roles | |
demo-publisher | demo-project-publisher |
superuser | superuser |
1 Comment
Luis Pérez García
I have been trying to use voters in an app group permissions like it's said in the advanced example.
In order to use voters, you have to change the class of the permissions node by adding a property named
class
and set it toinfo.magnolia.cms.security.operations.VoterBasedConfiguredAccessDefinition
It is not said anywhere in the documentation (or I wasn't able to find it).
I discovered it using the configuration in
/modules/log-tools/apps/logTools/permissions
as an exampleI hope this helps anyone and please, consider to add this to the documentation.