How to Set Up Joomla Access Control for an Editorial Team

The question people actually ask

“This editor needs to fix articles in the backend, but I don’t want them anywhere near Global Configuration.” If you run a Joomla site with more than one person touching content, that request arrives eventually. The temptation is to create a user and tick the Administrator group, because it seems close enough and you have a meeting in ten minutes. Six months later that same account has installed two extensions nobody remembers approving.

Joomla’s Access Control List exists precisely so you never have to make that trade. The system is powerful but it is also the one part of the backend where clicking the wrong checkbox produces no error message — just a permission that does not do what you assumed. This guide covers how the pieces fit together, then walks through the same worked example the official user guide uses: a group that can manage articles in the backend and nothing else.

Before touching permissions, it helps to know what you are protecting. If you are also planning a larger version jump, do the permission work first — it is much easier to verify an upgrade with a clean, documented permission set than with three years of accumulated exceptions. Our Joomla upgrade planning guide covers that sequencing.

Three layers, not one

Joomla ACL answers two separate questions, and confusing them is the root cause of almost every broken setup:

• User groups decide what someone can do — log in to the backend, create articles, edit other people’s work, delete items.
• Access levels decide what someone can see — which articles, modules and menu items are visible to them.
• Permissions are the individual actions (Create, Delete, Edit, Edit State) that you allow or deny per group, at progressively narrower scopes.

The official user guide describes this as controlling “who can see and manipulate content”: groups and access levels handle the seeing, action permissions handle the manipulating. Both have to be right. An editor who belongs to a group with full edit permissions but whose account cannot see the Special access level will have a half-empty backend and file a support ticket about missing articles.

The default groups

A fresh Joomla installation ships with nine groups arranged in a parent-child hierarchy: Public, Guest, Registered, Author, Editor, Publisher, Manager, Administrator and Super Users. Children inherit permissions from their parents, which is what keeps the system manageable — you grant a permission once at Public or Manager and every group below it picks the setting up.

The defaults already cover most content-team roles without any customisation:

• Author can log in to the site frontend and create and edit their own articles. Nothing else.
• Editor can additionally edit anyone’s articles.
• Publisher can edit anything and change published state.
• Manager gets backend login with a mostly content-focused scope.
• Administrator has nearly the whole backend except Global Configuration and Super User management.
• Super Users can do everything, including editing other Super Users.

The gap in this ladder is the one our worked example fills: a backend user who manages articles but sees no site-wide configuration. Manager is broader than that, and Editor has no backend login at all.

Access levels

Every article, module and menu item has an Access dropdown with the default levels: Public, Guest, Registered, Special and Super Users. Public means everyone, Registered requires a login, Special covers everyone above Registered in the group tree, and Super Users is visible to Super Users only. You can create additional levels at Users > Access Levels, and each level is simply a list of groups that may see items assigned to it.

One detail worth internalising: a new access level does nothing until you assign it. The level is the rule; the Access dropdown on the article is where the rule gets applied. Creating “Partners Only” and then forgetting to set it on the article is the classic silent failure — the article stays Public and nobody notices until it ranks in Google.

Where permissions live

Action permissions can be set at four scopes, each overriding the one above:

1. Global Configuration — site-wide defaults per group, including who has Administrator Login and Super User rights.
2. Component options — for example Content > Articles > Options > Permissions, which controls article-specific actions and workflow.
3. Category — overrides for one branch of the content tree.
4. Single item — the narrowest scope; a single article exposes only Delete, Edit and Edit State.

The settings dialog at each scope is the same: a matrix of groups down the side, actions across the top, and a three-state selector — Inherited, Allowed, Denied — per cell. Inherited means “use whatever the parent scope says”, and that is the setting you should leave wherever you can. A permission tree full of explicit overrides is a tree nobody can audit.

