sharix-open-testkit

sharix-open-testkit

Migrations

When testkit models are installed, their schema is owned by committed canonical migrations. Stage 7.6.6 can create the one-time baseline in the authoritative Open checkout; production install/start code never runs makemigrations.

Stage 8 reference environment

Scenario reference_demo_environment is a Stage 8 acceptance scenario. On a positive METASERVICE_ID it records a clean skip. On METASERVICE_ID=0 it runs the production read-only reference audit, checks that namespace 0 has no Platform sync journal/state, verifies the local no-money payment backend and login switch semantics, and exercises the production bootstrap inside a rollback-only transaction to detect duplicate/stable-key regressions. Testkit does not own or persist the reference fixtures.

Demo/reference reset

Testkit exposes one canonical reset entry point for the Stage 8 training namespace:

./venv/bin/python manage.py reset_demo_reference_environment --yes

The command is destructive only for rows provably owned by the canonical Stage 8 reference identities and only when METASERVICE_ID=0. It does not wipe arbitrary namespace-0 rows, schemas, migrations, source repositories, secrets or installation configuration. A normal positive-ID Platform installation fails closed before any reset work; even a misconfigured Platform exposing id 0 returns an explicit no-op because Platform does not own Open demo business data.

The database part removes mutable runtime descendants of reference users (orders and execution/payment descendants, reference appointment instances, mutable provider/resource/check/document state) and deletes file-backed onboarding projects owned by reference users. It then calls the production-owned reset_demo_reference_stage84() / Stage 8 ensure+audit. The LDAP part uses bin/sync_ldap_from_ldif.sh to restore safe profile attributes and canonical reference-user role memberships. Passwords are intentionally preserved by the existing LDAP recovery policy.

Installer flags now have real behavior and share the same service:

• TESTKIT_DELETE_LDIF_USER_DATA_ON_INSTALL=true resets database-side demo runtime;
• TESTKIT_RESET_LDIF_USERS_ON_INSTALL=true reconciles reference LDAP users/groups;
• enabling both is equivalent to the complete reset before install scenarios.

A positive METASERVICE_ID fails closed if either destructive reset flag is enabled.

Stage 9 service onboarding acceptance

Scenario service_onboarding_launch is a read-only Stage 9.4 acceptance check. It skips cleanly when sharix_onboarding is not installed (including Platform assemblies) or when no project has completed launch yet. For completed launch results it verifies that the recorded first order still exists and that the materialized service set has at least one active Provider offer. Testkit never creates launch business data and remains optional.

UI smoke persona/fixture resolution

run_ui_smoke remains read-only. It never creates Orders, requirement tickets or other business objects merely to satisfy a route fixture. When a case has an object-bound fixture and its persona is not pinned through SHARIX_UI_SMOKE_PERSONAS, Testkit checks active users matching the persona groups in deterministic group/primary-key order and uses the first user for whom the fixture resolver finds a stable object. This avoids coupling strict smoke to the first member of a role group when another valid test persona owns the fixture.

An explicit SHARIX_UI_SMOKE_PERSONAS entry is authoritative: Testkit checks only that configured user and fails/skips according to the requested strict mode rather than silently substituting another account.