How Group-Change Approval Works in the Frontend User Manager

Submit a durable approval request rather than applying immediately; reviewer later rechecks entitlement, user scope, protected groups, requested groups, and ACL.

This guide follows the accepted QC Frontend User Manager 2.0.4 implementation and applies to Max / All Access with approval enabled. QCFUM delegates selected Joomla user-onboarding and management workflows without making frontend staff Joomla backend administrators. When older manuals or walkthrough wording differs from the current source or accepted keyless-entitlement behavior, the current implementation takes precedence.

Before You Begin

Enable only the user-management actions staff actually need.
Test visibility and editability with the exact frontend-manager Joomla group.
Keep a Super User Administrator session available while first validating delegated controls.

Step-by-Step Workflow

Open Approval Queue as an account with the required approval permission.
Filter/locate the pending onboarding or protected user-management action.
Inspect the target user/invite, requested operation, submitter, and current group/protection context.
Approve only if the action remains authorized under the current entitlement, ACL, and safeguards; otherwise reject it.
Confirm the durable request moves to its resulting state and that the underlying Joomla user/invite action matches the decision.

Server-Side Safeguards

Joomla menu access, QCFUM ACL, product entitlement, and target-specific authorization are separate gates.
Super Users and equivalent protected administrative accounts remain protected server-side.
Visibility does not automatically imply editability; a user may be shown but intentionally view-only.
Allowed destination groups are constrained independently from the groups a target user currently has.
Bulk actions re-authorize each selected target server-side; the UI selection is never the security boundary.
Password resets are delivered privately; frontend managers do not receive the generated password.
The QCFUM MFA Required value is an administrative flag only, not Joomla MFA enforcement.

Durable Approval Model

Approval is a stored workflow decision, not merely a hidden frontend button.
The reviewer must still have permission when acting on the pending request.
The protected action is revalidated at approval time so changed groups, target protections, or entitlement cannot be bypassed by an old request.
Downgrade or entitlement change does not justify silently deleting durable pending security decisions; availability and final authorization remain current-state dependent.

Submit a durable approval request rather than applying immediately

Submit a durable approval request rather than applying immediately. In QCFUM 2.0.4, this must be evaluated together with the current Effective tier, the Joomla/QCFUM permissions of the acting account, and target/workflow safeguards. QCFUM is designed to fail closed around protected users and sensitive actions rather than trusting the presence of a frontend button as authorization.

For How Group-Change Approval Works in the Frontend User Manager, test the exact workflow with a safe non-administrator account and a deliberately chosen target. QCFUM’s frontend presentation is not the authorization boundary: a control can be visible while the server still refuses an unsafe target, an unavailable tier, an invalid workflow state, or a group change that violates administrator-defined safeguards.

Reviewer later rechecks entitlement, user scope, protected groups, requested

reviewer later rechecks entitlement, user scope, protected groups, requested groups, and ACL. In QCFUM 2.0.4, this must be evaluated together with the current Effective tier, the Joomla/QCFUM permissions of the acting account, and target/workflow safeguards. QCFUM is designed to fail closed around protected users and sensitive actions rather than trusting the presence of a frontend button as authorization.

How This Fits into QCFUM

The Frontend User Manager delegates selected Joomla user administration, but Joomla remains authoritative for users, groups, block/activation state, passwords, MFA systems, and ACL. Every sensitive target/action is re-authorized server-side.

A reliable QCFUM configuration keeps Joomla authoritative for real user accounts while QCFUM owns the delegated workflow, attribution, approval, automation, and safety rules around those accounts. This separation matters during upgrades and downgrades: preserving QCFUM records does not mean every preserved premium feature remains usable at a lower Effective tier.

Security and Data-Protection Notes

Use least privilege for menu access and QCFUM ACL; grant staff only the actions required for their role.
Never share passwords, invite tokens, API credentials, or private account data in screenshots, support requests, or custom email content.
Treat Super Users and equivalent administrative-capability accounts as protected even when a UI configuration appears permissive.
Verify destructive or access-changing actions with a safe test account before enabling them for production staff.
Remember that uninstall/reinstall is not a supported method for wiping QCFUM business data or resetting entitlement/preview history.

Verify the Result

Status shows the expected Base and Effective tiers for the current Authorized Domain.
Entitlement Revalidation is healthy at the canonical hourly cadence unless this guide is specifically diagnosing that task.
The resulting Joomla user/group state matches the intended QCFUM workflow.
A protected or out-of-scope user remains protected when tested with the delegated staff account.
Reload the real frontend/Administrator view rather than relying only on a saved form message.
Repeat the critical test using the exact non-Super-User group that will operate the workflow.

Common Mistakes to Avoid

Assuming inherited Joomla group visibility means QCFUM should write inherited memberships rather than direct memberships.
Assuming an old pending approval guarantees the action can still run after groups, protections, or entitlement change.
Assuming a visible Users-tab row is automatically editable or that a selected bulk target will bypass server-side authorization.
Testing only as Super User instead of the actual delegated staff group.
Changing multiple security/workflow settings at once during troubleshooting, making the real cause difficult to identify.

Troubleshooting

If a control or tab is missing, check Effective tier, QCFUM ACL, menu access, and feature configuration before assuming installation damage.
If a user cannot be selected or changed, check protected groups/IDs, core administrative protection, visibility/editability rules, destination-group rules, and the delegated manager’s exact permissions.
If onboarding stalls, inspect the stored workflow status (invite, approval, import, temporary access) rather than deleting the record and starting over immediately.
If automation does not run, verify Joomla Scheduled Tasks and distinguish the hourly Entitlement Revalidation task from the separately configured Scheduled Automation task.
If email does not arrive, verify Joomla mail transport independently, then inspect QCFUM template publication, recipient/address, queue state, and retry eligibility.

Operational Best Practice

Keep onboarding definitions simple enough that staff can select the correct Profile/Pack without guessing. Test every delegated workflow with the real staff Joomla group, keep entitlement/tasks healthy, and preserve an Administrator recovery path. When changing user-management safeguards, verify both a target that should be allowed and a protected target that must still be refused.

Community Discussion

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