Joomla user groups and access levels: how they resolve

Joomla calls this whole area ACL, for access control list, and it is really two systems that people mix up constantly. User groups decide what someone can do. Viewing access levels decide what they can see. Learn which one you are looking at and most permission confusion evaporates. What remains is one rule that catches everybody: a Denied setting wins over everything below it. If you have ever set a permission to Allowed and watched it do nothing at all, that rule is why.

Every default on this page was read out of the Joomla 6.1.2 release source rather than copied from other tutorials, which is why the group nesting below differs from most guides you will find. The safest place to try any of it is a site you can afford to wreck, so you can open a free Joomla test site and follow along.

What is the difference between a user group and an access level in Joomla?

Groups are about actions, access levels are about visibility. Joomla’s Programmers Manual draws the line in two sentences: access “relates to what users can view” while permissions “relate to what users can do” (Joomla Programmers Manual, ACL). You put a user in a group to let them edit articles. You put an access level on an article to control who sees it.

The two systems also use opposite logic, which is the deeper reason they get confused. Access levels are additive: belong to any group attached to a level and you see that content, and Joomla offers no way to deny a view. Permissions run the other way, with a veto that beats everything. One system says yes if anything says yes. The other says no if anything says no.

The nine default Joomla user groups

A fresh install ships nine, arranged in four separate branches under Public rather than one ladder. That shape is the detail most tutorials get wrong. The rows below come from the #__usergroupstable in the installer’s own SQL (Joomla CMS 6.1.2, installation/sql/mysql/base.sql):

Read that parent column carefully. Manager is not under Registered, and Super Users is a direct child of Public, not the top of the Author-Editor-Publisher chain. The third column is not folklore either: the installer writes those exact rules onto the root asset in the same SQL file, which is what makes a fresh site behave the way it does.

What access levels does Joomla come with?

Five, not four. Older guides say four because they predate Joomla 4. The #__viewlevels rows in that installer SQL give each level a specific set of groups:

• Public maps to the Public group, so everyone.
• Guest maps to Guest, so only visitors who are not logged in.
• Registered maps to Manager, Registered, and Super Users. Editor and Publisher get it too, but only by inheriting through Author and Registered rather than by being listed.
• Special maps to Manager, Author, and Super Users.
• Super Users maps to Super Users alone.

Two traps fall out of that mapping. First, Special is not “any logged-in user”. It skips Registered entirely, so an ordinary registered member cannot see Special content while an Author can. Second, the Guest level only works while your Guest User Group is still set to Guest. Repoint that setting to Public in Users, then Options, and nobody can see content you restricted to Guest (Joomla User Manual, Guest Access). Both traps are quicker to see than to reason about, which is what a practice Joomla site is for.

How do Joomla permissions resolve?

Along two axes at once, with one rule that wins on both. Permissions inherit down the asset chain, from Global Configuration to a component’s Options, then to a category, then to an individual item. They also inherit down the group tree, from a parent group to its children. A single Denied anywhere in either direction ends the discussion (Joomla Programmers Manual, “ACL Permissions”).

Each setting in a Permissions tab is one of three states:

1. Inherited, which Joomla shows as Not Set. No rule lives here, so the answer comes from the level above. It blocks for now, but you can still change it lower down, and that reversibility is the only thing separating it from Denied.
2. Allowed. Grants the action, unless a Denied sits above it or in any other group the user belongs to, in which case it silently does nothing at all.
3. Denied. Absolute.

Joomla states this itself, in the note above every Permissions tab: “Denied will overrule any inherited setting and also the setting in any child group, component or content. In the case of a setting conflict, Deny will take precedence. Not Set is equivalent to Denied but can be changed in child groups, components and content” (Joomla CMS 6.1.2, lib_joomla.ini).

The code is blunter still. In Joomla 6.1.2 the access rule evaluator comments “An explicit deny wins” and stops looping the moment it finds one, while its merge routine notes “Explicit deny always wins a merge,” so a deny recorded against a group cannot be overwritten by a later rule from a lower asset (Joomla CMS 6.1.2, libraries/src/Access/Rule.php). That is also why a user in two groups gets the worse of the two.

What does Not Allowed (Locked) mean?

It means the deny lives somewhere you are not currently looking. Joomla shows Not Allowed (Locked)with a padlock in the Calculated Setting column when the action is explicitly Denied either for the same group on the parent asset, or for this group’s parent group on this asset (Joomla CMS 6.1.2, layouts/joomla/form/field/rules.php). Whatever you pick in the dropdown beside it, the answer stays no. Go up to the level holding the Denied and change it there.

Trust that Calculated Setting column over your own reading of the dropdowns, with one caveat: it is stale until you save. Joomla says so directly, queuing “Save or reload to recalculate the child groups permissions” after you change a group that has children. The neighbouring labels each tell you something different too. Not Allowed (Inherited) means your Allowed here lost to a conflict higher up. Not Allowed (Default) means no rule exists anywhere. Allowed (Super User) means the group holds the Super User permission and the check is moot.

