Understanding QCUI Target Eligibility
Understanding QCUI Target Eligibility 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.
Eligibility decision
| Target state | Result |
|---|---|
Ordinary enabled user with core.login.site | Eligible, assuming all other checks pass. |
| Same account as issuing administrator | Denied: select a different frontend user. |
| Any Super User | Denied. Super User accounts cannot be impersonated. |
| Blocked account | Denied. |
| Password reset required | Denied until the account is no longer flagged for reset. |
| No frontend login permission | Denied because core.login.site is required. |
| Unknown username | Denied before any handoff token is issued. |
Two checkpoints
QCUI validates this matrix when the Super User starts the handoff and again after the one-time token is consumed. The second check matters because account state can change during the short interval between tabs.
Shared Sessions is a separate gate
Even an otherwise eligible target cannot be impersonated while Joomla Shared Sessions is enabled. That site-level setting is checked before start and consume.
Do not bypass Joomla account state
Understanding QCUI Target Eligibility should be resolved through normal Joomla user/ACL administration. QCUI deliberately refuses to impersonate accounts that Joomla or QCUI currently considers unsafe/ineligible; changing database flags or handcrafting a token would remove the controls the support workflow depends on.
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.