Controlling AdminCentral access

AdminCentral is a Magnolia CMS user interface where administrators and editors work. In this post I show how to configure menu permissions for a custom user role.

AdminCentral provides menus for common tasks. When you click a menu, workable items are displayed on the right.


You can hide menus and move them around to promote often-used items or deny permission to items that users should not be able to access. Magnolia CMS ships with typical roles such as superuser, editor and publisher. While a superuser can see everything, editors only see items that are relevant to their job.

Permissions for custom roles

Suppose your organization has a very specialized editor role, Category Editor, who is responsible for maintaining a taxonomy of categories. Categories are tags that help site visitors find related, interesting content.

Categories are managed in a custom data type under the Data menu. The demo-project website has an example taxonomy consisting of categories such as Culture, Family and Finance. The Category Editor needs access to the Data > Category menu only.


You can approach setting permissions for this role in two ways:
  • Top down: Start with a more powerful editor role and remove permissions until only the ability to edit categories is left.
  • Bottom up: Start with zero permissions and keep adding until the Category Editor can do their job. 

Magnolia CMS ships with a demo-project-base role that provides many basic permissions common to all users. It's a good starting point so let's choose the first option: top down.

Create category-editor role

Create new role category-editor and new user jsmith. Assign roles demo-project-base and category-editor to user jsmith.

Now open another browser instance and sign in as jsmith. You should see three menus: Website, Documents and Data.


The Category Editor doesn't need the first two menus or the Contact submenu so let's remove them.

Hide menus

Edit the access control lists (ACL) attached to the category-editor role. Deny access to the following nodes in the config workspace:
  • /modules/adminInterface/config/menu/website$
  • /modules/adminInterface/config/menu/dms$
  • /modules/adminInterface/config/menu/data/Contact$
The demo-project-base role already grants access to the same nodes so you need to make the deny rules "win". If a user has multiple ACLs through role and group assignment that specifically list the requested resource, the ACL with the longest pattern determines the permission. The order of the rules is not considered. This is a critical point. Use the dollar sign ($) to mark the end of the path, which makes the deny rule longer.

Here's what the Category Editor sees after the ACLs have been applied. Menus are now perfect but the editor cannot edit the data items. Categories have a crossed-out pen icon to indicate this.


Grant access to data

Add an ACL in the data workspace that grants Read/Write permission to /categorization node. Now the items are editable.


Lock the backdoor!

Menus are not the only way to access content in AdminCentral. They just provide convenient access to often-used items. If you are restricting access per security, not just for convenience, make sure you lock down the content too:
  • Workspaces store the actual content. Make sure that any role you choose as a basis does not grant access to a workspace that users should not be able to access. In our example the demo-project-base role does not grant any unnecessary workspace permissions. You can control workspace access with an ACL. Select the workspace from the controlled space dropdown.
  • Trees are customized views into specific data. Users can view trees with a direct URL if they know the name of the tree, for example http://[host]/[instance]/.magnolia/trees/website. Each module can register its own trees. Look in /modules/adminInterface/trees to get an idea. As long as you restrict permissions to workspaces correctly, trees will honor the permissions.  
  • Pages provide specialized tools such as exporting, importing and querying. Users can access pages with a direct URL too: http://[host]/[instance]/.magnolia/pages/jcrUtils. Like in trees, content cannot be accessed through pages as long as the workspace is locked down.