This is the easiest one to understand — that&apos;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 user groups. You cannot assign core permissions directly to users; these are assigned to the user group.

Core permissions are assigned to the user group, not to individual users. (If you want specific core permissions for a single user, you would need to create a user 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. Super Admin: access over the whole site, regardless of any other permissions settings Access Component: ability to change anything on the back end, except Global Configuration 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, trash Edit own: ability to edit the state (published, unpublished, trash) of any content the user group owns

A user group is a group of users who share the same permissions. Using the Joomla 1.5 user groups as an example, the publisher user 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 user group has the same permissions to do these same things. Unlike Joomla 1.5, however, a user may be assigned to multiple user groups. A user may be in the publisher user group as well as the administrator user group, for example. You can create your own user groups and assign them their own set of core permissions. Core permissions are inherited between user groups. A user 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 user group. By visiting the website, a site visitor is considered a user belonging to the public user group. The public user group and the registered user group may not be deleted, but all other user groups may be deleted. (However, I&apos;d recommend you keep them, because they give you a good model of how permissions inheritance works.)

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 user 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 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 user group in order to view this article. (However, as a super administrator, you are able to edit this article on the back end.)

3.
What is ACL? <ul><li>Most people think of “who sees what” </li></ul><ul><li>It’s also who creates, edits, and configures what </li></ul><ul><li>Joomla separates viewing from all other permissions in a separate system (access levels) </li></ul>

4.
Just because you can… <ul><li>ACL is NOT for newbies </li></ul><ul><li>ACL gets very complicated very quickly </li></ul><ul><li>There is nothing wrong with using the default settings, which approximate Joomla 1.5 ACL </li></ul>

5.
If the implementation is hard to explain, it's a bad idea. The Zen of Python

6.
Joomla 1.5 ACL: Review <ul><li>7 user groups , plus public. Groups cannot be expanded </li></ul><ul><li>Any user in any group can do anything the group can do </li></ul><ul><li>Groups are hierarchical: inherit permissions </li></ul><ul><li>3 access levels: Public, Registered, Special </li></ul>

7.
Joomla 1.7 ACL <ul><li>7 user groups by default, add as many more as you wish </li></ul><ul><li>Any user in any group can do anything the group can do </li></ul><ul><li>Groups are not hierarchical: they inherit permissions, but they can be set with whatever permissions you want </li></ul><ul><li>3 access levels by default, can add more. Permissions NOT inherited </li></ul>

15.
Access Levels (Users – Access Levels – Add New Access Level) <ul><li>Access levels do NOT inherit permissions from other groups </li></ul><ul><li>Possible for SU to not see certain content on front end </li></ul>

17.
Planning for ACL <ul><li>Describe the problem you are trying to solve. Example… </li></ul><ul><ul><li>The general public can visit that site and see most content. However, there is content behind the scenes for students and teachers. </li></ul></ul><ul><ul><li>A teacher can see content specifically for teachers, all student content, and the public content. </li></ul></ul><ul><ul><li>Students can only see student content (not teacher content) and the public content. </li></ul></ul>

18.
Planning for ACL <ul><li>Is your problem a reading problem? Or does it have to do with creating/editing/deleting content? Or both? </li></ul><ul><ul><li>If it’s a reading problem, you need to think about access levels. </li></ul></ul><ul><ul><li>If it’s an editing problem, you might not need to think about access levels at all. </li></ul></ul>

19.
Planning for ACL <ul><li>Think about maintenance. </li></ul><ul><ul><li>It’s easier to allow all content within a category be editable or readable by a group, rather than setting individual articles. </li></ul></ul>

20.
Planning for ACL <ul><li>Think about inheritance. </li></ul><ul><ul><li>Do users belong to more than one user group? If so, how does that affect their permission to do things? </li></ul></ul><ul><ul><ul><li>User group permissions ARE inherited </li></ul></ul></ul><ul><ul><ul><li>Access levels are NOT inherited </li></ul></ul></ul>