# Clean install, upgrade, uninstall, reinstall, and rollback plan

These are controlled acceptance tests for a disposable VTiger 8.4 clone; this reconstruction does not run them against production.

1. Clean install: import the ZIP, verify entity identity, Tools placement, two tables, reporting view, runtime screens, and absence of automatic profile grants.
2. Upgrade: seed PBXManager, crmentity, and MarvelPBX rows; capture counts and checksums; import over the prior module; verify all data is unchanged and the view/placement are correct.
3. Uninstall: capture all data first; uninstall in the clone; verify the lifecycle drops the reporting view and never explicitly deletes PBXManager, crmentity, or MarvelPBX tables. Confirm VTiger's selected uninstall policy before accepting any platform-driven table removal.
4. Reinstall: reimport the ZIP; verify idempotent placement and view recreation with no duplicate parent-tab relations.
5. Rollback: restore the database snapshot, prior module runtime, module metadata, and prior view definition as one coordinated change; clear VTiger caches; compare the captured counts/checksums and smoke-test list/detail/export views.

Failure is closed: restore the clone snapshot and do not deploy. Production rollout requires a fresh backup, maintenance window, explicit profile assignment, and successful clone evidence.

## Disposable package-test execution

Lifecycle imports must run only on a disposable clone. The selected mechanism is the authenticated standard Module Manager web flow on the isolated package-test virtual host. It uses the full index.php/WebUI bootstrap, an authenticated administrator session, same-origin referer validation, a POST request, and the CSRF token generated by VTiger.

The upload view stores the package in the Module Manager upload directory and inspects it with Vtiger_Package. Settings_ModuleManager_Basic_Action then calls Vtiger_Package::update for an existing module or Vtiger_Package::import for a clean installation. This is the supported path for the next test.

The bundled vtlib/tools/console.php is not used for this installation: it loads vtlib before config.php and the complete application/model bootstrap. A partial direct CLI bootstrap can establish the database and vtlib classes but still lacks Vtiger_Module_Model when PackageImport processes tables. No replacement CLI harness is approved unless it reproduces the complete proven web bootstrap.

The 12.5.1 legacy-upgrade test must begin from a clean clone of the version-0 manual MarvelPBX runtime and metadata state. A clone on which the failed 12.4.1 update already wrote version metadata is not a valid starting point and must not be repaired in place.

After each lifecycle test, including a failed update, destroy and recreate the disposable package-test filesystem and database from the isolated source snapshot. Verify the recreated clone's module version, duplicate-placement fixture, row counts, view definition, permissions, and runtime checksums before the next import.

Rollback of the disposable clone means destruction and clean recreation from an isolated filesystem/database source, not an application-user replay over the test state. SQL dumps remain evidence and an additional recovery layer. Exact restoration of SQL objects containing explicit DEFINER clauses requires a privileged database operator with SET USER/SUPER-equivalent authority; an application account cannot recreate another account's definer.