groombook/web
13
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

feat(GRO-2319): dev→uat — live StatusBadge palette (web) (#70)
CI / Test (pull_request) Successful in 24s
Details
CI / Lint & Typecheck (pull_request) Successful in 31s
Details
CI / Build & Push Docker Image (pull_request) Successful in 11s
Details

Browse Source
This commit is contained in:
Flea Flicker
2026-06-09 11:04:15 +00:00
committed by Flea Flicker
parent 7ef270312c
commit 3bfcf0b970
3 changed files with 118 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
UAT_PLAYBOOK.md
+19
View File
@@ -217,6 +217,25 @@ export const { signIn, signOut, useSession, changePassword } = authClient;
| TC-WEB-5.12.16 | Badge status from data | Compare badge label to appointment.status field | Badge label matches the API appointment status exactly |
| TC-WEB-5.12.17 | Unknown status fallback | Render badge with unknown status value | Badge renders with the raw status string as label and fallback CSS class |
#### 5.12f Live StatusBadge palette — no-show / pending / waitlisted (GRO-2319)
These cases exercise the full StatusBadge palette as it is now produced live by
the seeded UAT customer (`uat-customer@groombook.dev`), not just unit-rendered.
| # | Scenario | Steps | Expected |
|---|----------|-------|----------|
| TC-WEB-5.12.26 | No-show badge (item 1) | Sign in as `uat-customer@groombook.dev`, open `Appointments` → **Past** tab, find the seeded `no_show` appointment | A styled yellow **"No-show"** badge renders (`bg-yellow-100 text-yellow-700`) — **not** a raw gray `no_show` label. The DB `no_show` (underscore) status is normalized to the `no-show` palette key. |
| TC-WEB-5.12.27 | Pending derivation (item 2) | On the **Upcoming** tab, find the seeded upcoming appointment whose `confirmationStatus` is `pending` (groomer-unconfirmed) | The card's top-row badge reads amber **"Pending"** (derived from `confirmationStatus`), even though the raw appointment status is `scheduled`. |
| TC-WEB-5.12.28 | Confirmed not overridden | On the **Upcoming** tab, find the seeded confirmed appointment (`confirmationStatus = confirmed`) | Badge still reads green **"Confirmed"** — the pending derivation does not override a confirmed appointment. |
| TC-WEB-5.12.29 | Waitlisted card (item 2) | On the **Upcoming** tab, find the seeded waitlist entry for the customer | A card renders with a blue **"Waitlisted"** badge, a **dashed muted border**, and the subtext _"You're on the waitlist — we'll let you know if a spot opens."_ The Confirm / Reschedule / Cancel / Notes actions are **not** shown for this entry (it is not a booked appointment). |
> **GRO-2319 note:** the DB `appointment_status` enum cannot represent `pending`
> or `waitlisted`, so those badges are derived in the portal: `pending` from an
> upcoming appointment's `confirmationStatus`, and `waitlisted` from active
> `waitlist_entries` surfaced by `GET /api/portal/appointments` as synthetic
> cards. The `no_show` → `no-show` key normalization fixes the cosmetic badge
> mismatch (item 1).
#### 5.12d Appointment API Shape Normalization (GRO-2180)
| # | Scenario | Steps | Expected |