Web design, CMS and development, since 2014VR Games
Joomla

Joomla Access Levels Explained: Groups, Permissions and A Realistic Case

Joomla uses two separate models to manage who sees a piece of content: viewing access levels and user groups and permissions. While user groups determine who the user is (such as "Administrator") and what they can do, the viewing access level determines who may see the content—what it is visible to.

So, if you plan to create a restricted members-only section on your site, Know the following: a user group on its own is not enough to keep people out. You must point that group (e.g. "Subscriber") to a viewing access level, and bind that level to your restricted menu items and articles.

Groups vs Access: Joomla's Two Different Questions

Joomla's access-control model is built around three questions:

  1. Who are they? (user groups)
  2. What may they see? (viewing access levels)
  3. What may they do? (permissions)

A user group only defines a role (such as your membership, author, editors) and what permissions apply to that role. A viewing access level is only a membership list; it says "If someone is in one of these user groups, then they may see this content."

As one community explanation puts it, access levels decide who may see the content, and it never grants the right to change anything; permissions are what govern what a user can do.

So if you set up a Registration-level article, being in the Registration group lets you view it, but you still can't edit or delete it. And a special Members access level, for example, controls who can see the restricted content, not who is allowed to decide what articles go there.

The confusion starts with that last part. While groups are arranged in a hierarchy (Super Users, Admin, Manager, Author, Editor, Publisher, Registered, Subscriber) and child groups inherit their parent's permissions, viewing access levels are not inherited at all.

The default levels (Public, Guest, Registered, Special, Super Users) are set separately for each level, and a child group does not automatically get the same viewing access as its parent.

Viewing Access Levels: How Joomla Decides What Is Visible

So how does Joomla calculate visibility in technical terms?

It's simple. The Access field on articles, modules, menu items etc is really just pointing to a viewing-access-level integer (e.g. "Registered" maps to an integer ID).

When you edit the levels in Users -> Access Levels, you're just attaching different user groups to each numeric access level.

So when a visitor lands on a menu item, Joomla does this:

  1. Checks if the user is logged in. If not, they're in the Guest group.
  2. Looks at their user-group membership, including any inherited child groups.
  3. Compares the user's groups against the list in the menu item's viewing access level.
  4. If there's a match, the menu is shown. Otherwise, it's hidden.

The Default Levels: Public, Guest, Registered, Special, Super Users

Joomla's database entry for the Guest viewing access level maps only to the Guest user group.

"Guest" is the only level that applies to users who aren't logged in (a point that Joomla documentation and community articles all emphasize). For this reason, it's often used to advertise a registration-wall version of some content.

Everything in the Public level is visible to everyone, whether logged in or not. In the database, the Public level references the "Public" user group, the parent of all.

The Registered level is used for content that should be visible only to site members. It includes the Registered, Manager, and Super Users groups.

The Special level, as community articles explain, is aimed at editor and admin roles, to restrict content to Author, Manager, and Super Users.

These settings are all configurable in Users -> Access Levels; you can rename levels, change group memberships, or add entirely new levels.

Assigning Groups to Levels: Where Confusion Starts

The biggest source of confusion here is that viewing access levels are composited from user groups, But think of it as a subset. So, the Special level contains only certain groups, it cannot contain all the Manager child groups.

You specify which group, and then say they have access to certain objects. That means a Super User always has full access to everything, but other roughly "super user" groups, like Authors, do not.

Of course, both parts are needed. Being in a group alone doesn't control access, and access levels are useless without groups attached to them.

For example, shows "Special" level mapping to only 4 groups:

  1. Public Backend (for Super Users only)
  2. Manager (for designated managers)
  3. Author (for authors)
  4. Super Users

If you assign the "Special" level to articles in an admin-only section, then only users in one of those 4 groups will see it, regardless of their other group memberships or roles.

Designing a Members-Only Area Without Locking Yourself Out

Let's come back to that members-only section.

  1. Create a custom "Member" group, in Users -> Groups. Call it "Member."
  2. Create a custom "Member" viewing access level, in Users -> Access Levels. Check the "Member" group's box.
  3. In config, point the "Member" access level to the Member group.
  4. In your articles and menu items, set the Access level to "Member."

That's the rough plan, in principle. One approach is creating a viewing access level for each membership tier (Bronze, Silver, Gold), and attaching the corresponding "Bronze," "Silver," and "Gold" groups to each. With two levels of restricted access, everything should be even clearer.

Far more important though is avoiding the common missteps. The two most frequent come down to:

  1. Assuming a group itself controls visibility: This is backward thinking. Groups define your user roles, not their visibility. Even Super Users don't actually see everything because they aren't attached to "Super" access levels.
  1. Thinking viewing access levels inherit: This is true for permissions, not visibility. A Registered group doesn't automatically get "Guest" access, or a Manager get "Registered." If you want a group to be able to see certain things, give them access in the backend.

Checking Your Setup: Where to Look in the Backend

In a "Public" site, you might assume:

  1. No special user group, they're in the Default group.
  2. Public access level is applied to anything accessible by the public.

This includes even when someone visits for the first time, so they aren't logged in and don't have a username or password.

A "Registered" site requires you to log in, but:

  1. No special groups.
  2. Registered access level is applied by default to all areas of the site.

So the only way to customize who's allowed in certain areas is to add custom access levels for, say, important pages. This means that when you build a members-only area, everyone should be in the same group, but the pages should be accessible to the corresponding group only.

Joomla loves to use permissions and access levels to lock areas of a website, and there seems to be no shortage of those who misuse this feature to create members-only sections.

For example, you might have a members-only page, but visitors still see it in article listings. This occurs because the page's Access level's not set to "Special"; it's actually assigned to a "Registered" level.

And in fact, Registered readers see even more, because, by default, "Registered" maps to the whole Registered group, not just special members. In your content configuration, any content marked as "Registered" is viewed by the entire world; no special groups are required.