48 lines
2.7 KiB
Markdown
48 lines
2.7 KiB
Markdown
|
# Sedes de compañía
|
||
|
|
|
||
|
|
Cada sede pertenece a una compañía y conserva su UUID, nombre, dirección y teléfono.
|
||
|
|
El estado `active` distingue sedes disponibles y archivadas. La migración explícita
|
||
|
|
`migrateCompanies` añade la columna relacional no nullable y mantiene activas las sedes
|
||
|
|
existentes; puede volver a ejecutarse sin reinicializar los estados.
|
||
|
|
|
||
|
|
## Archivo y reactivación
|
||
|
|
|
||
|
|
El listado muestra las sedes activas por defecto. «Mostrar también las sedes archivadas»
|
||
|
|
permite consultar y reactivar las anteriores. El menú de fila ofrece Archivar/Reactivar,
|
||
|
|
Editar y Eliminar sede; el formulario de edición también permite cambiar el estado.
|
||
|
|
|
||
|
|
Archivar no borra ni desvincula datos. La sede sigue resolviéndose en fichas e historiales.
|
||
|
|
Los selectores de activos, puestos y destinos de red ofrecen solo sedes activas y, al
|
||
|
|
editar, la sede anterior aunque esté archivada. El servidor aplica el mismo contrato:
|
||
|
|
permite conservar la referencia anterior y rechaza nuevas asociaciones a sedes archivadas.
|
||
|
|
En accesos remotos el destino sigue siendo inmutable.
|
||
|
|
|
||
|
|
## Borrado definitivo
|
||
|
|
|
||
|
|
`POST /api/companies/:companyId/sites/:id/delete` recibe un objeto vacío y devuelve la
|
||
|
|
compañía actualizada. Requiere la misma sesión y protección CSRF que las demás escrituras
|
||
|
|
sobre compañías; valida UUID, pertenencia, cuerpo y ausencia de query adicional.
|
||
|
|
|
||
|
|
La operación bloquea la compañía dentro de una transacción y elimina exclusivamente
|
||
|
|
la sede solicitada. Las claves foráneas `RESTRICT` impiden borrar sedes referenciadas,
|
||
|
|
incluidas revisiones históricas de activos, puestos y accesos remotos. No se propagan
|
||
|
|
borrados ni se limpian referencias para permitir la eliminación. Una referencia produce
|
||
|
|
`409 SITE_IN_USE` y el diálogo propone archivar; una sede ausente o de otra compañía
|
||
|
|
produce `404 SITE_NOT_FOUND`. Repetir un borrado no genera otros efectos.
|
||
|
|
|
||
|
|
Los fallos de infraestructura distintos de una restricción referencial se propagan al
|
||
|
|
manejador HTTP común. La interfaz mantiene el diálogo abierto si el borrado falla y
|
||
|
|
actualiza la caché de la compañía únicamente tras confirmar la operación.
|
||
|
|
|
||
|
|
## Validación
|
||
|
|
|
||
|
|
La prueba aislada `apps/server/src/sites.integration.test.ts` usa MariaDB y comprueba
|
||
|
|
persistencia, repetición de migración, referencias con FK y borrado tras liberar las
|
||
|
|
asociaciones. Solo crea y limpia sus propios registros en la base de pruebas.
|
||
|
|
|
||
|
|
Las pruebas de dominio cubren archivo, reactivación, identidad y repetición del estado.
|
||
|
|
Las pruebas web comprueban textos es/en, el filtro inicial y el control de estado.
|
||
|
|
`apps/server/src/sites.integration.ts`, invocado por la suite HTTP/MariaDB, comprueba
|
||
|
|
validación, pertenencia, borrado de una sede vacía, conservación de referencias,
|
||
|
|
restricciones históricas y rechazo de nuevas asociaciones a sedes archivadas.
|