The 13 permission actions in Global Configuration

Joomla 6 offers thirteen actions at global level, which is more than most guides show. In the order Joomla renders them (Joomla CMS 6.1.2, com_config/forms/application.xml): Site Login, Administrator Login, Web Services Login, Offline Access, Super User, Configure Options, Access Administration Interface, Create, Delete, Edit, Edit State, Edit Own, and Edit Custom Field Value.

Two of those trip people up. Configure Options and Edit Custom Field Valueship with no rule at all on the root asset, so they read as Not Allowed (Default) for every group except Super Users until you set them. And the Super User action answers to two names depending on where you meet it: Joomla labels it “Super User” in Global Configuration but “Configure ACL & Options” inside a component’s Options (Joomla CMS 6.1.2, joomla.ini). One permission, two labels. If a stack difference might be muddying your results, our notes on Joomla system requirements cover what a current install expects.

How do you restrict one category to one group?

This is the job most people actually came for, and it needs both systems at once: a group to put people in, an access level to hang off that group, and then the category set to that level. Four steps:

1. In Users, then Groups, create your group. Pick its parent deliberately, because it inherits everything that parent can do.
2. In Users, then Access Levels, create a level and tick your new group. Tick Super Users too unless you enjoy locking yourself out of your own content.
3. Set the category’s Access field to your new level.
4. If those users also need to edit in there, use the category’s own Permissions tab, which is a separate question from Access and easy to forget.

One thing to know before you go hunting for a bug that is not there: access levels apply to modules and menu items as well as articles and categories (Joomla Programmers Manual, “ACL Access”). So if someone can reach an article by URL but cannot see the menu item pointing at it, the menu item has its own Access field and that is usually what is blocking them. The same applies to a module that quietly vanishes for half your users. Testing this properly means logging in as somebody other than yourself, which is another reason to do it on a disposable site of the kind you would use for extension testing rather than on production.

What stops you locking yourself out?

Less than you would hope. Joomla guards the Users screen well: it refuses to let you strip your own Super User rights, with the error “You can’t remove your own Super User permissions,” and it discards group changes to your own account if you are not a Super User, warning “You can’t edit your own user groups” (Joomla CMS 6.1.2, com_users.ini). It will not let you block or delete yourself either (Joomla CMS 6.1.2, UserModel.php), and the User Manual walks through changing a user’s groups safely.

None of that covers Global Configuration. Nothing stops you setting Denied on Administrator Login for the Public group.

That is the whole lockout in one dropdown. Every group descends from Public, and a Denied cannot be overridden below it, so the back end closes for everybody at once. Super Users survive only because the Super User permission short-circuits the check, not because the group tree protects them.

On a real site the recovery hatch still exists in Joomla 6.1: add a root_user line naming your user id or username to configuration.php and Joomla treats you as root again (Joomla CMS 6.1.2, libraries/src/User/User.php). Note what that needs, though: FTP or file-manager access to the server. Fine on hosting you control, no help at all if you were only experimenting.

Where to practice Joomla permissions safely

On a site you are willing to destroy. Permissions resist learning by reading, because the instructive part is what breaks, and the only way to see what breaks is to break it. A disposable test site hands you a real Joomla with Super User rights, so every screen behaves exactly as it would on production, and the consequences expire on a timer instead of landing on a client.

1. Open a test site on Joomla 6.1 or Joomla 5.4. It only needs an email.
2. Add a group under Registered and look at what it already inherits before you change a single setting. That baseline is what most permission surprises are measured against.
3. Create an access level, attach your group, and put an article behind it.
4. Make a second user in that group, then open the front end in a private window and confirm they see what you intended and nothing more.
5. Now the instructive bit. Set Denied on something for a parent group, save, and watch Not Allowed (Locked) appear further down the tree.
6. Try to undo it with an Allowed at category or article level. It will not work, and watching that fail once teaches the rule better than any table can.
7. Walk away. The site deletes itself after 4 hours, so a locked-out back end costs nothing.

A throwaway install suits any change that is awkward to reverse, which is why the same trick works for installing sample data or testing an update.

Conclusion

Joomla’s ACL stops being confusing once you hold three facts at once. Groups govern what people can do and access levels govern what they can see, running on opposite logic. The defaults are nine groups in four branches off Public, and five access levels rather than the four that older guides describe. And Denied is final: it beats an inherited setting, a child group, a category, and an item alike, which makes an Allowed further down pure decoration.

Once that lands, the Calculated Setting column turns into the fastest debugging tool in the admin. Getting there takes experimenting, and experimenting on production is how people lock out their own colleagues. Spin up a throwaway Joomla site to practice on, set a Denied deliberately, see what it takes down with it, and let the evidence expire in four hours. If you would rather weigh up the ways of getting a scratch install first, our comparison of the four options covers them.

Frequently asked questions