dmolinari/SIG-CM2.0
1
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases Wiki Activity

[ADM-001] Cascada de inactividad: medio inactivo debe congelar secciones (y productos) hijas #16

New Issue
Closed
opened 2026-04-17 13:26:41 +00:00 by dmolinari · 0 comments
dmolinari commented 2026-04-17 13:26:41 +00:00
Owner
Copy Link

Contexto

Durante el smoke test de ADM-001 (PR #15), se detectó una inconsistencia: al desactivar un Medio, el admin puede seguir editando/desactivando/reactivando las Secciones de ese Medio. Tampoco bloquea operaciones sobre entidades futuras más abajo en la jerarquía (Productos, Avisos, Tarifarios, etc.).

La spec REQ-SEC-001 ya valida que un create de Sección sobre un Medio inactivo devuelva 404, pero REQ-SEC-002 (update), REQ-SEC-003 (deactivate/reactivate) y REQ-SEC-004 (list — por default activo=true) no extienden esa regla al padre. Es una zona gris de la spec.

Decisión (usuario, 2026-04-17)

Opción B — Congelamiento total en cascada: si Medio.Activo = false, TODA mutación sobre entidades de jerarquía menor (Seccion + Producto + lo que venga en ADM-003/PRD-/PRC-/VTA-*) debe rechazarse con 409 medio_inactivo. Solo reactivar el Medio libera la cascada.

Razonamiento: "Si el medio se desactiva es porque no se debe utilizar ni editar; sus secciones y productos deben tomar la misma lógica por menor jerarquía."

Alcance propuesto

Inmediato (Secciones — esta UDT o próxima)

  • SeccionRepository / handlers: validar Medio.Activo = true antes de update, deactivate, reactivate (además del create ya validado).
  • Nueva excepción MedioInactivoException + mapping en ExceptionFilter → 409 medio_inactivo.
  • Integration tests: update/deactivate/reactivate sobre Seccion cuyo Medio está inactivo → 409, sin AuditEvent.
  • Frontend: SeccionesListPage / detail muestra un banner "Medio desactivado — operaciones bloqueadas" cuando medio.activo = false; botones Edit/Deactivate/Reactivate disabled.
  • Actualizar spec de secciones-management en engram para formalizar la regla (convertir la zona gris en requirement explícito).

Cascada futura (cuando aparezcan esas entidades)

  • PRD-002 Producto: mismo patrón de cascada desde Medio → Categoría → Producto.
  • PRC-003/004 Tarifarios: no permitir editar tarifas de un medio inactivo.
  • VTA-/FAC-: no permitir avisos/facturas sobre un medio inactivo (pero mantener lectura histórica).

Decisión adicional requerida en el momento

  • Reactivación: cuando se reactiva el Medio, ¿las Secciones que se desactivaron durante el periodo inactivo vuelven solas o quedan manualmente reactivables? → sugiero manual (menos sorpresas).
  • Read-only vs 409: para operaciones de escritura en frontend, ¿mostrar controles disabled + tooltip (UX amigable) o devolver 409 cuando el usuario igual lo intenta vía API directa? → ambas; el 409 es la barrera real, el disabled es la ayuda UI.

Referencias

  • PR origen: ADM-001: Medios y Secciones (fundacional) (#15)
  • Engram: sdd/adm-001-medios-secciones/{spec,design,archive-report}
  • Related files:
    • src/api/SIGCM2.Application/Secciones/Update/UpdateSeccionCommandHandler.cs
    • src/api/SIGCM2.Application/Secciones/{Deactivate,Reactivate}/*Handler.cs
    • src/api/SIGCM2.Api/Filters/ExceptionFilter.cs
    • src/web/src/features/secciones/pages/SeccionesListPage.tsx

Prioridad

Alta — es regla transversal de dominio (cascada de inactividad) que va a impactar a todas las UDTs de fase 2 en adelante. Mejor resolverla antes de que CAT-/PRD-/VTA-* arranquen para que reusen el patrón.

## Contexto Durante el smoke test de ADM-001 (PR #15), se detectó una inconsistencia: al **desactivar un Medio**, el admin puede **seguir editando/desactivando/reactivando las Secciones** de ese Medio. Tampoco bloquea operaciones sobre entidades futuras más abajo en la jerarquía (Productos, Avisos, Tarifarios, etc.). La spec **REQ-SEC-001** ya valida que un *create* de Sección sobre un Medio inactivo devuelva 404, pero **REQ-SEC-002 (update)**, **REQ-SEC-003 (deactivate/reactivate)** y REQ-SEC-004 (list — por default `activo=true`) **no extienden esa regla al padre**. Es una zona gris de la spec. ## Decisión (usuario, 2026-04-17) **Opción B — Congelamiento total en cascada**: si `Medio.Activo = false`, TODA mutación sobre entidades de jerarquía menor (Seccion + Producto + lo que venga en ADM-003/PRD-*/PRC-*/VTA-*) debe rechazarse con `409 medio_inactivo`. Solo reactivar el Medio libera la cascada. Razonamiento: *"Si el medio se desactiva es porque no se debe utilizar ni editar; sus secciones y productos deben tomar la misma lógica por menor jerarquía."* ## Alcance propuesto ### Inmediato (Secciones — esta UDT o próxima) - [ ] `SeccionRepository` / handlers: validar `Medio.Activo = true` antes de `update`, `deactivate`, `reactivate` (además del `create` ya validado). - [ ] Nueva excepción `MedioInactivoException` + mapping en `ExceptionFilter` → `409 medio_inactivo`. - [ ] Integration tests: update/deactivate/reactivate sobre Seccion cuyo Medio está inactivo → 409, sin AuditEvent. - [ ] Frontend: `SeccionesListPage` / detail muestra un banner "Medio desactivado — operaciones bloqueadas" cuando `medio.activo = false`; botones Edit/Deactivate/Reactivate disabled. - [ ] Actualizar `spec` de `secciones-management` en engram para formalizar la regla (convertir la zona gris en requirement explícito). ### Cascada futura (cuando aparezcan esas entidades) - [ ] PRD-002 Producto: mismo patrón de cascada desde Medio → Categoría → Producto. - [ ] PRC-003/004 Tarifarios: no permitir editar tarifas de un medio inactivo. - [ ] VTA-*/FAC-*: no permitir avisos/facturas sobre un medio inactivo (pero mantener lectura histórica). ### Decisión adicional requerida en el momento - **Reactivación**: cuando se reactiva el Medio, ¿las Secciones que se desactivaron durante el periodo inactivo vuelven solas o quedan manualmente reactivables? → sugiero manual (menos sorpresas). - **Read-only vs 409**: para operaciones de escritura en frontend, ¿mostrar controles disabled + tooltip (UX amigable) o devolver 409 cuando el usuario igual lo intenta vía API directa? → ambas; el 409 es la barrera real, el disabled es la ayuda UI. ## Referencias - PR origen: #15 - Engram: `sdd/adm-001-medios-secciones/{spec,design,archive-report}` - Related files: - `src/api/SIGCM2.Application/Secciones/Update/UpdateSeccionCommandHandler.cs` - `src/api/SIGCM2.Application/Secciones/{Deactivate,Reactivate}/*Handler.cs` - `src/api/SIGCM2.Api/Filters/ExceptionFilter.cs` - `src/web/src/features/secciones/pages/SeccionesListPage.tsx` ## Prioridad **Alta** — es regla transversal de dominio (cascada de inactividad) que va a impactar a todas las UDTs de fase 2 en adelante. Mejor resolverla antes de que CAT-*/PRD-*/VTA-* arranquen para que reusen el patrón.
dmolinari added the followup label 2026-04-17 13:26:57 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
followup
Deuda técnica o mejora detectada en un UDT, a retomar en otro futuro. Revisar al empezar cada UDT.
No Label followup
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dmolinari
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dmolinari/SIG-CM2.0#16
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?