refinement phase 2
This commit is contained in:
@@ -93,7 +93,12 @@ delivers fixes in its own change. **Frontend never edits backend code to "fix" a
|
||||
app. If the backend intends to persist a "current role", the router should prefer it. Also note: verify_otp
|
||||
returns `roles` but no user `id` (only `/me` has it) — fine for now (context id is hydrated from `/me`),
|
||||
flagging in case that changes.
|
||||
- **Status:** open
|
||||
- **Resolution (refinement-phase-2, 2026-07-13):** **The client owns the active-role choice** — `MeResult`
|
||||
will *not* gain an `activeRole`. A dual customer+nurse session is disambiguated by the client-carried
|
||||
intended role (the A1 vs B1 login switch), defaulting to the family app; `RoleGuard` lets a dual-role user
|
||||
move freely between shells. No server change needed. If the backend ever wants to persist a "current role",
|
||||
file a new REQ and the router will prefer it. **Confirmed the `/me` `id`-hydration note still holds.**
|
||||
- **Status:** resolved (client owns it; no backend change)
|
||||
|
||||
## REQ-008 — Accept the client-picked map pin on address create/update — filed by frontend-phase-3-b4 — 2026-07-02
|
||||
- **Need:** Let `customer_addresses/create` and `customer_addresses/update/{id}` accept optional
|
||||
@@ -579,4 +584,19 @@ delivers fixes in its own change. **Frontend never edits backend code to "fix" a
|
||||
DTO. The client defaults to `[]` meanwhile. `services/reviews` moderation methods are mock-primary; `moderateReview`
|
||||
maps the live `PATCH reviews/{id}/status` and the queue maps `GET admin/reviews/moderation_queue`.
|
||||
- **Why:** moderators see the tags a review carries before publishing/hiding.
|
||||
|
||||
## REQ-038 — Signal on `/me` that the caller administers a partner center (partner auto-routing) — filed by refinement-phase-2 — 2026-07-13
|
||||
- **Need:** add a boolean/id on `MeResult` — e.g. `administersPartnerCenterId: number | null` (or a plain
|
||||
`isPartnerCenterAdmin: bool`) — indicating the signed-in user is the admin of a `partner_center`.
|
||||
- **Why:** the partner portal (`/partner`) is a **separate authz scope** — a center admin is not a Balinyaar
|
||||
admin, and partner-ness is **not** derivable from `me.roles`. So `resolveRoleDestination` (the login role
|
||||
router) can't route a partner admin to `/partner` on login the way it routes customer/nurse/admin. Today
|
||||
`/partner` is only reachable by **direct navigation** (in dev the `services/partnerCenter` mock resolves a
|
||||
center for `useMyPartnerCenter`, so the shell renders instead of access-denied); there is no seeded real
|
||||
partner-center↔user association and no `/me`-level signal, so login→`/partner` can't be delivered. With this
|
||||
field the router gains a partner branch and the demo seed can associate a phone user with a seeded center.
|
||||
- **Proposed shape:** `MeResult.administersPartnerCenterId?: number | null`; when non-null,
|
||||
`resolveRoleDestination` routes to `ROUTES.PARTNER`. Pair with a Development seed (a partner-center + a
|
||||
`demo_partner_*` phone user linked as its admin) so the actor is reachable end-to-end like the others.
|
||||
- **Status:** open (partner login-routing deferred; `/partner` reachable by direct nav + the partnerCenter mock)
|
||||
- **Status:** open
|
||||
|
||||
Reference in New Issue
Block a user