Understanding the QCUI Audit Database Table
Understanding the QCUI Audit Database Table 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.
Table purpose
#__qcloginasuser_audit stores QCUI lifecycle and denial evidence.
| 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. |
Schema fields
Each row stores action, administrator and target user IDs, UTC timestamp, IP address, browser user-agent, and short details. The product currently does not expose a GUI to browse these rows.
Maintenance boundary
Understanding the QCUI Audit Database Table should be handled through Joomla’s extension installer/update lifecycle. The retained qcloginasuser identity, schema migrations, and uninstall SQL exist to make that lifecycle predictable; manual file/table surgery can create a state the released plugin was not designed to manage.
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.