Understanding QCUI Database Schema Migrations

Understanding QCUI Database Schema Migrations 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.

Joomla migration model

The manifest points Joomla to sql/updates/mysql. Earlier migration files evolve the dedicated QCUI tables as the plugin changes, while the current 1.0.03 migration is intentionally schema-neutral.

Do not edit schema casually

The runtime expects columns and indexes that support token uniqueness/expiry/atomic use and audit evidence. Let Joomla’s installer/update process manage these files rather than manually removing columns to “clean up” the database.

Verify after update

A clean handoff test confirms the token table is writable and audit/start/end logic can operate after schema migration.

Maintenance boundary

Understanding QCUI Database Schema Migrations 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

Understanding QCUI Database Schema Migrations 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.