Feature #398
openIPD: DietaryOrder reads Admins diet-type catalog instead of a fixed enum (Part 3 of 4)
0%
Description
Part 3 of the Dietetics/Nutrition workflow (Part 1: Admin, #388; Part 2: HR, #390). Safe, purely-additive expand step per ADR-0002: added a nullable DietTypeCode string column to DietaryOrder alongside the existing (untouched) DietType enum column -- zero risk to existing admission records. When a caller supplies DietTypeCode, DietaryOrderService validates it against Admins active diet-type catalog for the hospital (case-insensitive) and rejects an unknown code at the source instead of letting it silently accrue Rs0 downstream -- the exact failure mode already found and fixed twice this session. An unreachable Admin degrades to the legacy enum path rather than blocking order placement. Old callers that only send DietType keep working unchanged, and now also get DietTypeCode populated going forward. DietaryOrderLookupService (feeds Canteen/Billing) prefers DietTypeCode when present. New GET /api/ipd/dietary-orders/diet-types endpoint exposes Admins live catalog for the order form. Also brought the branch current with devs 26 commits and fixed two unrelated pre-existing kernel gaps from the already-merged doctor-module work that blocked the build (Redmine #397, separate commit). Full suite 1751/1751 green, including the new Testcontainers-backed migration.