Note:Please note that much of the information in this document is out of date.
This is a pre alpha document Joomla! version 1.6 that shows early concepts not all of which are implemented in 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.
Sections are used to group rules, actions, assets and assetgroups for each extension using the table jos_access_sections. This allows us to have completely separate ACL systems for different extensions.
These are users stored in jos_users table. Please note that gid and usertype fields are only there for legacy purposes and are not used in the current ACL system. Users can be mapped to rules via jos_user_rule_map table. In phpGACL, users were called AROs (Access Request Object).
These are user groups that are held in table jos_usergroups. You can have nested user groups. Each group obviously can hold an unlimited number of users and each user can be assigned to an unlimited number of user groups. These relations are held in the table jos_user_usergroup_map. User groups can be mapped to rules via the jos_usergroup_rule_map table.
Actions are things your users will perform such as logging in to backend.
Assets are items that you need to set access control on. For example each article on your site can be an asset and you can set edit permission for them. Currently these are not used in core.
These are used for creating different view permissions for a combination of usergroups. (???) How this is achieved:
Rules are combinations of actions and usergroups (or users) and optionally assets. There are three types of rules:
There are three access levels in core by default: Public, Registered, Special. These are access levels. For them we use the action core.view. Let's use Special for our example: First of all there is an asset group named Special. We need to tie some user groups to it and selecting Manager is enough. Because the system will automatically include its child groups (being Administrator and Super Administrator by default) The rule needed for this level is core.view.3. As you remember naming convention is action_name.asset_group_id and here our id is 3.
It seems that this diagram has been deprecated in favor of much simpler structure.
-- Matias 7-Mar-2010