Feature #659
openProduction: diet-type recipe assignment -- the cook sheet had no way to be filled in
0%
Description
The cook sheet showed all zeros / "Nothing planned for today yet" even with real patient diet orders on the ward meal sheet. Traced through MealSheetService -> ProductionPlanService.GenerateForSheetAsync, which needs a DietTypeRecipeAssignment row (diet type x meal slot -> recipe) for every pairing it plans. canteen.diet_type_recipe_assignments was empty for every tenant: the entity, EF config and migration existed (added 2026-10-09), but no service, controller or page ever wrote to it.
Added the missing write path: SetupService.GetDietTypeRecipeAssignmentsAsync cross-joins Admin's active diet types against the hospital's meal slots, left-joining any existing assignment; AssignRecipeAsync upserts, UnassignRecipeAsync archives (no hard deletes). New Kitchen-gated DietTypeRecipeAssignmentsController at /api/canteen/kitchen/diet-type-recipe-assignments (same split reasoning as KitchenMealSlotsController), reusing the existing recipes.read/update permission keys.
Also found and fixed a second bug in the lookup itself: ProductionPlanService matched MealSheetLine.DietTypeCode against the assignment's DietTypeCode case-sensitively, but the assignment is always stored upper-cased while a sheet line's code arrives verbatim from the live sync ("Soft"/"SOFT" both exist for the same hospital) -- every patient whose line didn't already match the stored case was silently skipped. Fixed with StringComparer.OrdinalIgnoreCase, with a regression test.
A portal page was initially added (Kitchen > Diet recipe mapping) but removed in a follow-up once it was confirmed the prototype has no such page -- the backend stays (it's still the only write path for the assignment), reachable directly over the API; only the portal route, nav entry and query hooks came back out.
11 new SetupServiceTests, 6 new authorization-matrix tests, 1 ProductionPlanService regression test, 3 frontend tests for the slot-grouping helper, all passing. 1043/1045 backend (only the two pre-existing date-fragile Coupon_liability tests failing), 582/582 frontend.
Commits (pushed under the wrong Redmine number, #398, a separate already-resolved issue -- corrected here): 0d5dec8, 786edbd.