How QCUI Updates Preserve the Existing Enabled or Disabled State
How QCUI Updates Preserve the Existing Enabled or Disabled State describes a current QCUI 1.0.03 implementation detail that matters when you are validating security, session isolation, or support behavior.
Fresh install versus update
| Installer path | Enabled-state behavior |
|---|---|
| Fresh install | The installer explicitly enables system/qcloginasuser. |
| Update | The update hook returns successfully without forcing enabled=1, preserving the administrator’s existing choice. |
Why preservation matters
A site owner may intentionally disable impersonation outside active support windows. An extension update should not silently override that security/operations choice.
Verify the result
- Before update, note the plugin state.
- Update QCUI normally.
- After update, confirm Joomla kept that same enabled/disabled state.
Maintenance boundary
How QCUI Updates Preserve the Existing Enabled or Disabled State 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.
Maintenance boundary
How QCUI Updates Preserve the Existing Enabled or Disabled State 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.