32 lines
4.5 KiB
Markdown
32 lines
4.5 KiB
Markdown
|
# Software del ordenador
|
||
|
|
|
||
|
|
## Uso
|
||
|
|
|
||
|
|
La ficha de un puesto muestra **Software del ordenador**, asociado a su ordenador principal. Permite registrar el sistema operativo actual y las aplicaciones instaladas para el equipo, sin exigir persona ni perfil. Dos perfiles del mismo equipo consultan la misma instalación; cambiar el responsable no cambia el software. Al sustituir el ordenador principal, la ficha consulta las instalaciones del equipo nuevo y conserva las del anterior.
|
||
|
|
|
||
|
|
El sistema operativo es un recurso de la plantilla global **Sistema operativo**, con proveedor, edición y descripción; las copias y plantillas propias admiten uso explícito `os`. Las aplicaciones usan el recurso de uso `application`. La versión/build concreta pertenece a la instalación; el producto y edición pertenecen al recurso. Se aceptan varias instalaciones de sistemas operativos distintos (por ejemplo, arranque dual); no se deduce su tipo por el nombre ni se guarda el SO actual en las características del activo. El SO de fábrica sigue describiendo la compra original.
|
||
|
|
|
||
|
|
El alta y la edición utilizan modal. Hay altas rápidas para sistema operativo y aplicación reutilizando el editor de recursos sin un tercer nivel de formularios. Cancelar el hijo conserva el padre; un recurso ya guardado permanece aunque se cancele la instalación. El listado reutiliza EntityListHeader, EntityTable, acciones por fila y paginación compartida, con búsqueda, columnas, ordenación, inclusión de cerradas y limpiar filtros. Recurso enlaza a su ficha.
|
||
|
|
|
||
|
|
## Relación con perfiles
|
||
|
|
|
||
|
|
La instalación del ordenador y la disponibilidad de una aplicación para una persona son relaciones distintas. El bloque de aplicaciones del perfil conserva sus registros, forma de uso y versiones; puede representar aplicaciones web o instalaciones propias de ese usuario. No se generan instalaciones de equipo a partir de registros antiguos porque no documentan ese ámbito. Tampoco se crean aplicaciones en todos los perfiles por registrar software en el equipo. No se instalan programas ni se asignan o consumen licencias automáticamente.
|
||
|
|
|
||
|
|
## Reglas
|
||
|
|
|
||
|
|
La pareja ordenador/recurso es fija y solo admite una instalación abierta. Una cerrada permite un nuevo registro. Se comparte el ciclo ya existente: pendiente → configurado o nunca configurado; configurado → pendiente de retirar → retirado. Los estados terminales no se editan. Las notas pueden completarse mientras se revisa o retira una instalación.
|
||
|
|
|
||
|
|
El servidor comprueba pertenencia a compañía, tipo de recurso, disponibilidad del activo y actividad del recurso. Las altas o reconfiguraciones pendientes/configuradas exigen referencias disponibles; retirar y completar notas sigue siendo posible si el activo está retirado o el recurso inactivo. Se conserva historial y aparece un aviso de revisión. Eliminar corrige un alta por error y elimina también sus revisiones, con confirmación explícita en la interfaz.
|
||
|
|
|
||
|
|
## Persistencia y API
|
||
|
|
|
||
|
|
SoftwareInstallation es un agregado, con SoftwareInstallationValues y revisiones con UUID propio. `software_installations` y `software_installation_revisions` guardan columnas tradicionales: compañía, activo, recurso, versión, estado, notas, actor y fecha. Claves foráneas protegen referencias, una clave nullable única protege la pareja abierta y el índice de revisiones protege su orden. No se persiste JSON.
|
||
|
|
|
||
|
|
Migración explícita e idempotente al inicializar el módulo. Las escrituras se serializan con el bloqueo de compañía y guardan raíz/revisiones dentro de la misma transacción. Una actualización semánticamente equivalente no añade revisión. El mapper comprueba identidad, pareja fija, fechas, transiciones, última revisión y clave abierta.
|
||
|
|
|
||
|
|
`GET /api/software-installations/:companyId` consulta todas las instalaciones de la compañía; la ficha filtra por ordenador. `POST` crea; `POST /:companyId/:id/update` edita; `POST /:companyId/:id/delete` elimina. Sesión obligatoria, validación estricta, origen y CSRF en escrituras; actor tomado de la sesión. La auditoría central continúa como entrega independiente.
|
||
|
|
|
||
|
|
## Verificación
|
||
|
|
|
||
|
|
Pruebas de dominio y persistencia: referencias, SO/aplicaciones, duplicados, ámbito, identidad fija, idempotencia, versiones, revisión, transiciones e historial corrupto. Pruebas HTTP con MariaDB: migración repetida, concurrencia, CSRF/origen, compañía ajena, versiones históricas, recursos inactivos, retirada y eliminación. Pruebas de interfaz es/en: filtrado por ordenador, enlaces, versiones, ausencia de formularios incrustados y ayuda.
|