Diagram stanów
Klik w węzeł → detail
Transitions + gates
| Transition | Gate |
|---|---|
→
|
Per-state endpoint matrix
Co aplikacja zwraca dla każdego endpointu × stan. Implementuje {Machine}StateMiddleware.
| Endpoint | |
|---|---|
|
Schema additions (migration 007)
design/007_lifecycle_states.sql
Cross-state interactions (z `lifecycle_state_machines_v1.md` sekcja 4)
Tenant suspend → Restaurants effective paused
Middleware `TenantStateMiddleware` PRZED `RestaurantStateMiddleware`. Tenant `suspended` → wszystkie placement 503 niezależnie od stanu restauracji. Rollback-friendly: po resume, restauracje wracają do swoich stanów bez batch UPDATE.
Customer erasure → Orders snapshot
Anonimizacja zostawia orders + items + addresses w bazie (snapshot pricing → 5 lat księgowe). customer_id → anonim_id, telefon/email/imię redacted. Restaurant_user/admin nie widzi pierwotnego imienia.
Restaurant close → Outstanding KSeF settlement
Auto-lock period current week + final invoice generation. Email do owner z settlement summary. closed state nadal allowed dla in-flight orders w status [placed, accepted, preparing, ready_for_pickup, picked_up].
Order modification + customer state
Customer `restricted` (Art. 18) NIE może placement, ALE może modyfikować swoje wcześniej złożone orders w window pre-accept (jeśli restauracja nie potwierdziła). Defense-in-depth: middleware sprawdza order.customer_id + customer.lifecycle_state przy każdej akcji.
Source: design/lifecycle_state_machines_v1.md (691 LOC) ·
Migration: design/007_lifecycle_states.sql ·
← Wróć