Joomla Group Inheritance in QCFUM Visibility, Editability, and Protection

QCFUM 2.0.4 understands Joomla’s nested user-group hierarchy when deciding whether an existing user is visible, editable, or protected. This means a parent-group selection can apply to users assigned directly to descendant groups.

Authorization Uses the Group Hierarchy

For managed-user authorization, QCFUM builds the target user’s authorized group set from both the user’s direct Joomla group memberships and the ancestor groups above those memberships in Joomla’s nested-set hierarchy.

For example, if a site has a parent group named Staff and a child group named Editors, selecting Staff for a QCFUM visibility or editability rule can include a user assigned directly to Editors.

Where Inheritance Matters

  • Users shown in Frontend User Manager: a selected parent can make descendant-group users eligible to appear.
  • Users frontend managers may change: a selected parent can authorize editing of users assigned to descendant groups.
  • Groups always hidden/protected: selecting a parent can protect users assigned to its descendants.
  • Automatic administrative protection: Joomla capability checks add another protection layer regardless of manually selected groups.

Actual Membership Changes Stay Direct

Inheritance is used for authorization and protection decisions. It does not mean QCFUM writes inherited memberships into Joomla.

When a permitted Frontend User Manager group change is applied, QCFUM works with the user’s direct Joomla memberships. Allowed target groups may be added or removed directly, while unrelated existing direct memberships are preserved.

Why This Distinction Matters

Without hierarchy-aware authorization, an administrator could select a parent group and unexpectedly fail to match its child-group users. Without direct-membership editing, a frontend workflow could incorrectly flatten or duplicate Joomla’s group structure. QCFUM keeps those two concerns separate.

Test a Parent/Child Example

  1. Choose a safe parent Joomla group and a test child group beneath it.
  2. Assign a test user directly to the child group.
  3. Select the parent in the relevant QCFUM visibility, editability, or protection setting.
  4. Test as the real delegated staff group.
  5. Confirm the user is included or protected as expected without QCFUM adding the parent as a new direct membership.

Current-Version Note

This hierarchy-aware behavior reflects the current post-2.0.2 implementation. Older instructions that treat only the user’s literal direct group IDs as the authorization set are obsolete.

Community Discussion

Want to compare Joomla user-management safeguards, share practical QCFUM configuration ideas, or discuss how other administrators delegate frontend workflows? Visit the QC Frontend User Manager Community. For private support, bug reports, account-specific entitlement problems, or feature requests, use the QuantaCade support system.