How Joomla Permission Inheritance Works
Joomla permissions are evaluated through two related hierarchies: the user-group hierarchy and the asset hierarchy for the item being accessed. Understanding both explains why a permission that looks Allowed on one screen may still calculate as Denied for a particular user.
User groups inherit from their parents
A Joomla user may belong directly to one or more groups. Child groups also inherit the relevant membership context and permissions of their parent groups. This is why choosing a parent when creating a custom group is a security decision, not just an organizational choice.
Permissions also flow through the asset hierarchy
For content actions, Joomla can evaluate rules from Global Configuration down through a component, category hierarchy, and individual item where supported. Joomla's current programmer documentation describes this using the assets table: Joomla gathers rules for the target asset and its ancestors when deciding whether an action is authorized.
Inherited means “use the applicable higher-level result”
When an action is set to Inherited, that level does not add an explicit Allowed or Denied rule for the selected group. Joomla continues evaluating the applicable parent group and higher asset-level rules. After saving a permission screen, use the Calculated Setting to see the effective result instead of assuming Inherited means Allowed.
Denied has priority
If Joomla finds an explicit Denied rule for the action in an applicable group or higher asset level, a lower Allowed setting does not override it. If no Denied rule applies and at least one applicable rule allows the action, Joomla can authorize it. If no applicable rule grants the action, the user is not authorized.
Example: article editing
Suppose an Editors child group is Allowed to edit a category, but one of the user's applicable parent/group rules is explicitly Denied for Edit at a higher level. The lower Allowed rule will not win. Conversely, if the higher level is merely Inherited/Not Set and an applicable category rule grants Edit, the calculated result can become Allowed.
Troubleshoot inheritance systematically
- Identify the exact user and every group that applies, including parent groups.
- Identify the exact action, such as Edit, Create, Delete, or Edit State.
- Start at Global Configuration and inspect the relevant group rules.
- Continue through the component, category, and item levels that apply to the target.
- Look specifically for an explicit Denied rule.
- Save changes and inspect the Calculated Setting.
- Retest with the affected non-Super-User account.
Keep viewing access separate
Viewing access levels use user groups to decide what a user can see, but they are separate from action permissions. A user can qualify to view an article while lacking permission to edit it. Diagnose visibility and action authorization as separate layers.
Need More Help with Joomla?
Still having trouble? Open a support ticket with QuantaCade Support and we'll be happy to help where we can.
Support priority is given to QuantaCade products, services, and customers. However, we're also happy to assist fellow Joomla users with general Joomla questions and troubleshooting when possible.
QuantaCade is an independent Joomla extension developer and is not official Joomla support. Some issues involving third-party extensions, hosting environments, server configurations, or other systems outside our development control may be beyond what we're able to resolve.