Joomla 1.6, 1.7, and 2.5: ACL Concepts Overview

Many think of ACL as relating to the front end of a website only. For example, when I log into the website, what articles do I have available to me? And if someone else logs into the site, do they see the same articles, or do they see different ones?

However, ACL also relates to who has rights to create, edit, and delete content; who can publish and unpublish content; who can log into the front end or back end of the website; and who can make changes to which components, modules, and templates.

Just because you can doesn’t mean you should! ACL is complex, and it takes some time to understand exactly how it works. For many sites, perhaps even most sites, you might not need anything beyond the default Joomla configuration. However, if you’re building a larger site, it could come in handy.

Examples of where ACL would be required include:

• A school site, where parents, teachers, students, and the public see types of content
• A large website with many contributors, where you don’t want people changing each other’s content, and trust can’t or won’t work
• You have users who should be able to create and edit content for the website, but they can’t necessarily publish content. What’s more, you have two or more groups of these users who need to create and edit content belonging to different areas of the website.
• You would like a user to be able to log into the back end of the website, access controls for a single component, and touch nothing else.

ACL can also be used to build a simplified administrator interface, eliminating areas where a client would not need to visit to make changes to the site. In Joomla 1.5, you could make a client a manager, but they would be able to edit any component, any content on the site, and make changes to menus. With Joomla 1.6 and higher, you can refine ACL so a client can access only specific categories of articles (or specific articles), specific components (or none at all), and so forth. Via ACL, you can improve backend administrator usability for your client.

ACL in Joomla 1.5

Joomla 1.5 has a limited and fixed ACL system. If you’ve worked with Joomla 1.5, you’ve seen how you can set a menu item or article to be viewable by the public, registered users, or “special” (authors and above). Likewise, you probably know that registered users can’t log into the back end of a Joomla site, but a super administrator can. Joomla 1.5 ACL is hierarchical, meaning that each user group inherits permissions from the groups below it.

A full explanation of Joomla 1.5’s groups can be found at brian.teeman.net. Groups include public, registered, author, editor, publisher, manager, administrator, and super administrator.

Joomla 1.5’s access levels include public, registered, and special. Public indicates that anyone can see the content. Registered indicates that those with registered user access and higher can see the content. Special is for Author groups and higher only. There is no way to add additional access levels, nor is there any way to segment audiences more finely.

ACL in Joomla 1.6 and higher: Overview

Joomla 1.6+ ACL is not necessarily hierarchical. You can set up groups with whatever permissions you wish. These permissions are inherited from parents in the case of groups, but they are not inherited in the case of access levels. At a minimum, all user groups are children of the Public group.

There are four aspects to the ACL system in Joomla 1.6+. These include the user, the group, core permissions, and access levels. I’ve represented these in the following diagram to describe their relationship, and I’ll go through each in detail.

User

This is the easiest one to understand — that’s you, or someone else visiting the website. A user does not have to have an account to be considered a user of the website. That user would still be considered a public user. Individual users may be assigned to one or several groups. You cannot assign core permissions directly to users; these are assigned to the group.

Core Permissions

Core permissions are assigned to the group, not to individual users. (If you want specific core permissions for a single user, you would need to create a group for that single user.)

Core permissions include:

• Site login: the ability to log into the front of the website.

• Admin login: the ability to log into the back end of the website.
• Offline access: When the site is taken offline (in Global Configuration – Site tab), this controls who is able to log in to see the site
• Super Admin: administrative (root) privileges, such as changing Global Configuration. Super Admin privileges also override any other ACL settings, giving this user group full access to all of Joomla’s systems.
• Access Component: ability to get to specific areas in the back end (think menus, article manager, media manager, components, etc)

• Create: ability to create new content

• Delete: ability to delete (trash) content
• Edit: ability to edit existing content which is not necessarily your own

• Edit state: ability to change state between published, unpublished, trashed, archived
• Edit own: ability to edit your own content (but not the content of others)

The core permissions are set in the Global Configuration, under Site – Global Configuration, then clicking on the Permissions tab.

Understanding Core Permissions in Global Configuration

In the Manager group shown above, and in all other groups except for Public, each one of the dropdowns shown here has three options: Allow, Deny, and Inherited. The Public group is the parent for all groups underneath. The Public group’s dropdowns has three values, which include Allow, Deny, and Not Set.

• Allow means something is explicitly allowed or permitted for a specific group.
• Deny means something is explicitly denied or not permitted for a specific group.
• Inherited means something is derived from a parent group. Inherited is not available as an option for the Public group.
• Not Set means the permission has not yet been configured. Not Set is only available to the Public group and only in the Global Configuration.

A full explanation of each user group’s permissions is explained below.

Special Note about Core Permissions Assigned in Global Configuration