Denied is also stronger than people expect: a Denied at a higher scope cannot be un-done by an Allowed further down. If a group is denied Edit at Global Configuration, allowing Edit on a single article will not restore it. Use Denied sparingly, and only when you mean it structurally.

Worked example: a backend editor who cannot break the site

The goal: a user who logs into the administrator backend, sees the Content menus, and can create, edit and publish articles — but has no access to Global Configuration, extensions, templates or users.

Step 1 — create the group. Go to Users > Groups > New. Name it something that describes the job, such as Content Admin. Set the parent group to Public. Parenting under Public rather than Manager matters: inheritance flows downward, so a child of Manager inherits Manager’s backend scope and you would spend the next steps fighting it. A child of Public starts from nothing.

Step 2 — add the group to the Special access level. Edit the Special level at Users > Access Levels and tick your new group. This is what lets the group’s members see backend items — menus, modules and quick icons — that are set to Special rather than Public. Skip this step and the user can log in to an almost empty backend.

Step 3 — grant Administrator Login. In Global Configuration > Permissions, select the Content Admin group and set Administrator Login to Allowed. This is the only change the group needs at global scope; leave everything else Inherited, which resolves to Denied for a child of Public. Save.

Step 4 — open up the Articles component. In Content > Articles > Options > Permissions, select Content Admin and set the article actions to Allowed: Create, Edit, Edit State, and the workflow actions if you use workflows. Leave the two configuration options — Configure Options and, if present, the ACL-only option — at Inherited. Leaving those alone is the whole point: it is what keeps the Options button out of reach for this group.

Step 5 — assign a user. Create the user at Users > New (or edit an existing one), and assign them to Content Admin in the Assigned User Groups tab. The user guide’s walkthrough of assigning users to groups is short and worth a read if you have never done it.

Step 6 — test before you announce it. Log in as that user in a private browser window. You should see the Content menus and the articles list, and little else. Try the things that should fail: browse directly to administrator/index.php?option=com_config and confirm you get a permission error, not the configuration screen. Try to edit another author’s article, to publish, to delete. Ten minutes of this beats a month of “can you just check something” messages.

Habits that keep a permission tree healthy

One Super User per person, never shared. Super Users can edit each other, so a shared Super User account is an accountability hole: the User Actions Log will attribute everything to the same identity. Give each administrator who genuinely needs it their own account, enable multi-factor authentication on all of them, and use a personal non-Super-User account for day-to-day content work.

Document exceptions. Anywhere you set an explicit Allowed or Denied that differs from its parent scope, write down why. A comment in your internal runbook takes thirty seconds; a year later, “who allowed Delete for Authors on the News category and why” takes an afternoon.

Audit quarterly. The backend records logins, content saves and extension installs in Users > User Actions Log. Reviewing it a few times a year catches both dormant accounts that should be disabled and permissions that have quietly drifted. This pairs naturally with other recurring site work — if you already follow a scheduled maintenance routine, put a permission review on the same calendar.

Downgrade before you delete. When someone leaves the team, set their account to Blocked rather than deleting it outright, at least until you have confirmed nothing references it. Then remove them from groups in a controlled way. The user guide covers the mechanics of changing a user’s groups if you need the click path.

When this matters commercially

Permission problems rarely announce themselves. They surface as an editor who quietly cannot publish, a staff-turnover gap where a departed employee’s account still works, or an audit question you cannot answer. If your organisation runs Joomla — or is weighing it against alternatives for exactly this kind of multi-role editing — our Joomla development services page describes how we set up editorial workflows, and the Joomla platform overview covers where the system fits relative to WordPress and TYPO3. For the broader question of who on your team should be allowed to install third-party code at all, see our piece on plugin and extension governance.

The pattern to take away is simple: start from a child of Public, add the narrowest set of Allowed permissions at the narrowest sensible scope, verify the failures as carefully as the successes, and write down every exception. Do that, and Joomla’s ACL stops being the part of the backend people fear and becomes the reason you can hand out backend access without flinching.