At a Glance
Persona: Audit / Config (System Administrator config + Auditor read-only) · Module: recipe · Scenarios: ~31
Categories: Happy Path · Permission · Validation · Edge Case
E2E coverage: none for recipe internals; integration-health checks separate from recipe E2E in../carmen-inventory-frontend-e2e/
This page captures the test scenarios that the Audit / Config persona — comprising System Administrator (categories, cuisines, equipment masters, RBAC, tenant policy on publish gate / un-publish / co-approval, integration wiring with [product](/en/inventory/product) / [inventory](/en/inventory/inventory) / [store-requisition](/en/inventory/store-requisition)) and Auditor (read-only versioning / pricing-history / signature trace; compliance review) — directly drives in the recipe module. Unlike the four operational personas (Chef, Cost Controller, Outlet Manager, Procurement / F&B Ops) who work the happy-path lifecycle, the Audit / Config sub-roles act on the periphery: before any recipe exists (config), during the lifecycle (RBAC enforcement, integration health), and after publish (audit trace, signature verification). The Sysadmin has full read / write on configuration tables and the RBAC mapping; the Auditor is read-only on tb_recipe_version, tb_recipe_pricing_history, and the per-row audit columns. There is no "void" or "admin-cancel" path on the recipe — data hygiene on archived recipes after retention period is the only delete authority, and it sits with the Sysadmin per REC_AUTH_014. Scenarios are grouped into happy paths (category / cuisine / equipment masters; RBAC; tenant policy; integration health; auditor sample; auditor compliance review; soft-delete archived), RBAC (Sysadmin authority; auditor read-only), validation (negative tests around incomplete masters, in-flight orphaned references), and edge cases around multi-tenant configs, retention-period soft-delete, versioning chain reconstruction. Cross-persona handoffs that pivot off this persona (Scenarios 10, 11 in the parent overview) live in 04-test-scenarios.md, not here.
| # | Scenario | Pre-condition | Steps | Expected |
|---|---|---|---|---|
| AC-HP-01 | Sysadmin configures category master | Tenant onboarding; Sysadmin has full config authority. | 1. Open Sysadmin → Recipe Category Master. 2. Create category Mains (no parent, level 1). 3. Add sub-categories Premium Mains, Standard Mains (parent = Mains, level 2). 4. Set default_cost_settings per category (target food-cost %, labor / overhead percentages). 5. Save. |
tb_recipe_category rows persisted with hierarchy via parent_id; level populated correctly; new recipes in each category will inherit the default_cost_settings at create time. |
| AC-HP-02 | Sysadmin configures cuisine master | Tenant has cuisines Thai, Italian, French. |
1. Open Cuisine Master. 2. Create each cuisine with region tag (ASIA / EUROPE), popular_dishes, key_ingredients. 3. Save. |
tb_recipe_cuisines rows persisted; @@unique([name, deleted_at]) constraint prevents duplicates; region-tag enables region-based filtering. |
| AC-HP-03 | Sysadmin configures RBAC | Sysadmin assigns Executive Chef recipe:create / edit / publish / archive / edit-published on all categories; Pastry Chef on Desserts only; Cost Controller recipe:read / edit-cost / read-history on all; Outlet Manager recipe:read only. |
1. Open RBAC matrix. 2. For each role × category, set permissions. 3. Assign users to roles. 4. Save. | RBAC mapping persisted; permissions enforced on subsequent API calls per role / category scope; in-flight sessions refresh on next request. |
| AC-HP-04 | Sysadmin sets tenant policy (publish gate, edit-published, co-approval) | Tenant policy decisions: enable REC_AUTH_007 co-approval at 2-pp tolerance; enable edit_published_with_versioning = true (in-place edit on PUBLISHED). |
1. Open Tenant Policy. 2. Toggle publish_gate_off_target_co_approval = true; set off_target_tolerance_percentage_points = 2. 3. Toggle edit_published_with_versioning = true. 4. Save. |
Policy values persisted; subsequent publishes / edits gated per the policy; pre-existing recipes in flight may need re-evaluation under the new policy (manual coordination). |
| AC-HP-05 | Sysadmin wires integration | Confirm upstream and downstream coupling is operational. | 1. Open Integration Health dashboard. 2. Verify: vendor pricelist → product cost → recipe cost-drift chain (REC_XMOD_005 / REC_XMOD_006); recipe → SR auto-create (REC_XMOD_007); recipe → inventory theoretical OUT fan-out (REC_XMOD_003); recipe → menu-item linkage (REC_XMOD_008). 3. Run integration health-check probes. |
All chains report healthy; any failure surfaces an alert; Sysadmin investigates per chain (e.g. broken event listener on cost-drift, mis-wired POS endpoint on menu-item linkage). |
| AC-HP-06 | Auditor sample — verify versioning chain | Sample 30 PUBLISHED recipes for the audit period. |
1. Open Auditor → Recipe History view. 2. For each sampled recipe: verify tb_recipe_version chain (v1 at publication; v_n for each subsequent edit); verify published_at matches v1; verify off-target publishes have co-approval recorded in change_summary; verify cost / price changes have tb_recipe_pricing_history rows; verify audit columns (created_by_id / updated_by_id) are consistent. |
Per REC_AUTH_013. Auditor finds clean chain on 28 of 30 samples; 2 samples have audit findings (e.g. missing change_summary on an edit; missing pricing-history row on a cost-only edit) which are logged and escalated to Sysadmin / Cost Controller for investigation. |
| AC-HP-07 | Auditor compliance review on sub-recipe cascade | Sample 10 recipes whose tb_recipe_pricing_history.change_reason indicates a sub-recipe cascade. |
1. For each sampled recipe: trace the cascade chain from the parent recipe's pricing-history entry back to the sub-recipe's cost change back to the originating leaf-product cost update. 2. Verify the cascade math is internally consistent. 3. Verify post-cascade margin moves outside tolerance triggered a Cost Controller / Chef review (signoff or revision in tb_recipe_version). |
Cascade trace is internally consistent on all 10 samples; 3 samples where the post-cascade margin exceeded tolerance had appropriate Cost Controller review actions in the audit chain. |
| AC-HP-08 | Sysadmin soft-deletes archived recipe after retention | ARCHIVED recipe Holiday 2022 Special has been archived for 3 years (tenant retention policy: 2 years). |
1. Open archived recipes list. 2. Filter by archived_at < 2024-01-01. 3. Select recipes for soft-delete. 4. Bulk soft-delete. |
deleted_at populated on selected rows; rows remain in database (auditable); disappear from default queries; tb_recipe_version rows preserved (cascade-on-delete is not soft-aware). |
| # | Scenario | Expected behaviour (allow/deny + reason) |
|---|---|---|
| AC-PERM-01 | Sysadmin edits category / cuisine / equipment masters | Allow. Per REC_AUTH_012. Full write on master-data tables. |
| AC-PERM-02 | Sysadmin edits RBAC matrix | Allow. Per REC_AUTH_012. RBAC is Sysadmin-only. |
| AC-PERM-03 | Sysadmin edits tenant policy (publish gate, edit-published, co-approval tolerance) | Allow. Per REC_AUTH_012. |
| AC-PERM-04 | Sysadmin attempts to edit recipe ingredients / steps | Allow (typically) but unusual. Sysadmin technically has all permissions in a fully-privileged role; in practice they do not edit ingredients (that's the Chef's authority). Audit findings flag any Sysadmin write on recipe operational fields as anomalous. |
| AC-PERM-05 | Auditor reads tb_recipe_version history |
Allow. Per REC_AUTH_013. recipe:read-history permission. |
| AC-PERM-06 | Auditor reads tb_recipe_pricing_history |
Allow. Per REC_AUTH_013. |
| AC-PERM-07 | Auditor attempts any write | Deny — read-only. All write endpoints rejected with "Auditor role is read-only on the recipe library." |
| AC-PERM-08 | Sysadmin soft-deletes a PUBLISHED recipe |
Deny — must archive first. PUBLISHED recipes cannot be soft-deleted; must be archived per REC_AUTH_014. |
| AC-PERM-09 | Sysadmin soft-deletes an ARCHIVED recipe within retention period |
Deny — retention violation. Tenant retention policy blocks soft-delete of recipes archived within retention period; UI blocks the operation; direct API call returns "Cannot soft-delete recipe within retention period (archived less than N days ago)." |
| # | Scenario | Trigger | Expected error |
|---|---|---|---|
| AC-VAL-01 | Sysadmin attempts to soft-delete a category referenced by recipes | Category Mains is referenced by 50 PUBLISHED recipes; Sysadmin tries to soft-delete. |
Reject (FK Restrict + soft-delete application check). Server returns "Cannot delete category 'Mains' — it is referenced by 50 active recipes. Reassign recipes to a different category first." |
| AC-VAL-02 | Sysadmin attempts to delete a cuisine referenced by recipes | Similar to AC-VAL-01 for tb_recipe_cuisines. |
Reject. Server returns analogous error. |
| AC-VAL-03 | RBAC change orphans in-flight chef work | Sysadmin removes recipe:edit for Pastry Chef on Mains while 3 DRAFT recipes by the Pastry Chef are in Mains. |
Warn at save. UI surfaces: "This change orphans 3 in-flight DRAFT recipes by Pastry Chef in Mains. Proceed?" Sysadmin either accepts (orphaned recipes become read-only to Pastry Chef; need Executive Chef takeover) or cancels. |
| AC-VAL-04 | Tenant policy change creates inconsistent recipes | Sysadmin enables publish_gate_off_target_co_approval = true with tolerance 2pp; some PUBLISHED recipes are off-target at 5pp drift. |
Warn — pre-existing recipes grandfathered. Existing PUBLISHED recipes are not retroactively gated; new publishes / edits use the new policy. Sysadmin coordinates with Cost Control Department on whether to retroactively review off-target recipes. |
| AC-VAL-05 | Integration health check fails on theoretical-consumption fan-out | Recipe → inventory theoretical OUT chain broken (event listener crashed). | Alert. Health dashboard surfaces "Theoretical-consumption fan-out FAILING; menu sales not driving recipe-explosion movements." Sysadmin investigates and restarts the listener / fixes the integration. |
| AC-VAL-06 | Auditor finding — missing version row on edit | Auditor finds a recipe whose updated_at has changed multiple times since published_at, but the tb_recipe_version chain has only one row. |
Audit finding — investigate. The finding indicates either (a) versioning system gap (edits applied without writing version rows — Sysadmin investigates the service code) or (b) intended behaviour (e.g. pricing-only edits don't trigger version rows — verify the edits are all pricing-only via tb_recipe_pricing_history). |
| # | Scenario | Condition | Expected |
|---|---|---|---|
| AC-EDGE-01 | Multi-tenant config — per-tenant categories and policies | Tenant A has categories Appetiser / Main / Dessert; Tenant B has Starter / Course / Sweet. |
Per-tenant scoping via x-app-id header; recipe master data is tenant-scoped; queries filter by tenant; cross-tenant config leakage is blocked at the auth boundary. |
| AC-EDGE-02 | Bulk RBAC change across many users | Sysadmin reassigns 50 chefs to new category scopes (e.g. opening 3 new outlets with distinct chef teams). | Bulk operation completes; per-user RBAC saved; all in-flight sessions affected; coordination with HR / operations to communicate the change. |
| AC-EDGE-03 | Long-tail versioning chain | Recipe has 200+ tb_recipe_version rows over 5 years. |
All rows retained; UI paginates / lazy-loads version history; Auditor sample queries indexed appropriately on recipe_id + version_number; performance regression test confirms version browse within acceptable time. |
| AC-EDGE-04 | Auditor reconstructs historical state | Auditor needs to know what House Burger looked like 18 months ago for a compliance dispute. |
Auditor opens version history; selects the version active 18 months ago (by created_at); reads the JSON snapshot (recipe_data, ingredients_data, steps_data, variants_data); full historical recipe state reconstructed without affecting current state. |
| AC-EDGE-05 | Equipment master cleanup | Sysadmin retires old equipment (e.g. discontinued sous-vide rig); referenced in prep-step JSON on 12 recipes. | Sysadmin soft-deletes the equipment row (the prep-step references are JSON, not FK, so no schema-level block); Sysadmin coordinates with Chef to update the affected prep steps; or leaves the references in place as historical record. |
| AC-EDGE-06 | Retention-policy enforcement at scale | Tenant retention: archive 2 years, then soft-delete; 500 recipes archived 2 years ago. | Bulk soft-delete operation per REC_POST_009; UI permits batch selection; tb_recipe_version rows preserved (not cascade-deleted by soft-delete); recipes disappear from default queries; audit data preserved. |
| AC-EDGE-07 | Auditor cross-references recipe version with menu-item linkage history | Auditor wants to know which menu items were linked to recipe X at a specific historical date. | The recipe tb_recipe_version chain is one input; the POS-integration layer's linkage history is another (outside the recipe schema per REC_XMOD_008); Auditor joins the two for the historical reconstruction; if the POS layer doesn't preserve linkage history, that's an audit gap to escalate. |
| AC-EDGE-08 | Sysadmin investigates integration alert — [store-requisition](/en/inventory/store-requisition) auto-create failure |
Recipe-driven SR auto-create has been failing for 3 days; planned events have no SR drafts. | Sysadmin investigates the integration: confirms recipe module is firing events; confirms SR module is receiving but failing on create (e.g. permission issue, mis-configured destination location). Fix applied; backfill the missed SR drafts manually if needed. |
REC_AUTH_012 (Sysadmin authority), REC_AUTH_013 (Auditor read-only), REC_AUTH_014 (delete authority via soft-delete); Section 5 — REC_POST_009 (soft-delete posting effects); Section 6 — REC_XMOD_009 (versioning audit), REC_XMOD_010 (RBAC mapping).is_used_in_recipe flag on products that gates recipe eligibility.