feat(seed): on-demand QA walkthrough dataset for a QA-marked tenant #265

Merged
vas2000-work merged 1 commit from feat/PMS-331-qa-seed-dataset into main 2026-06-16 23:49:28 +02:00
Owner

Adds an operator-triggered QA seed (mokosh-bootstrap qa-seed --tenant <uuid> / qa-teardown) that loads a small but realistic, related dataset into a dedicated QA tenant so the staging walkthrough (PMS-326) can exercise list sort/filter/pagination/grouping/reports and relationship features that an empty tenant cannot.

Hard guardrail (fail closed): confirm_qa_tenant runs first for both seed and teardown and refuses with zero writes unless the target tenant's settings->>'is_qa' is true. A tenant marked environment=production is rejected outright, and a missing tenant row also fails closed. There is no flag that lets the seed touch an unmarked tenant, so it can never write to production or a real customer tenant.

Dataset (all QA-prefixed in names and qa-seed tagged where a tags column exists): 8 companies across every type with a parent and two children plus account managers, ~16 contacts (one primary per company, varied roles/phones/emails), 35 tickets (exceeds the 25/page default so the primary list paginates) cycling every status and priority over staggered dates with mixed billable/assignee, 2 projects with phases and tasks, 8 time entries with fractional hours both billable and not, one contract of every type, and two invoices with multiple line items plus payments (one full, one partial). Records are wired through the real service create paths so FK relationships and validation hold.

Idempotent: a pre-existing QA company short-circuits the seed without inserting. Teardown removes the dataset and the QA lookup rows it created in FK-dependency order, leaving stock tenant configuration intact. Includes unit tests and a compile-time assertion that the ticket count paginates.

#PMS-331

Adds an operator-triggered QA seed (`mokosh-bootstrap qa-seed --tenant <uuid>` / `qa-teardown`) that loads a small but realistic, related dataset into a dedicated QA tenant so the staging walkthrough (PMS-326) can exercise list sort/filter/pagination/grouping/reports and relationship features that an empty tenant cannot. Hard guardrail (fail closed): `confirm_qa_tenant` runs first for both seed and teardown and refuses with zero writes unless the target tenant's `settings->>'is_qa'` is true. A tenant marked `environment=production` is rejected outright, and a missing tenant row also fails closed. There is no flag that lets the seed touch an unmarked tenant, so it can never write to production or a real customer tenant. Dataset (all QA-prefixed in names and `qa-seed` tagged where a tags column exists): 8 companies across every type with a parent and two children plus account managers, ~16 contacts (one primary per company, varied roles/phones/emails), 35 tickets (exceeds the 25/page default so the primary list paginates) cycling every status and priority over staggered dates with mixed billable/assignee, 2 projects with phases and tasks, 8 time entries with fractional hours both billable and not, one contract of every type, and two invoices with multiple line items plus payments (one full, one partial). Records are wired through the real service create paths so FK relationships and validation hold. Idempotent: a pre-existing QA company short-circuits the seed without inserting. Teardown removes the dataset and the QA lookup rows it created in FK-dependency order, leaving stock tenant configuration intact. Includes unit tests and a compile-time assertion that the ticket count paginates. #PMS-331
feat(seed): on-demand QA walkthrough dataset for a QA-marked tenant
All checks were successful
Check / fmt + clippy + compile + unit/doc tests (pull_request) Successful in 56s
E2E / Playwright against staging (pull_request) Successful in 57s
Integration / integration tests (pull_request) Successful in 5m31s
Create release / Create release from merged PR (pull_request) Has been skipped
553a995e81
Adds an operator-triggered QA seed (`mokosh-bootstrap qa-seed --tenant <uuid>` / `qa-teardown`) that loads a small but realistic, related dataset into a dedicated QA tenant so the staging walkthrough (PMS-326) can exercise list sort/filter/pagination/grouping/reports and relationship features that an empty tenant cannot.

Hard guardrail (fail closed): `confirm_qa_tenant` runs first for both seed and teardown and refuses with zero writes unless the target tenant's `settings->>'is_qa'` is true. A tenant marked `environment=production` is rejected outright, and a missing tenant row also fails closed. There is no flag that lets the seed touch an unmarked tenant, so it can never write to production or a real customer tenant.

Dataset (all QA-prefixed in names and `qa-seed` tagged where a tags column exists): 8 companies across every type with a parent and two children plus account managers, ~16 contacts (one primary per company, varied roles/phones/emails), 35 tickets (exceeds the 25/page default so the primary list paginates) cycling every status and priority over staggered dates with mixed billable/assignee, 2 projects with phases and tasks, 8 time entries with fractional hours both billable and not, one contract of every type, and two invoices with multiple line items plus payments (one full, one partial). Records are wired through the real service create paths so FK relationships and validation hold.

Idempotent: a pre-existing QA company short-circuits the seed without inserting. Teardown removes the dataset and the QA lookup rows it created in FK-dependency order, leaving stock tenant configuration intact. Includes unit tests and a compile-time assertion that the ticket count paginates.

#PMS-331
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
psa-systems/mokosh-server!265
No description provided.