Permission Inheritance & Parent Groups (Joomla 2.5)

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".

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 "Contributors" which has the "Create" and "Edit Own" permissions assigned in the global permissions area of your site. You then create a group called "Proof Readers" and set its parent group to the "Contributors" group. When you do this, the "Proof Readers" group will inherit the "Create" and "Edit Own" permissions from the "Contributors" group. You can then give the "Proof Readers" group more permissions, or you can take away the permissions that it inherited. For instance, you could give the "Proof Readers" 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.

Back to Top

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 User" groups have the "Public" group as their parent group. The other groups are children (child groups/nested 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 2.5) 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 inheritspermissions 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 "Contributors" and "Proof Readers" groups. Remember that the "Proof Readers" group has the "Contributor"s group as its parent. Let’s say that we know that we do not want the "Contributors" 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 "Contributors" 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 "Proof Readers" 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