Users and User Groups in Joomla

1. The Basics

1.1 Why Users Matter

Without proper user management, every visitor sees the same website. There is no way to restrict admin access, no way to protect content, no membership area, and no separation between editors and visitors. Security incidents tend to follow quickly.

With Joomla's user system, you can run public, members-only, and staff-only content side by side. You can hand specific tasks to specific people, you can offer self-service registration and password reset, and you can enable multi-factor authentication.

1.2 The Three Pillars

Joomla splits user management into three independent building blocks. Understanding these three pillars is the key to the whole system:

The rest of this article is about how these three pillars combine.

1.3 Where Do I Find Users?

In the Joomla 6 backend, the user system is managed under the Users menu:

Users → Manage          (all user accounts)
Users → Groups          (user groups)
Users → Access Levels   (viewing access levels)
Users → Fields          (custom profile fields)
Users → User Notes      (internal notes per user)

Permissions live in a separate place: the Permissions tab inside Global Configuration, inside each component's Options, and inside categories and items.

3. User Groups

3.1 What is a User Group?

A user group is a labelled bucket of users. The group on its own carries no permissions. Permissions are assigned to the group later, through the ACL.

Three rules to remember:

• A user can belong to multiple groups at the same time.
• Groups can be nested in a parent-child tree.
• A child group inherits its parent's permissions, unless you override them.

The group is the single most important ACL concept. Get groups right, and the rest of the system falls into place.

3.2 The Default Groups in Joomla 6

Out of the box, Joomla ships with this group tree:

Public
 ├── Guest
 ├── Manager
 │    └── Administrator
 ├── Registered
 │    └── Author
 │         └── Editor
 │              └── Publisher
 └── Super Users

Each group serves a specific role:

• Public: every visitor, logged in or not.
• Guest: explicitly not logged in.
• Registered: any logged-in frontend user.
• Author, Editor, Publisher: increasing content rights on the frontend.
• Manager, Administrator: backend access with increasing privilege.
• Super Users: unrestricted, can do anything anywhere.

3.3 Inheritance in Practice

A group inherits permissions, not users. This is a common point of confusion. An example:

• Adding a user to Editor does not automatically add them to Author.
• But the Editor group inherits Author's permissions, so an Editor can do everything an Author can.
• If you set "Delete" to Denied on Editor, the inheritance breaks for that one action.

In short: inheritance flows down the group tree, but user assignments are leaf assignments only.

3.4 Creating a Custom Group

Go to Users → Groups → New. Only two fields are required:

The parent choice decides which permissions you start with. Pick the closest match, so you have fewer things to override later.

Common real-world custom groups:

• Members (parent: Registered): paying members of a community.
• Moderators (parent: Editor): forum or comment moderation.
• Site Admins (parent: Administrator): backend access without Super User rights.

3.5 Many-to-Many in Action

A single user can sit in several groups at the same time. Example: Jane is a Newsroom Editor on the content side and a Forum Moderator.

• Open Users → Manage → Jane → Assigned User Groups.
• Tick both groups.
• Jane now gets the union of the two groups' permissions.

If one group Allows an action and another group does not, Allow wins, unless a third group explicitly Denies the same action. The "Deny always wins" rule is what makes this combination safe.

5. Permissions (ACL)

5.1 From Visibility to Action

Access levels decide who can see. Permissions decide who can do. The Joomla ACL answers questions like:

• May this group create articles?
• May they edit only their own articles, or any article?
• May they publish?
• May they delete articles inside a specific category?
• May they log in to the backend at all?

5.2 The Standard Action Set

Most components expose the same set of actions. Some add their own on top:

5.3 The Four Permission States

For every combination of action and group, you pick one of these states:

After saving, Joomla shows the calculated result next to your setting: Allowed, Not Allowed, or the dreaded Not Allowed (Locked).

5.4 The Permission Hierarchy

Permissions cascade through four levels, each able to override the one above:

Global Configuration
 └── Component Options (for example com_content)
       └── Category permissions
             └── Item permissions (per article)

The practical approach is:

• Set a baseline at Global Configuration.
• Tighten or loosen per component.
• Override per category for sections like "Press Releases - staff only".
• Use the item level only as a last resort.

5.5 The Deny Trap

The most important ACL rule in Joomla is short: Deny always wins.

If a group is Denied at Global Configuration, no Allow further down can rescue it. The lower levels will literally show Not Allowed (Locked) and grey out the dropdown.

Practical guidelines:

1. Default to Inherited everywhere.
2. Use Allowed to grant rights downward.
3. Use Denied only when you want the rule to be permanent and absolute, usually at the Global level for safety.
4. If you lose a permission and cannot figure out why, walk up the tree looking for a Deny.

5.6 Global Configuration: Permissions Tab

Open System → Global Configuration → Permissions. This sets the default for the entire site. A typical baseline looks like this:

Get this layer right, and about 80% of ACL "weirdness" disappears.

5.7 Component-level Permissions

Every component has an Options button in the toolbar with its own Permissions tab. For com_content (Articles) you can, for example:

• Tighten Create so only Authors and above can write articles.
• Allow Edit State for Publishers, but not for Authors and Editors.
• Grant Access Administration Interface to a Newsroom group without making them Manager.

This is where most day-to-day ACL configuration lives.

5.8 Category-level Permissions

Open any category and select the Permissions tab. Here you can fine-tune rights for a specific section:

