fix(GRO-2342): portal waitlist card populates service {id, name} #208
Reference in New Issue
Block a user
Delete Branch "feat/GRO-2342-portal-waitlist-servicename"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
GRO-2342 (Phase 1: feature → dev) — Portal: waitlist card service {id, name}
Cosmetic follow-up to GRO-2319 (Phase 4 CTO review). The synthetic waitlist card on
GET /api/portal/appointmentsreturnedservice: {id}only, so the portal fell back to the literal 'Service' label. CMPO spec did not call for a service name on the waitlist card; populating the real name is non-urgent but closes the cosmetic gap.Changes
src/routes/portal.tsGET /portal/appointments— include aservicesSELECT (in addition topetsandstaff) covering both appointment and waitlistserviceId. A newserviceMapfeeds aservice.namelookup. The synthetic waitlist card'sserviceobject is now{id, name}— same shape the appointments join returns. The appointments join also gains a name (consistent shape, no regression for the existing path; the web portal'sserviceName: raw.service?.name ?? raw.serviceNamemapping is unchanged).src/__tests__/portal.test.ts— mock theservicestable and assertservice: {id, name}on both the synthetic waitlist card and the appointment card (TC-API-8.20 GRO-2342).UAT_PLAYBOOK.md— TC-API-8.20 covering the waitlist card service name. TC-API-8.19 (GRO-2319 surfacing contract) retained verbatim.Why this is a follow-up and not a blocker
Per the GRO-2319 thread, the waitlist card's primary signals are the Waitlisted badge + the waitlist subtext (CMPO spec). Falling back to 'Service' is a cosmetic gap, not a functional regression. UAT regression GRO-2341 (PASS 5/5) didn't cover this because the CMPO sign-off excluded the service name.
Out of scope
service.name.Standard SDLC follow-up
groombook/infra(4-line kustomization edit)🪒 Self-merge after CI passes (Phase 1, no reviewer required).
Cosmetic follow-up to GRO-2319 (Phase 4 review by CTO). The synthetic waitlist card on GET /portal/appointments returned service: {id} only, so the portal fell back to the literal 'Service' label. CMPO spec did not call for a service name on the waitlist card, but populating the real name is non-urgent and closes the cosmetic gap. - src/routes/portal.ts: include a services SELECT (in addition to pets and staff) covering both appointment and waitlist serviceIds. serviceMap feeds a service.name lookup. The synthetic waitlist card's service object is now {id, name} — same shape the appointments join returns — so the portal renders the real name. The appointments join also gains a name (consistent shape, no regression for the existing path). - src/__tests__/portal.test.ts: mock the services table and assert service: {id, name} on both the synthetic waitlist card and the appointment card. - UAT_PLAYBOOK.md: TC-API-8.20 covering the waitlist card service name (TC-API-8.19 retained verbatim for the original GRO-2319 surfacing contract). Co-Authored-By: Paperclip <noreply@paperclip.ing>