How Joomla User-Group Inheritance and QCLF Allow/Deny Precedence Work
Joomla group membership is hierarchical, so a user can be authorized through a directly assigned child group plus inherited ancestors such as Registered and Public. QCLF 1.1.27 resolves Section/Category ACL with specificity instead of letting every inherited Deny override a more specific child rule.
This is important when a trusted child group needs an exception to a broader parent-group policy.
QCLF Starts from Direct Group Assignments
QCLF reads the user’s directly assigned Joomla groups, then maps their authorized ancestors. If a user is directly mapped to both a child group and one of its ancestors, QCLF treats only the leaf-most direct assignments as specificity roots.
This prevents an explicitly mapped ancestor such as Registered from being treated as equally specific to a child group such as Support.
Closest Matching Rule Wins
For a given Section or Category action, QCLF calculates the distance from each leaf-most direct group to matching ancestor rules. Only rules at the closest matching hierarchy distance participate.
A rule on the direct Support group therefore outranks a rule inherited from Registered or Public for that same action.
Deny Wins Only at Equal Specificity
If multiple matching rules exist at the same closest distance, QCLF uses Deny as the safe tie-breaker. If the closest set contains no Deny but contains Allow, the result is Allow.
This is more precise than a global “any Deny anywhere wins” model.
Example: Support Over Public
| Rule set | Result |
|---|---|
| Public = Deny; Support = Allow; user directly in Support | Allow. Support is the closer/more specific rule. |
| Support Group A = Allow; Support Group B = Deny; both equally specific direct groups | Deny. Equal-specificity tie breaks safely toward Deny. |
| Only Public = Deny; user inherits Public through Support | Deny. It is the closest matching rule available. |
| No matching explicit rule | No custom ACL decision; the action falls back to its normal QCLF default and other gates. |
Compatibility Fallback
If Joomla does not expose direct group assignments in the expected way, QCLF falls back to the deepest authorized groups in the Joomla tree and still uses Deny as the tie-breaker at equal depth. A last-resort conservative resolver is retained for unusual identity data.
Testing Guidance
- Test with the actual user account and direct group mappings used in production.
- Do not infer the result by looking at only one parent group.
- When debugging, compare rules for the same action across the user’s direct groups and ancestors.
- Use explicit Deny sparingly at broad parent groups when child exceptions are expected.
Community Discussion
Want to compare forum workflows, share practical QCLF tips, or discuss how other Joomla site owners use this feature? Visit the QC Live Forum Community. For private support, bug reports, account-specific entitlement problems, or feature requests, use the QuantaCade support system.