ACL stands for access control levels. It refers to who has permission to do what on the website, including read, create, edit, delete, or log in, among other permissions.

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?

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 and modules.

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 company intranet, where some managers see one level of content, while employees see another

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

A site with multiple blogs, where authors can't create or edit posts in each other's blogs, and trust can't or won't work

ACL in Joomla 1.0

ACL in the Joomla 1.0 was very entry level, you had no real ways to tweak the permissions a user have beside placing it in one of the per-established user groups and associate viewing rights to different parts of the website (content items, menu items) to be viewable by the public, registered users, or special(authors and above).

ACL in Joomla 1.5

Joomla 1.5 has his own ACL also at a limited level, even if evolved since the previous version. 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.

ACL in Joomla 1.7

Overview

Joomla 1.7 ACL is not 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.

There are four aspects to the ACL system in Joomla 1.7. 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.)

Edit: ability to edit existing content which is not necessarily your own

Edit state: ability to change state between published, unpublished, trash

The core permissions are set in the Global Configuration, under Site - Global Configuration, then clicking on the Permissions tab. I'll go through understanding this chart in my second article on ACL.

Group

A group 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. 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 and the registered 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.)

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.7 as default settings, but you can also create your own access levels.

Access levels do not inherit their permissions. If you have an article, and you set it to be viewable by publishers only, even super administrators cannot view that article. You must be assigned to the publisher group in order to view this article. (However, as a super administrator, you are able to edit this article on the back end.)