Understanding QCUL Laboratory, Update-item, and Production States
QCUL uses explicit internal states for the laboratory lifecycle, tested update, and production operation; the administrator sees simplified labels that indicate what is happening and what action is safe next.
Laboratory state labels
| Visible label | Meaning |
|---|---|
| Checking site | Preflight: storage, permissions, paths, database, and gate capability. |
| Copying site files | Production files are being copied into the private laboratory. |
| Copying site data | Joomla-prefixed production database tables are being copied to the isolated lab prefix. |
| Securing laboratory | Configuration, private gate, runtime marker, cookies, and identity protections are applied. |
| Disabling outgoing activity | Mail, Scheduled Tasks, Lazy Scheduler, copied sessions, and remember-me tokens are neutralized. |
| Saving lab restore point | Files/database are being protected before a test update. |
| Installing in laboratory | The selected package is being installed only inside the private copy. |
| Checking update | Version/route/evidence validation is running. |
| Undoing lab update | The lab restore point is being restored. |
| Ready to test | The laboratory is usable and available for update testing/review. |
| Needs attention | A test or cleanup condition requires administrator review. |
| Removing laboratory | The private environment and temporary artifacts are being deleted. |
| Removal needs attention | Cleanup could not remove every owned object; Retry Removal is appropriate. |
Tested-update result states
| Visible result | Operational meaning |
|---|---|
| No problems found | Automated evidence passed; human laboratory review is still required. |
| Review recommended | The update installed/tested but evidence needs human investigation. |
| Failed / Error | The rehearsal did not establish a valid production candidate. |
| Tested here / Already installed in lab | The laboratory already contains the target/test result; use existing result or reset lab state rather than reinstalling blindly. |
| Installed on live site | The production operation installed the tested target. |
| Live update undone | A QCUL production rollback restored the prior live state. |
Production execution labels
- Readiness can show blocked reasons such as review needed, choose production protection, wrong target, or another QCUL task running.
- A completed production install can be Installed — review recommended when target installation succeeded but validation evidence needs attention.
- Rollback attention deliberately requires Resume Rollback rather than uncontrolled automatic retry.
Use state, not button guessing
When a control disappears, read the current state/evidence first. QCUL intentionally hides or changes actions when their prerequisites are no longer true.
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.