Why Production Push and Rollback Require a Super User

QCUL requires a Joomla Super User for production push and production rollback because those actions can alter or restore live files, database schema/data, and site availability.

Defense beyond ordinary lab permissions

A user can be allowed to create/view/test laboratories or download reports without being able to change production. Live push/rollback actions explicitly check both the current Joomla user and QCUL operation authority on the server.

Why this matters

• Protects against over-delegated maintenance accounts.
• Prevents a laboratory reviewer from silently escalating to live deployment.
• Keeps destructive recovery authority with experienced administrators.
• Makes forged/modified browser forms insufficient when the server user is not authorized.

Recommended team design

Delegate lab review/report access broadly enough for useful QA, but keep Super User production actions with a small group that also understands backups, maintenance windows, rollback evidence, and Joomla recovery.

Defense-in-depth principle

Why Production Push and Rollback Require a Super User is one layer in QCUL’s security model. Keep Joomla ACL, CSRF tokens, private gate/storage, laboratory identity, runtime authorization, side-effect quarantine, production Super User checks, and careful handling of production-derived evidence together rather than weakening another control to make one workflow more convenient.

Community Discussion

Want to compare update-testing workflows, share practical tips, or discuss how you use this QCUL feature? Visit the QC Update Laboratory Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.