34 lines
1.7 KiB
Markdown
34 lines
1.7 KiB
Markdown
# F-153 — Product Spec
|
|
|
|
## Problem
|
|
The order read model and its serialization (`serializeOrder`) do **not** expose
|
|
the linked customer's email. `orders_orders.user_id` references `identity_users`
|
|
(whose `email citext NOT NULL UNIQUE` always exists), but the order view carries
|
|
only `userId` — never the email. Consequence:
|
|
- Order detail (`/orders/:id`, `/orders/:id/admin`) and the admin order list
|
|
(`/orders`) never display the customer email ("customer email missing ... displayed").
|
|
- The admin force-transition (`POST /orders/:id/transitions/admin`) works around
|
|
this with a fragile inline `SELECT email FROM identity_users WHERE id =
|
|
order.userId`, which surfaces "El cliente no tiene email asociado" whenever the
|
|
view itself doesn't carry the association.
|
|
|
|
## Goal
|
|
Associate the linked customer's email to the **order read model** and display it in
|
|
serialization — detail, admin list, and the admin force-transition notification —
|
|
using the order view as the single source of truth.
|
|
|
|
## Scope IN
|
|
- `orders/domain`: add `email` to `OrderView` (read model).
|
|
- `orders/infrastructure` (pg-order-repository): JOIN `identity_users` to resolve
|
|
`email` on every order read (`findById`, `findByIdAndUserId`, `findAll`, `search`).
|
|
- `orders/api` (orders.routes): surface `email` in `serializeOrder` and consume
|
|
`order.email` in the admin force-transition notification (removing the inline lookup).
|
|
|
|
## Scope OUT
|
|
- No changes to the `identity` domain (no TS cross-import).
|
|
- No new tables / migrations: `identity_users.email` already exists and is NOT NULL.
|
|
- No new endpoints; no auth/RBAC change; no order state machine change.
|
|
|
|
## Risk / Priority
|
|
- Priority: high. Risk: med (additive read-model field; backward compatible).
|