Understanding QCUI Audit Logging
Understanding QCUI Audit Logging explains the current QCUI 1.0.03 behavior and how it affects a Super User who needs to inspect the Joomla frontend as an eligible user.
Purpose
QCUI records important impersonation lifecycle and denial events in #__qcloginasuser_audit. This gives the product an internal evidence trail without putting a management/reporting screen into the current plugin UI.
| Event | When it is written |
|---|---|
issued | A valid Super User successfully creates a one-time frontend handoff. |
started | The frontend consumes the token and switches to the eligible target identity. |
ended | The impersonated frontend is deliberately returned to guest. |
denied_shared_session | An administrator tries to start QCUI while Joomla Shared Sessions is enabled. |
denied_unknown_user | The submitted exact username does not identify a Joomla user. |
denied_target | The target fails an eligibility rule at start or consume time. |
denied_admin | The issuing administrator is no longer a Super User when the token is consumed. |
Failure behavior
Audit insertion is wrapped so an audit-storage failure does not expose credentials or break Joomla. That resilience means administrators should still monitor database health if an external compliance process depends on those rows.
Community Discussion
Want to compare support workflows, share practical tips, or discuss how you use this QCUI feature? Visit the QC User Impersonation Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.