← back to index

V0.5 — Bulk Delete + Deactivate on Cashiers + RegistersPROD

Narong's Telegram, 2026-05-29 evening (right after Item #3l ship): "mass remove the cashiers as well" + Karou's clarification + "we already have deactivate/activate so im assuming its same as archive — so we can just add delete." Extends V0.3's bulk-archive pattern to two more surfaces (Team>Cashiers + Configurations>Registers), with hard-delete enabled per-row + bulk when the row has 0 sales attributed AND no active session. Decisions locked WITHOUT Narong by Karou's Q1-Q4 answers.

Summary

Status: 14/14 prod · 51/51 regression = 65/65 · shipped
Commit: nix-cafe d4b1edb
Files: 7 modified + 1 new · ~1180 LOC · no migration
Eligibility: Cashier deletable iff salesCount === 0 && !inActiveSession (R8.4 active_session_token IS NULL). Register deletable iff salesCount === 0 && !hasOpenSession

What ships

Bulk Delete + Bulk Deactivate on Cashiers (gated nix_cafe.team.edit); existing per-row Deactivate stays as the Archive equivalent.
Bulk Delete + Deactivate + Reactivate on Registers (gated nix_cafe.settings.edit); 3-button floating bar shows counts based on selection state.
Per-row Delete button on both pages — disabled with tooltip when row is ineligible.
Eligibility surfaced inline: cashiers show "N sales" under name; registers show "· N sales" inline. Computed via correlated subqueries on cafe.orders + cafe.sessions (raw qualified column refs — Drizzle's ${...} interpolation strips table prefix inside subqueries and Postgres mis-resolves).
Shared <BulkActionConfirmDialog> with two modes: simple confirm (all eligible) vs blocked surface (mixed eligibility). Blocked surface lists ineligible rows with per-row reason ("12 sales" / "in active session" / "has open session") + a Deselect ineligible button that drops them from the selection. Q2-C semantics — confirm is hidden until selection is fully eligible.
Server-side eligibility re-verify in every bulk action (never trust client). Refusal returns structured ineligible array so the dialog can re-render the breakdown if the eligibility raced (e.g. another user opened a shift between page render and the user's submit).
Tx-wrapped register Delete deletes child sessions in the same transaction to satisfy cafe.sessions.pos_config_id ON DELETE RESTRICT. cafe.cash_movements.session_id ON DELETE CASCADE handles the cash_movements automatically.
Audit log: cashiers.bulk_deleted / .bulk_deactivated / registers.bulk_deleted / .bulk_deactivated / .bulk_reactivated — one summary row per call (matches U12 + Item #3l pattern; bulk of 50 cashiers ≠ 50 audit rows).

14/14 prod checks ✓

✓	Pre-flight: clean any V0_5 pollution from prior runs
✓	Seed 3 cashiers on lumiere: clean / in-active-session (`active_session_token=uuid`) / with-sales (throwaway order attributed via `cashier_pin_id`)
✓	SSO login
✓	/cafe/team Cashiers tab renders with checkbox column + per-row state: clean Delete enabled, sales+session Delete disabled with reason tooltip, "1 sale" badge under sales cashier name
✓	Select all 3 + Bulk Delete → confirm dialog refuses with blocked surface: lists 2 ineligible (1 in_session, 1 has_sales "1 sale") + no Confirm button shown (Q2-C — must deselect first)
✓	Click "Deselect ineligible" → dialog closes + selection narrows to 1 (clean only)
✓	Bulk Delete (eligible-only) → confirm dialog with single-row breakdown → Confirm → success → DB verifies: clean GONE, sales + session STILL THERE (refused-correctly check)
✓	Bulk Deactivate the 2 ineligible (always succeeds — no eligibility check) → DB confirms `is_active=false` on both
✓	Seed 2 registers: clean + with-open-session
✓	/cafe/pos/registers shows new registers with correct eligibility — clean Delete enabled, open-session Delete disabled
✓	Bulk Delete clean register → confirm → DB verifies: clean GONE, open-session STILL THERE
✓	Audit log: 3 expected actions written (cashiers.bulk_deleted + cashiers.bulk_deactivated + registers.bulk_deleted) within last 5 min for lumiere tenant
✓	Cleanup test pollution (cashiers + sessions + order + remaining register)
✓	No 5xx during the suite

Screenshots (click to enlarge)

Mid-Gate finds

Drizzle correlated-subquery interpolation — sql\`WHERE pos_config_id = ${schema.cafePosConfigs.id}\` generates WHERE pos_config_id = "id" (table prefix stripped). Inside a subquery referencing cafe.sessions, Postgres resolved "id" to sessions.id instead of pos_configs.id — so EXISTS always returned false. Fix: use raw qualified column names (cafe.pos_configs.id) in the subquery body. Applied to 4 subqueries across pin_identities.ts + pos_configs.ts.
Wide-replace miss — first SQL fix only caught 1 of 2 callsites (listRegistersForShop); the second copy in fetchRegisterEligibility was outside the comment-anchored old_string. Caught by Gate 1 round 2.
Cross-tenant guard test — initial probe used "get-coffee" which isn't seeded locally. Switched to fake-UUID-tenant approach — tests the exact guard semantics without needing 2 real tenants.
Tab-button selector guesswork — Gate 2 first run failed waiting for cashier-table-body because /cafe/team defaults to Members tab. My guessed selectors (:has-text("Cashiers")) didn't bind correctly. Fix: use the actual data-testid="tab-cashiers". Saved durable rule [[feedback_grep_testids_before_guessing]] re-validated.
React state batching after checkbox click — register-bulk-bar didn't appear immediately after page.click(checkbox). Added a 500ms wait before next waitForSelector.

Regression sweep — 51/51 ✓

14/14 + 51/51 = 65/65 prod tests green on the karouna-dev branch.

test-phase1-prod.mjs	11/11
test-phase2-sso-outdoor-prod.mjs	6/6
test-m1-prod.mjs	10/10
test-r7-prod.mjs	14/14
test-r8-prod.mjs	4/4
test-phase2-cafe-multishop-prod.mjs	6/6