Note: This is a draft version written for the October 2009 alpha2 release of Joomla! version 1.6. Since version 1.6 is still under active development, screenshots and other information discussed in this article may change before the final release of version 1.6. However, it is expected that the basic concepts outlined here will not change.
In the case of Joomla!, we have two separate aspects to ACL.
This section outlines the major ACL changes between versions 1.5 and 1.6.
With the definition in mind, let's look at how we set up the ACL for our site in version 1.6. The table below summarizes the major changes from version 1.5.
|Version 1.5||Version 1.6|
|Groups||7 fixed groups (Public, Registered, Author, Editor, Publisher, Manager, Administrator, and Super-Administrator)||Unlimited user-defined Groups|
|Users & Groups||A User can be assigned to only one group||A User can be assigned to multiple groups|
|Access Levels||3 fixed Access Levels (Public, Registered, Special)||Unlimited user-defined Access Levels|
|Access Levels & Groups||Relationship between Groups and Access Levels was fixed.||Groups are assigned to Access Levels. Any combination of Groups can be assigned to any Access Level.|
We see that in every case the ACL has been made much more flexible, with unlimited Groups and Access Levels, and the ability to assign one User to multiple Groups and any Groups to any Access Level.
The other side of ACL is granting permissions to users to take actions on objects. Here again there is a big change between Version 1.5 and 1.6. In 1.5, the actions allowed for a given group were fixed. For example, a User in the Author group could only submit an article whereas someone in the Publisher group could submit, edit, and publish articles. Also, in version 1.5 the permissions were all-or-nothing. A member of the Editor group could edit all articles on the site.
The table below shows what has changed between versions 1.5 and 1.6.
|Version 1.5||Version 1.6|
|Groups and Actions||Actions allowed by different groups are fixed.||Actions allowed for each group are defined by site administrator.|
|Permission Scope||Entire Site. User has same permissions for all objects on the site.||Permissions can be set at multiple levels in hierarchy: Site, Component, Category, Object.|
|Permission Inheritance||Not applicable||Permissions can be inherited from parent Groups and parent Categories|
There are four possible permissions for actions, as outlined below:
Action permissions in version 1.6 can be defined at up to four levels, as follows:
This is accessed from Site → Global Configuration → Permissions. This screen allows you set the top-level permission for each group for each action, as shown in the screenshot below.
The options for each value are Not Set (shown as "..."), Allow, or Deny.
This is accessed for each component by clicking the Options icon in the toolbar. This screen is similar to the Global Configuration screen above, except that the options are Inherit, Allow, or Deny. An example is shown below:
Note that this option will only be available for members of groups who have permission for the Admin action in the Global Configuration screen.
Category permissions are accessed in the Category Manager: Edit Category screen. This screen has five tabs, as shown below.
The first tab shows the current permissions for each group for this category. Each of the other four tabs allows you to change the permissions for one action. For example, the screen below shows how you can change the permissions in the Create tab.
Note that the Manage and Admin actions do not apply at the category level, so those actions are not included.
Note also that Categories can be arranged in a hierarchy. If so, then action permissions in a parent category are inherited automatically by a child category. For example, if you had a category hierarchy of Animals → Pets → Dogs, then the full permission level hierarchy for an article in the Dogs category would be as follows:
Permissions for a single article are access in the Article Manager: Edit Article screen. This screen has four tabs, as shown below.
The first tab shows the current permissions for each group for this article. Each of the other tabs allows you to change the permissions for one action. For example, the screen below shows how you can change the permissions in the Delete tab.
Note that the Manage, Admin, and Create actions do not apply at the article level, so these actions are not included. Permission to create an article is set at one of the higher levels in the hierarchy.
Access Levels in version 1.6 are simple and flexible. The screen below shows the Special Access Level.
To create an access level, you simply check the box for each group you want included in that level. The Special Access Level includes the Administrator, Manager, Publisher, Editor, Author, and Super Users groups.
Once Access Levels are created, they are used in the same way as in version 1.5. Each object in the front end is assigned an Access Level. If the level is Public, then anyone may access that object. Otherwise, only members of groups assigned to that access level may access that object.
For example, the screen below shows the Edit Menu Item screen with the list of available access levels.
When Joomla! is installed, these are set to their initial default settings. We will discuss these initial settings as a way to understand how the ACL works.
Version 1.6 allows you to define your own Groups. When you install version 1.6, it includes a set of default groups, as shown below.
The arrows indicate the child-parent relationships. As discussed above, when you set a permission for a parent group, this permission is automatically inherited by all child groups. The Not Set, Inherit, and Allow permissions can be overridden for a child group. The Deny permission cannot be overridden and will always deny an action for all child groups.
Joomla! version 1.6 will install with the same familiar back-end permissions as that of version 1.5. However, with 1.6, you can easily change these to suit the needs of your site.
As discussed earlier, the permissions for each action are inherited from the level above in the permission hierarchy and from a group's parent group. Let's see how this works. The top level for this is the entire site. This is set up in the Site->Global Configuration->Permissions, as shown below.
The first thing to notice is the column headings, Admin, Login, Manage, Create, Delete, Edit, Edit State. These are the actions that a use can perform on an object in Joomla. The specific meaning of each action depends on the context. For the Global Configuration screen, they are defined as follows:
On the left side, we have the Groups for the site. In this case, we have the standard 7 groups that we had in version 1.5 plus we have an additional group called "Park Rangers". Notice that our groups are set up with similar permissions as they were for version 1.5. Keep in mind that we can change any of these permissions to make the security work the way we want. Let's go through this to see how it works.
There are two very important points to understand from this screen. The first is to see how the permissions can be inherited from the parent Group. The second is to see how you can control the default permissions by Group and by Action.
This provides a lot of flexibility. For example, if you wanted Park Rangers to be able to have the ability to login to the back end, you could just change their Login value to "Allow". If you wanted to not allow members of Administrator group to delete objects or change their state, you would change their permissions in these columns to Inherit (or Deny).
Now, let's continue to see how the default back-end permissions for version 1.6 mimic the permissions for version 1.5. The Super Users group in 1.6 is equivalent to the Super Administrator group in 1.5.
Just looking at the Global Configuration screen above, it would appear that the Administrator group and the Manager group have identical permissions. However, in version 1.5 Administrators can do everything except Global Configuration, whereas Managers are not permitted to add users or work with menu items. That is also true in the default version 1.6 configuration. Let's see how this is accomplished.
If we navigate to Users->User Manager and click the Options button in the toolbar, we see the screen below:
This screen is the same as the Global Configuration Permissions screen, except that these values only affect working with Users. Let's look at how this works.
First, notice that the Administrator group has Allow permission for the Admin action and the Manager group has Deny permission for this action. Remember that the Admin action in the Global Configuration screen gives the group "super user" permissions. In this screen, the Admin action allows you to edit the Options values. So, the Administrator group can do this but the Manager group cannot.
Next, notice that the Administrator has Inherit for the Manage action and the Manager group has Deny permission. In this screen, the Manage action gives a group access to the User Manager. Since the Administrator has Allow for the Manage action by default, then the Inherit permission here means they inherit the Allow permission for the Manage action. Since the Manager group has Deny permission for the Manage action, members of the Manager group cannot access the User Manager and therefore cannot do any of the other user-related actions.
If you look at the Options for Menus->Menu Manager, you will see the same default settings as for the User Manager. Again, the Administrator group can manage and set default permissions for Menu Manager objects whereas the Manager group cannot.
In short, we can see that the different permissions for the Administrator and Manager groups are set using the Options->Permissions forms on the User Manager and Menu Manager screens.
It is also important to understand that this same Options->Permissions form for setting default permissions is available for all Joomla! objects, including Media Manager, Banners, Contacts, Newsfeeds, Redirect, Search Statistics, Web Links, Extensions, Modules, Plugins, Templates, and Language. So you now have the option to create user groups with fine-tuned sets of back-end permissions.
Default permissions for the front end are also set using the Options form. Let's look at Content->Article Manager->Options->Permissions.
First, if we look at the permissions for Administrator and Manager, we see that in this case Administrator can do all actions for articles and Manager can do all actions except the Admin action. So both groups can create, delete, edit, and change the state of articles, but a Manager cannot see or change the default permissions for articles.
Now, let's look at the groups Publisher, Editor, and Author and see how their permissions are set. All of these groups have Inherit permission for Admin and Manage. Remember that Publisher is a child of the Registered group, and Registered does not have any default permissions except for Login. Since Registered does not have permission for Admin and Manage, and since Publisher's permission for Admin and Manage is Inherit, then Publisher does not have these permissions either. This same permission is passed from Publisher to Editor and from Editor to Author. So, by default, none of these groups are allowed to work with articles in the back end.
Publisher has Allow permission for Create, Edit, and Edit State. This means that Publishers, by default, can add new articles, edit existing articles, and change the state of articles. Note that, by default, Publishers can not delete articles. However, this could potentially be overridden for a child group or at the category or article level in the permissions hierarchy.
Editors inherit the same permissions as Publishers except that they have Deny permission for the Edit State action. So Editors can Create and Edit but are not allowed to Edit State, which in this case means to Publish, Unpublish, Trash, or Archive articles. Remember that the Deny permission cannot be overridden for child groups or for categories or articles. So, with this setup, members of Editor and any child group of Editor can never have Edit State permission for any category or any article.
Finally, Authors inherit the Editor permissions except for the Deny in Edit. So Authors can only Create new articles and cannot do any other action. Again, since there is an explicit Deny, this cannot be overridden for any category or article.
It is important to remember that, except for the Deny settings, these permissions are only default settings for categories and articles and for any child groups that are created. So they can be overridden for child groups, for categories, and for specific articles.
The diagram below shows how each action in the permissions form relates to the various options on the Article Manager screen.
As discussed above, it is possible to define groups in a hierarchy, where each child group inherits action permissions (for example, the create permission) from its parent group. Action permissions are also be inherited from the permission level above. For example, a permission in the Article Manager is inherited from the same permission in the Global Configuration, and a permission in a child Category is inherited from the parent Category permission.
This dual inheritance can be confusing, but it can also be useful. Let's consider an example as follows. We have a school with a group hierarchy of Teachers → History Teachers → Assistant History Teachers. We also have a category hierarchy of Assignments → History Assignments. We want History Teachers and Assistant History Teachers to have the following permissions:
This ACL scheme is very easy to implement. The diagram below shows how this would be set up for the Create Action.
In the diagram, the Permission Hierarchy is shown down the left side and the Group hierarchy is shown across the top. Permissions are inherited down and to the right, as shown by the arrows. To implement the desired permissions, we leave the Global Configuration blank (Not Set) for all three groups. Similarly, in the Article Manager and Assignments Category, we leave the Create permission to Inherit for all the groups. As shown in the diagram, this means that these groups do not have Create permission for articles in general or for articles in the Assignments group.
To sum up so far, we have not set any special permissions to get to this point. Now, in the History Assignments category permissions screen, we set the Create permission to Allow for the History Teachers group. This setting overrides the Soft (Implicit) Deny that we had by default and gives members of this group permission to create content (articles and child categories) for this category. This Allow setting also is inherited by the Assistant History Teachers group.
Next, we need to grant History Teachers the Edit State permission while denying this permission to Assistant History Teachers. This is done as shown in the diagram below.
This configuration is the same as the one above except that this time we set the Edit State permission in the History Assignments category to Deny for the Assistant History Teachers group. This means that Assistant History Teachers will not be able to Publish or Unpublish articles in this category.
Note that this was accomplished by setting just two permissions in the History Assignments category: Allow for the History Teachers group and Deny for the Assistant History Teachers group.
Here are some examples of how you might set up the ACL for some specific situations.
We want to create a group called "Article Administrator" with back-end permissions only for articles and not for any other back-end menu options. Members of this group should be able to use all of the features of the article manager, including setting article permissions.
That's all you need to do. Members of this group can login to the back end and do everything in Article Manager but can't do anything else in the back end.