When core permissions are set at the Global Configuration level, they carry through the entire site and through all areas of the site. For example, an Author has the Create permission assigned globally. That author may create an article in any category on the website. The Create permission also means they could create a new weblink from the front end of the website, if the weblink component is in use. You may want to think carefully about where permissions are assigned within Joomla. You do not have to set the Create permission in Global Configuration if you want a user group to be able to create articles and categories. You could also assign this permission within the Options in the Article Manager. I will go more in depth about where to assign permissions in later articles.

All About Deny

You might be tempted to set all of these dropdowns to specifically say Allow or Deny so it’s easier to read.

However, I would strongly encourage you NOT to do that.

If Deny is set in the permissions, even if you set an Allow for a higher level user group, the lower level Deny would be inherited and would override the Allow.

For example, if you set the Public group dropdowns to Deny for all, there’s no point in having any higher level groups! Everyone would be denied from doing anything on the website forever with the exception of the Super Users.

User Group

A user group (also called groups) is a group of users who share the same permissions. Using the Joomla 1.5 groups as an example, the publisher group has the right to log into the front of the website, create new articles, edit any articles on the site, and publish or unpublish articles. Anyone in the publisher group has the same permissions to do these same things.

Unlike Joomla 1.5, however, a user may be assigned to multiple groups. A user may be in the publisher group as well as the administrator group, for example.

You can create your own groups and assign them their own set of core permissions. Core permissions are inherited between groups.

A group might be created for two different reasons. One would be to view content on the front end of the website. (User groups are assigned to access levels to see content on the front end of the website.) The other would be to specify what content can be created, edited, deleted, published or unpublished, or managed by that group.

By visiting the website, a site visitor is considered a user belonging to the public group.

The public group may not be deleted, but all other groups may be deleted. (However, I’d recommend you keep them, because they give you a good model of how permissions inheritance works.)

The Default Groups

By default, Joomla 1.6 and higher comes configured with the same groups as appear in Joomla 1.5. The groups and their core permissions are as follows (consider singing along to “The 12 Days of Christmas” while reading):

• Public: Public can see the content on the front end of the website that is not hidden behind a login. For the Public group, by default, all values are set to Not Set. As you might expect, Public users are not allowed to log into the front end of the website, among other permissions. They are not explicitly denied from doing this, however — they are denied because there is no permission explicitly set.
• Registered: Registered users can log into the front end of the website only. Registered users are children of the Public group. They are assigned the Site Login permission.
• Author: Authors can create their own content via the Create and Edit Own permissions. Authors are children of the Registered group. They inherit the Site Login permission from Registered users.
• Editor: Editors can edit any content on the site via the Edit permission. Editors are children of the Author group. They also inherit the Create and Edit Own permissions from Authors and the Site Login permission from Registered users.
• Publisher: Publishers may publish, unpublish, archive or trash content via the Edit State permission. Publishers are children of the Editor group. They also inherit the Edit permission from Editors, the Create and Edit Own permissions from Authors, and the Site Login permission from Registered users.
• Manager: Managers are children of the Public group, so all permissions previously assigned to Registered, Author, Editor, and Publisher groups do not apply to Managers. They must all be reassigned individually. That includes Site Login, Admin Login, Offline Access, Create, Delete, Edit, Edit State, and Edit Own.
• Administrator: Administrators are able to edit and configure extensions via the Access Component permission. Administrators are children of the Manager group, so they inherit the Site Login, Admin Login, Offline Access, Create, Delete, Edit, Edit State, and Edit Own permissions from them.
• Super Users: Super Users (formerly Super Administrators) are able to change Global Configuration as well as other abilities via the Super Admin permission. Super Users are also children of Public. However, they have only one permission set: the Super Admin permission. This permission overrides all others, so the super user is able to perform all functions.

The default groups and their permissions are represented in the Global Configuration (under Site – Global Configuration – Permissions).

Access Level

Access levels refer to who can see what content on the front end of the website. Essentially, this amounts to read permissions on the front end of the website.

Historically, there have been three access levels: public (which anyone can see), registered (you must be logged in to see the content), or special (you must be a logged in author or higher level group to see the content).

These access levels are still present in 1.6+ as default settings, but you can also create your own access levels.

Access levels do not inherit their permissions. If an article is set to be viewable by publishers only via a custom access level, even super administrators cannot view that article. You must assign super users to also be part of the publisher group in order to view this article on the front end of the website, or you must assign super users and publishers to the same access level to see the content.. (In all cases, as a super user, you are able to edit this article on the back end.)

What’s next?

I will be writing a series of case studies that you can follow for putting the above principles into action. The examples will include:

• Different users seeing different content from the front end of the website
• A stripped down back end for simplifying a client’s administration of their site