Use Block-First Instead of Deleting a User

Block/disable instead of delete gives QCFUM frontend managers a safer offboarding action: the Joomla account stays in place, but QCFUM sets it to blocked. This preserves the user record and memberships for later administrator review or recovery.

It is still a privileged Max/All Access Frontend User Manager action and is subject to the same target protections as deletion.

Configure Block-First

Enable Allow frontend deletion of users, then set Frontend deletion behavior to Block/disable instead of delete. The frontend control is still labeled as a deletion action, but the server-side result is a Joomla block rather than removal.

What QCFUM Changes

For an eligible target, QCFUM loads the Joomla user, sets block = 1, and saves the account. It records the frontend_manager_user_blocked_instead_of_deleted audit event. The Joomla user ID, profile, group memberships, and other account data remain.

Current Notification Behavior

In QCFUM 2.0.4, the block-first branch does not call the frontend_manager_delete_notice template. If your process requires an offboarding notice, plan that separately and verify what the user should receive before delegating this action.

Approval and Recovery

If deletion approval is also enabled, QCFUM can store a durable request whose payload carries block-first behavior. On approval, the reviewer path again blocks the account instead of deleting it. Because the account still exists, an authorized administrator can later unblock it if the offboarding decision changes.

Community Discussion

Want to compare Joomla user-management 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.