[PRD-001 / Frontend] ProductTypesPage.openEdit() debe fetchear ProductTypeDetail antes de precargar el form #37

New Issue

dmolinari · 2026-04-19T15:17:32Z

dmolinari commented

2026-04-19 15:17:32 +00:00

Contexto

Detectado durante re-verify de PRD-001 (post W3 fix, PR en preparación).

En src/web/src/features/product-types/pages/ProductTypesPage.tsx, la función openEdit(pt: ProductTypeListItem) mapea el ListItem a un ProductTypeDetail con los campos multimedia en null. Si un ProductType tiene allowImages: true con límites almacenados (MaxImages, MaxImageSizeMB, MaxImageWidth, MaxImageHeight), abrir el edit dialog muestra esos campos vacíos/disabled y al guardar se sobrescriben silenciosamente con null.

Impacto

Riesgo práctico actual: BAJO. Pre-PRD-008 (seed de 12 tipos legacy) no existen ProductTypes con multimedia limits configurados en producción. El bug es dormant.

Riesgo a partir de PRD-008 / uso real: ALTO. Un admin editando un tipo con multimedia config cargada perdería esa configuración sin advertencia.

Fix propuesto

Usar el hook useProductType(id) (ya implementado y actualmente sin consumers) para fetchear el detalle completo antes de abrir el dialog en modo edit.

Opciones:

Opción A (recomendada): En openEdit, invocar queryClient.fetchQuery con la queryKey de useProductType(id) y esperar el resultado antes de abrir el dialog. Mientras carga, mostrar spinner o disable del botón. Limpio, no cambia API.
Opción B: Cambiar el endpoint list (GET /api/v1/product-types) para incluir todos los campos multimedia. Ahorra una llamada pero acopla el ListItem al detalle.
Opción C: Mover a /admin/product-types/:id/edit route dedicada que hace fetch por sí misma (patrón página vs dialog). Mayor cambio.

Preferencia: Opción A — mínima invasividad, usa el hook que ya existe.

Criterios de aceptación

Click en Edit de una fila hace fetch de ProductTypeDetail antes de abrir el dialog (loading state visible o botón disabled durante fetch)
El form precarga correctamente los campos multimedia cuando allowImages: true
Guardar sin tocar los campos multimedia NO los sobrescribe con null
Tests frontend para el flow: click Edit → espera fetch → dialog abre con datos completos → save envía los mismos valores
No rompe los 390 tests frontend existentes

Prioridad

Antes de PRD-008 (seed de tipos legacy) o antes del primer admin creando/editando tipos con multimedia en producción — lo que ocurra primero.

Artifacts

Verify-report PRD-001 (engram): sdd/prd-001-product-type-flags-multimedia/verify-report — sección "openEdit Deviation Assessment"
Archive-report PRD-001 (engram): sdd/prd-001-product-type-flags-multimedia/archive-report (cuando se genere)
PR PRD-001: (link al crear)

## Contexto Detectado durante re-verify de PRD-001 (post W3 fix, PR en preparación). En `src/web/src/features/product-types/pages/ProductTypesPage.tsx`, la función `openEdit(pt: ProductTypeListItem)` mapea el `ListItem` a un `ProductTypeDetail` con los campos multimedia en `null`. Si un `ProductType` tiene `allowImages: true` con límites almacenados (`MaxImages`, `MaxImageSizeMB`, `MaxImageWidth`, `MaxImageHeight`), abrir el edit dialog muestra esos campos vacíos/disabled y al guardar se **sobrescriben silenciosamente con null**. ## Impacto **Riesgo práctico actual**: BAJO. Pre-PRD-008 (seed de 12 tipos legacy) no existen `ProductTypes` con multimedia limits configurados en producción. El bug es dormant. **Riesgo a partir de PRD-008 / uso real**: ALTO. Un admin editando un tipo con multimedia config cargada perdería esa configuración sin advertencia. ## Fix propuesto Usar el hook `useProductType(id)` (ya implementado y actualmente sin consumers) para fetchear el detalle completo antes de abrir el dialog en modo edit. Opciones: 1. **Opción A (recomendada)**: En `openEdit`, invocar `queryClient.fetchQuery` con la queryKey de `useProductType(id)` y esperar el resultado antes de abrir el dialog. Mientras carga, mostrar spinner o disable del botón. Limpio, no cambia API. 2. **Opción B**: Cambiar el endpoint list (`GET /api/v1/product-types`) para incluir todos los campos multimedia. Ahorra una llamada pero acopla el ListItem al detalle. 3. **Opción C**: Mover a `/admin/product-types/:id/edit` route dedicada que hace fetch por sí misma (patrón página vs dialog). Mayor cambio. Preferencia: **Opción A** — mínima invasividad, usa el hook que ya existe. ## Criterios de aceptación - [ ] Click en Edit de una fila hace fetch de `ProductTypeDetail` antes de abrir el dialog (loading state visible o botón disabled durante fetch) - [ ] El form precarga correctamente los campos multimedia cuando `allowImages: true` - [ ] Guardar sin tocar los campos multimedia NO los sobrescribe con null - [ ] Tests frontend para el flow: click Edit → espera fetch → dialog abre con datos completos → save envía los mismos valores - [ ] No rompe los 390 tests frontend existentes ## Prioridad Antes de PRD-008 (seed de tipos legacy) o antes del primer admin creando/editando tipos con multimedia en producción — lo que ocurra primero. ## Artifacts - Verify-report PRD-001 (engram): `sdd/prd-001-product-type-flags-multimedia/verify-report` — sección "openEdit Deviation Assessment" - Archive-report PRD-001 (engram): `sdd/prd-001-product-type-flags-multimedia/archive-report` (cuando se genere) - PR PRD-001: (link al crear)

dmolinari added the followup label 2026-04-19 15:17:32 +00:00

dmolinari referenced this issue

2026-04-19 15:18:47 +00:00

feat: PRD-001 ProductType (flags + multimedia) #38

dmolinari referenced this issue

2026-04-19 15:21:17 +00:00

ProductTypesPage: openEdit() should fetch full ProductTypeDetail before populating form #39

dmolinari referenced this issue from a commit

2026-04-19 19:53:33 +00:00

fix(frontend): openEdit fetch ProductTypeDetail antes de abrir dialog (closes #37)

dmolinari referenced a pull request that will close this issue

2026-04-19 19:53:43 +00:00