Troubleshooting a Target Without Frontend Login Permission

Troubleshooting a Target Without Frontend Login Permission requires identifying whether the problem is in plugin visibility, target eligibility, the short-lived handoff, or the separate frontend session before changing configuration.

Diagnostic procedure

  1. Review the target’s user groups and the effective core.login.site permission.
  2. Correct Joomla ACL only if the account is genuinely supposed to have frontend login.
  3. Start a new QCUI handoff after the ACL change.
  4. If frontend login is intentionally denied, QCUI correctly remains unavailable for that target.

Keep the layers separate

This denial comes from Joomla core.login.site. Trace effective ACL/user-group permission first; QCUI cannot create a frontend support session for an account Joomla itself says may not log in there.

Information to preserve

Record the target username, user groups, and effective core.login.site result. Do not collect the account password; QCUI is respecting Joomla ACL rather than authenticating with credentials.

When to escalate

If Troubleshooting a Target Without Frontend Login Permission persists after the documented layer is verified, stop creating repeated handoffs and preserve the exact error/context. A private support case should include version/state evidence but never passwords, session cookies, MFA secrets, or raw QCUI tokens.

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.