feat(GRO-2319): surface active waitlist entries on portal appointments + seed
CI / Test (pull_request) Successful in 27s
CI / Lint & Typecheck (pull_request) Successful in 33s
CI / Build & Push Docker Images (pull_request) Successful in 1m24s

- GET /api/portal/appointments now also returns the client's ACTIVE
  waitlist_entries as synthetic `waitlisted` cards (id prefixed `waitlist:`,
  status hard-set to waitlisted, startTime derived from preferred date/time)
  so the portal can render Waitlisted cards in the Upcoming list (item 2).
- Seed one active waitlist entry for the UAT customer. waitlist_entries is
  NOT truncated on the hourly reset, so the entry is upserted by fixed id and
  its preferred date refreshed to a future-relative value each reset to stay
  Upcoming. (The existing scheduled row already carries confirmationStatus
  pending, which drives the live Pending badge.)
- portal.test.ts: GET /portal/appointments waitlist-surfacing tests.
- UAT_PLAYBOOK.md TC-API-8.19 for the surfaced waitlist entries.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
This commit is contained in:
Flea Flicker
2026-06-09 10:37:47 +00:00
parent d61607f4c5
commit 7523263072
4 changed files with 165 additions and 9 deletions
+1
View File
@@ -287,6 +287,7 @@ This means:
| TC-API-8.16 | Portal pet update — malformed (non-UUID) petId returns 404 (GRO-2203) | With a valid portal session, `PATCH /api/portal/pets/not-a-uuid` with header `X-Impersonation-Session-Id` and body `{"coatType":"short"}` | 404 Not Found with body `{"error":"Not found"}` (was an unhandled 500 from the Postgres uuid cast in GRO-2203; mirrors the GRO-2014 guard). No mutation persisted |
| TC-API-8.17 | SSO portal session slides on activity (GRO-2234) | Establish a portal session (TC-API-8.8). Note the returned `sessionId`. Make any authenticated portal call (e.g. `GET /api/portal/me`) several times spaced over ≥1 minute, each with `X-Impersonation-Session-Id: {sessionId}`. | Every call returns 200; the session's `expiresAt` is extended (slid forward to ~30 min from each request) so the session stays valid during continuous use — it does NOT lapse mid-session. SSO-bridge sessions mint with a 30-min idle TTL bounded by an 8h absolute cap from `startedAt`. |
| TC-API-8.18 | Slow-wizard Book New submit succeeds (GRO-2234) | Establish a portal session (TC-API-8.8). Wait >2 minutes while making at least one intervening authenticated portal call (mimicking the multi-step Book New wizard: pet/service/groomer/date GETs). Then `POST /api/portal/waitlist` with a valid pet+service payload and the same `X-Impersonation-Session-Id`. | 201 Created — the deliberately-paced wizard no longer 401s on submit because activity slid the session forward. (Regression guard for the GRO-2234 "session TTL too short → 401" defect.) |
| TC-API-8.19 | Portal appointments surface active waitlist entries (GRO-2319) | As `uat-customer@groombook.dev`, establish a portal session, then `GET /api/portal/appointments`. | 200 OK. In addition to the customer's appointments, the response includes the seeded ACTIVE waitlist entry as a synthetic card: `status: "waitlisted"`, `id` prefixed `waitlist:`, `confirmationStatus: null`, a non-null derived `startTime` (from the entry's preferred date/time), and the entry's `pet`. Cancelled/notified/expired waitlist entries are NOT surfaced. |
### 4.9 Waitlist