David
ded45e1c42
test: implement resource template propagation tests for resource revisions feat: create prepareResourceTemplateUpdates function for handling resource template updates feat: add resource revision specifications for managing resource revisions in the database test: add tests for entity column visibility and local storage handling feat: implement entity column visibility storage for managing column preferences feat: create synchronizeTemplateStructure utility for managing template field and section synchronization
29 lines
3.7 KiB
Markdown
29 lines
3.7 KiB
Markdown
# 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`.
|