• Members may Create articles in the Member Stories category.
• Members may Edit Own but not Edit (other people's items).
• Newsroom may Edit State in Press Releases but nowhere else.

Category permissions are the right tool for multi-team editorial workflows. They let you separate newsroom, blog, and member-content teams without ever giving anyone "Edit" globally.

5.9 Item-level Permissions

Every article (and many other items) has its own Permissions tab. Use it sparingly: lock down a single sensitive article, or open one item to a wider group as an exception. If you find yourself overriding permissions on many individual items, the better solution is usually a new category.

5.10 Worked Example: Newsroom Editors

The goal is a Newsroom Editors group that can fully manage the Press Releases category, and nothing else. The steps:

1. Group: create Newsroom Editors with parent Registered.
2. Global Configuration → Permissions: grant Newsroom Editors both Site Login and Administrator Login as Allowed.
3. Articles Options → Permissions: grant Newsroom Editors Access Administration Interface as Allowed. Leave everything else as Inherited.
4. Press Releases category → Permissions: grant Newsroom Editors Create, Edit, Edit State, and Delete as Allowed.
5. All other categories: leave inherited. The newsroom can see other categories, but cannot touch them.

Done. No Super User, no over-privilege.

7. Multi-Factor Authentication and Security

7.1 Native MFA in Joomla 6

Joomla 4 introduced native multi-factor authentication, and Joomla 6 refines it further. The supported methods are:

• TOTP: time-based one-time passwords, used by Google Authenticator and similar apps.
• WebAuthn: passkeys and hardware security keys.
• YubiKey: a hardware token.
• Email OTP: a code sent by email.
• Fixed code: only useful for testing.

Each user can opt in to MFA, or you can enforce it for entire groups through the Captive MFA plugin. Backup codes are generated automatically, and you should always remind users to store them in a safe place.

7.2 The Captive Login Flow

Joomla uses a captive model: a logged-in user without a satisfied MFA requirement is trapped on the MFA setup page until they complete it. They cannot navigate away.

You can configure this under Users → Manage → Options → Multi-factor Authentication. It is a powerful way to enforce an organisational security policy without writing a single line of code.

7.3 Useful User-related Plugins

Several plugins extend Joomla's user system. You can find them under System → Manage → Plugins filtered by User and Authentication:

• User - Joomla: core profile sync, do not disable this one.
• User - Profile: extra profile fields, such as date of birth or terms of service acceptance. You can use Joomla's custom fields in Users for that too.
• User - Contact Creator: automatically creates a Contact entry for every new user. It does NOT synchronize data after the user/contact have been created.
• Authentication - Joomla / LDAP / Cookie: different login methods.
• Multi-factor Authentication - ...: one plugin for each MFA method.

For custom logic, you can write your own User plugin that hooks into events such as onUserBeforeSave, onUserAfterSave, onUserLogin, and onUserLogout.

7.4 Custom Profile Fields

There are two ways to add custom profile data to users:

1. Custom Fields under Users → Fields: a point-and-click way to add text, list, calendar, media, and other field types. Each field can have its own Access level, so only specific groups see it.
2. User Profile plugin: a code-defined approach, ideal for required structured data such as date of birth or terms of service acceptance.

In Joomla 6, Custom Fields are usually the right answer. Reach for the plugin only when you need server-side validation logic.

9. Common Mistakes and Pitfalls

9.1 Deny is Forever

A Deny at Global Configuration cannot be Allowed lower down. The lower levels will show Not Allowed (Locked) and grey out the dropdown. Use Deny only when you want a rule to be absolute.

9.2 Confusing Group Inheritance with User Inheritance

Inheritance applies to permissions, not to users. Adding a user to Editor does not also add them to Author. But the Editor group still inherits Author's rights for each action.

9.3 Over-using Super User

Super User overrides every Deny and every restriction. It is tempting to grant Super User "just to make it work", but it removes all safety nets. Keep the Super Users group to one or two trusted people.

9.4 Forgetting Super Users in a Custom Access Level

When you create a new viewing access level, always include Super Users in the group list. Otherwise you can lock yourself out of content that only your custom group can see.

9.5 Mixing Up Guest and Public

These two look similar but mean different things:

• Public: everyone, logged in or not.
• Guest: explicitly not logged in.

A Public module is shown to all visitors. A Guest module is hidden the moment a user logs in.

9.6 Deleting a User Keeps Their Content

If you delete a user, their articles, contacts, and other items remain in the database with a created_by field pointing to a non-existent user. Reassign authorship first, then delete the account.

9.7 Putting Public Inside Custom Access Levels

If you tick the Public group inside a custom access level, that level becomes equivalent to "Public". Anyone can see the content, which defeats the purpose of the custom level.

9.8 Skipping Rebuild After Direct Database Changes

If you bulk-edit rules directly in #__assets or import users through SQL, you may need to rebuild the asset tree and clear the cache. Otherwise the UI keeps showing stale results.

11. Summary

In Joomla, the user system is much more than a login form. It controls almost every layer of the website:

• Identity: who can log in and how.
• Visibility: which content is shown to whom.
• Authority: who can create, edit, publish, and delete.
• Security: multi-factor authentication and group-based hardening.
• Workflow: editorial teams with clear boundaries.
• Developer integration: a shared API for users, groups, and ACL.
• Compliance: GDPR, audit trails, and access control.

A well-planned user setup makes a Joomla website safe, predictable, and easy to maintain for years. A bad setup leads to security risks, frustrated editors, and ACL puzzles that grow over time.

If you are planning a new Joomla site, migrating from an older version, or trying to clean up a permissions tangle on an existing site, Check the usersgroups, access levels, and permissions first. Use those three pillars correctly, and Joomla works with you instead of against you.