Joomla Users, Groups, Access Levels and ACL

Users → Manage lists the accounts of the site. The list can be filtered by state (enabled or blocked), active or not (activation), group, last-visit range and registration range, and searched by name, username or email. Prefixing the search with id: finds one user by id. The columns show the name, username, enabled and activated state, the assigned groups, the email address, the last visit date, the registration date and the id.

The toolbar of the list has New, Actions (Activate, Block, Unblock, Delete, and Batch), and Options. Blocking an account is the recommended way to disable a person: the User Guide advises blocking rather than deleting, because a deleted account removes the group mappings in #__user_usergroup_map and the user’s private messages, while content the user created keeps the old user id as its author.

The Batch dialog can add users to a group, delete them from a group, set them to a single group, and require a password reset at next login. Use it for bulk onboarding of a club season: select the 40 renewed members and add them to Registered, or require a reset after a suspected credential leak.

The user edit form (Users → Manage → New or the user’s name) has these tabs:

The Assigned User Groups tab has a rule that matters for delegation: an Administrator cannot make anyone, including themselves, a Super User. Only a Super User can create or promote Super Users. The User Guide’s page on changing a user’s group also notes that, thanks to inheritance, you normally need to assign only the single group carrying the most privileges the person needs.

Source: Joomla User Guide: Changing User’s Groups

Source: Joomla Manual: User

A fresh Joomla installation creates nine groups. They form a tree: a child group inherits everything granted to its parent, and a user in a child group counts as a member of all of its ancestor groups for both viewing and permissions.

Two details trip people up. First, Guest is a real group (id 9) that exists only for the Guest access level, and Super Users hangs directly under Public, so Super Users are not "Administrators plus more" in the tree: their power comes from the core.admin permission, not from inheritance. Second, Author, Editor and Publisher are front-end roles. They do not have Administrator Login, so they work through the front-end article edit forms. Manager and Administrator can use both the front end and the back end.

The groups are ids because the stored rules refer to them by number. The ids above are those created by the installer; a site that has deleted or recreated groups has different numbers, so always read them from Users → Groups.

Source: Joomla User Guide: Access Control

Inheritance has three consequences:

Users: Groups (Users → Groups) lists the groups with their member counts and a Users in group link. A group has only a Group Title and a Group Parent. Changing a group’s parent moves its subtree and changes the effective permissions of every member immediately. A user left without any group is treated as a member of Public. Deleting or reparenting the nine core groups breaks the assumptions of the default rules and of extensions, so create new groups instead.

When creating a custom group choose the parent that already has most of the permissions you want, and add only the difference. The Tallpine Trail Warden group is a child of Registered: a warden is a member who can additionally read the trail conditions area and edit the warden-notes field on trail reports, but who should not publish news.

Source: Joomla User Guide: Access Control

The id 10 is what a fresh Tallpine installation receives; a site with other custom groups gets another number.

A viewing access level is a named set of groups. Every article, category, module, menu item, contact, banner, custom field and similar item has an Access field that stores the id of one level. A user may view the item when any of the user’s groups, own or inherited, appears in that level. The Manual’s worked example: a user in groups A, C and D can see an item whose level lists A, D and E, because A and D match, and cannot see an item whose level lists only E.

The order in which the levels appear in the Access list is set by the Ordering column of Users → Access Levels, not alphabetically. The ids shown are those the installer creates; and the installer creates the levels with ids 1, 2, 3, 5 and 6.

Because groups are inherited, a level that lists Registered is also visible to Author, Editor and Publisher, and a level listing Manager is visible to Administrators. A level can also contain an individual user: the stored rule list may hold a negative number that is the negated user id. The screens do not offer this, but the resolution code honours it.

The ticks matter. A level contains exactly the groups you tick; being a descendant of a ticked group counts, being an ancestor does not. Because Trail Warden is a child of Registered, a warden also passes the Registered level. If you tick only Trail Warden, then a plain Registered member, an Author and an Editor will not see the trail conditions. Add the groups that should see them too, for example Publisher or Editor.

Super Users do not need to be ticked. The level calculation grants every level to a user whose groups hold core.admin at the global level.

A visitor who has not logged in has user id 0 and is assigned the group chosen in Users: Options → Guest User Group. If the option is empty the code falls back to Public. This is the reason the Guest level works only when that option points to the Guest group. If it points to Public, a visitor sees Public items and no Guest items; if it points to Registered (a configuration mistake seen in migrated sites), anonymous visitors see members-only content. Check this option first when the login menu item is missing for visitors or when content appears for people who have not logged in.

The User Guide’s guest access page sets a Login Form menu item to Guest so it disappears after login, and a Logout item to Registered so it appears only after login.

Source: Joomla User Guide: Guest Access

Source: Joomla Manual: ACL access

In a database query use the same list instead of testing items one by one:

Source: Joomla Manual: ACL access

When the user may not see a single requested item, the convention is HTTP 403: a logged-in user gets 403, and a guest gets either 403 or a redirect to the login page with a message. A page of an extension that forgets the check leaks content even though its menu item is hidden, because hiding a menu item does not protect the URL behind it.

