25 lines
1.3 KiB
Markdown
25 lines
1.3 KiB
Markdown
# D5.3.7.2.4 — Protección de planes obsoletos e idempotencia
|
|
|
|
Versión: `0.19.3-7.2.4`.
|
|
|
|
## Objetivo
|
|
|
|
Evitar que un plan READY generado contra un estado anterior del Maestro pueda aplicarse después de que otro lote o una edición administrativa haya modificado los datos maestros.
|
|
|
|
## Cambios
|
|
|
|
- El plan guarda `masterStateHash` dentro de su resumen.
|
|
- El hash representa el estado relevante de activos, organizaciones, Departamentos, relaciones operativas, derechos y IDs externos.
|
|
- La generación toma una huella antes y después de construir el plan; si el Maestro cambia durante la generación, se aborta.
|
|
- La aplicación compara la huella actual contra la guardada **antes de cualquier escritura**.
|
|
- Los planes READY de versiones anteriores, que no tienen huella, se consideran obsoletos y deben regenerarse.
|
|
- El frontend muestra `Plan obsoleto` y deshabilita `Confirmar y aplicar` hasta regenerar.
|
|
|
|
## Caso real cubierto
|
|
|
|
Si un lote A aplica 64 Áreas, 12 Organizaciones, 230 Yacimientos y sus relaciones mientras existe un lote B con un plan READY anterior, el lote B ya no puede volver a crear esas entidades. Debe conciliar y regenerar; el nuevo plan debe resolverlas como coincidencias.
|
|
|
|
## Migraciones
|
|
|
|
No agrega migraciones. La huella se almacena en el JSON `summary` ya existente del plan.
|