Permission Inheritance & Parent Groups (Joomla 3)

Every User Group in Joomla, with the only exception being the Public Group, has a parent group. The Parent Group determines the Permissions that the User Group starts with when it is first established. After that point, Permissions can be changed for the User Group to fit the needs of that Group. This allows you to create a tiered site administration system where different User Groups have different site editing capabilities. The concept of basing a User Group’s Permissions off of a Parent Group is called Permissions Inheritance, and this article explains that topic.

Permissions Inheritance Basics

Implicit Deny

Explicit Deny

Permissions Inheritance Basics

When a User Group is first created, it inherits all of the Permissions that have been assigned to its Parent Group. This goes for both Global Permissions as well as Manager and Component-specific Permissions. As an example, let’s say that you have created a group called Administrator which has the Create and Edit Own Permissions assigned in the Global Permissions area of your site. You then create a group called Managers and set its parent group to the Administrator group. When you do this, the Administrator group will inherit the Create and Edit Own permissions from the Manager Group. You can then give the Administrator group more permissions, or you can take away the Permissions that it inherited. For instance, you could give the Administrator group the Edit Permission so that they can edit any Article, not just the ones that they have written. You could also take away the Create Permission from them, so that they only have the ability to edit Articles, not create new ones.

Implicit Deny

In general, you can override the Permissions that are inherited from the parent group. However, there is one exception. To understand that exception, first we have to explain the concept of implicit deny versus explicit deny. Implicit deny means that any Permission that is not specifically set is denied by default. To understand this best, log into the Administration area (the back end) of your site.

Click on the User Group tab to open the the Group Manager, and you'll notice how all groups except for the Public Group are indented at least one level.

This indicates that the Manager, Registered, and Super Users Groups have the Public Group as their Parent Group. The other Groups are Children (Child Groups) of the Manager and Registered Groups. To understand a little better, go to the Global Configurations area.

Once inside the Global Configurations area, click on the Permissions tab. You will notice how the Permissions for the Public Group are set to "Not Set". This means that, by default, all of those Permissions are not allowed for the Public group (implicit deny). 

Now, open up the Manager User Group.

Any Permission Setting set to "Allowed" is also listed as "Allowed" underneath the Calculated Setting, but because the Public Group is the Manager Group's Parent, any Permission Setting set to "Inherited" receives the Calculated Setting of "Not Allowed". This is due to the fact that those Permissions are inherited from the Public group, which has all of its Permissions set to "Not Set". The screenshot also illustrates that setting a Permission to Allowed will override a permission that is inherited as Not Allowed due to the permission not being set in the Parent Group.

Back to Top

Explicit Deny

The exception to the "Allowed" Permission Setting overriding a Permission that is inherited as "Not Allowed" comes from the concept of explicit deny. The article titled Permission Settings (Joomla 3.0) explains that Permissions can be set to "Inherited", "Allowed", or "Denied". At this point, you should understand what the "Inherited" and "Allowed" settings determine. The "Denied" setting is what is known as an explicit deny, and will override any other setting. This means that if you set a permission to be "Denied" in one Group, any Group that inherits Permissions from that Group will also have that Permission set to "Denied". You cannot override this using the "Allowed" setting.

To illustrate this concept, let’s go back to the example of the Manager and Administrator Groups. Remember that the Administrator Group has the Manager Group as its Parent. Let’s say that we know that we do not want the Manager Group or any of its Child groups to have the Delete Permission. To accomplish this, we would set the Delete permission to Denied for the Manager group.

As you can see, once we change the setting for the Delete permission to "Denied", the Calculated Setting for the Contributors Group is "Not Allowed". Now open the Administrator Group. You'll notice that the Calculated Setting on the Delete Permission is set to "Not Allowed" and it is "Locked".

This means that you cannot override that setting, it will always be "Not Allowed" and "Locked" unless this is changed in the Parent Group. You need to be very careful in how you use the Denied setting. In most cases, it is better to simply leave the permission as "Not Set".

Back to Top