Permissions are named with the core. prefix. The list a site shows depends on the component, because each component declares its own in access.xml. The global list is:

core.login.api was added with the Web Services API in 4.0, and core.execute.transition with workflows in 4.0. The login actions exist only at the global level. The component-specific ones, such as core.create for Contacts, appear on the component’s own Permissions tab; categories, field groups and fields get a smaller set (for com_users: create, delete, edit, edit state and edit own on categories; the same plus edit value on field groups; delete, edit, edit state and edit value on fields).

core.edit.own does not check ownership by itself. It tells the code that the user may edit their own items, and the component must still compare the item’s created_by with the user id. The Manual’s pattern is:

Source: Joomla Manual: ACL access

Every permission lives on an asset, and assets form a tree stored in #__assets as a nested set:

Source: Joomla Manual: ACL permissions

For core content the chain is root.1, com_content, the category (and its parent categories), then com_content.article.22. Each level offers the same table of groups and actions and starts from what the level above decided.

The item-level tab appears only after the item has been saved once, because a new item has no asset yet. The tab shows "Please save before changing permissions" until then. Core modules, menu items and plugins have their own assets for the same reason.

Each asset row has a rules column holding JSON. A key is an action, a nested key is a group id, and the value is 1 (Allowed) or 0 (Denied). A group with no entry is Inherited. The default com_content rules from the installer grant Administrator (7) core.admin, Manager (6) core.manage, Author (3) core.create, Editor (4) core.edit, Publisher (5) core.edit.state, and Manager and Publisher core.execute.transition. The example below is illustrative and adds a deny.

Source: Joomla Manual: ACL permissions

The last two lines show the two kinds of entry: an allow for Manager and Publisher, and an explicit deny of delete for every Registered member. The format is the one Joomla\CMS\Access\Rules parses and prints: top-level keys are action names, nested keys are group ids (a negative number is a single user), and the nested values are booleans. The root asset root.1 of a new installation carries, for example, core.login.site for Registered (2) and Manager (6), core.login.admin for Manager (6), core.login.api for Super Users (8), core.admin for Super Users (8) and core.manage for Administrator (7).

Inspect the stored rules read-only with SQL:

Source: Joomla Manual: ACL permissions

Do not edit rules by hand on a production site. The asset tree uses nested-set columns (lft, rgt) that must stay consistent, and the permission screens recalculate and save them correctly. Reading is safe.

When you open a Permissions tab, the form shows one row per action and one column per level of the tree below it. For each group the row shows a Select New Setting list and, next to it, the Calculated Setting.

The list offers three values:

The Calculated Setting column shows the final result for that group on that asset:

The rules the calculator follows are:

The source of Rule::allow() confirms the order: it walks the identities, remembers a true, and returns false at the first explicit false; if nothing matched it returns null, which Access::check() treats as a denial. The method Access::getAssetRules($assetKey, true, true) merges the rules of the asset with its ancestors, and Access::getGroupsByUser($userId, true) supplies the identity list, adding every ancestor group through the nested-set lft and rgt bounds.

Reading the explicit deny rule in practice: an Allowed on the item for Editor does not help an Editor who also belongs to a group with a Denied on the component. The way out is never to override at the item; it is to remove or move the deny.

A worked example in the Tallpine site, for core.edit.state and a user who is both a Trail Warden and a Publisher:

Source: Joomla Manual: ACL permissions

Changing a permission saves immediately through an AJAX request when the item already exists, which is why the screen asks you to save the item first. Two notices appear: when a group with children is changed the screen asks you to save or reload to recalculate the child groups; when the Super User setting changes it asks to reload to recalculate that group. If a permission seems to have no effect after changing it, reload the screen and clear the Joomla cache (see Caching and performance) before debugging further, because page caches can serve content generated for another user group.

A Super User is a user in a group that has Super User (core.admin) allowed at the global level. By default that group is Super Users, but it can be any group. It has these consequences:

The special root_user setting in configuration.php can name a user who is treated as a super user in the view level computation even before groups are evaluated. It is intended for recovery and should be left empty in normal operation (see configuration.php and .htaccess).

Source: Joomla Manual: User

getAuthorisedGroups() returns the ids of the groups, getAuthorisedViewLevels() the ids of the levels. Mixing them is a frequent bug, and the Manual points out that some core code names the level array $groups, which is misleading.

To open registration for Tallpine members: Users → Manage → Options, set Allow User Registration to Yes, check that New User Registration Group is Registered, choose Self or Administrator activation, save, then expose the form with a menu item of type Users → Registration Form or add the Login module with its registration link.

The registration form collects name, login name, password and email. The User - Profile plugin adds address and telephone fields, each of which can be disabled separately for registration and for the profile form; the Edit Profile menu item (type Users → Edit User Profile) must have access Registered. Activation emails use the mail templates.

Source: Joomla User Guide: User Registration and Joomla User Guide: User Profile