metis-desk/docs/sincronizacion-de-plantillas.md

Sincronización de plantillas de activos y recursos

Guardar una plantilla actualiza la estructura de todos los activos o recursos que la utilizan. Una plantilla global afecta a todas sus compañías; una plantilla propia afecta a sus registros. No cambia la plantilla asignada ni se mezclan campos por nombre: se utiliza su UUID.

• Se incorporan secciones y campos nuevos y se aplica el orden de la plantilla.
• Los campos retirados vacíos desaparecen de la ficha actual. Ausencia, null y texto vacío o solo espacios se consideran vacíos; cero y false son valores que se conservan.
• Los campos retirados con valor permanecen, después de los campos actuales de la plantilla, y dejan de ser obligatorios. Sus secciones retiradas se conservan mientras contengan campos retenidos. Las secciones vigentes mantienen el orden de la plantilla y las conservadas se añaden al final.
• Si se elimina una sección y la plantilla deja sus campos sin sección, las fichas conservan en la sección anterior los campos que tengan valor. Mover expresamente un campo a otra sección vigente sí aplica la nueva ubicación.
• Los nombres de secciones conservadas se desambiguan cuando coinciden con una sección nueva. No se unen identidades distintas por tener el mismo nombre.
• Los campos de integración de buzones y accesos se conservan aunque estén vacíos, para mantener válidas sus referencias funcionales.
• Un campo obligatorio nuevo queda pendiente; la siguiente edición del registro exige completarlo. La sincronización no fabrica valores.
• Los límites del editor de plantillas siguen vigentes; las especificaciones de fichas pueden superarlos por conservar datos de campos retirados.

Cada cambio efectivo crea una revisión con el usuario autenticado y fecha UTC. Repetir una modificación equivalente no añade revisiones. Las revisiones conservan valores y estructura originales, incluidos nombres, tipos, opciones y orden. La interfaz de historial utiliza esa estructura histórica.

La actualización del catálogo y de todas las fichas afectadas se ejecuta en una transacción, con bloqueo del catálogo y de las compañías afectadas. Se preparan las nuevas especificaciones antes de escribir. Un fallo de validación o persistencia impide guardar parcialmente el cambio. La disponibilidad de una plantilla no elimina datos ni impide sincronizar registros existentes.

Persistencia y arranque

Las tablas de especificaciones actuales siguen siendo asset_specification_* y resource_specification_*. Cada revisión añade su estructura en cuatro tablas relacionales: *_revision_specifications, *_revision_specification_sections, *_revision_specification_fields y *_revision_specification_choices.

El arranque ejecuta migraciones explícitas e idempotentes antes de servir el inventario. Primero copian las especificaciones originales a las revisiones existentes; en activos, sustituyen la referencia de características históricas a la estructura actual por una referencia a los campos de su propia revisión. No se reescriben los valores históricos. Reiniciar no duplica instantáneas.

La inicialización de definiciones de serie no representa una edición de usuario y no propaga estructuras ni crea revisiones de negocio. Las ediciones desde HTTP pasan siempre el usuario de sesión al caso de uso.

Verificación

Las pruebas de dominio cubren incorporación, orden, retirada con y sin valor, conservación de cero y false, campos obligatorios nuevos, limpieza posterior, identidades, límites e idempotencia. Las pruebas MariaDB comprueban ambos módulos, dos compañías, lectura histórica y rollback ante un fallo durante la segunda actualización. Utilizan tablas aisladas en metis_desk_test.