metis-desk/docs/auditorias/workplace-dashboard/02-mapa-relaciones.md

Mapa de relaciones del puesto

Fecha: 22 de octubre de 2026. Etiquetas y catálogo de fuentes E: inventario. Las tablas describen implementación y DDL inspeccionados, no un esquema instalado consultado.

Relaciones directas y composición

Entidad	Relación y cardinalidad	Modelo/tabla y condición	API disponible	Uso actual
Compañía	Cada puesto pertenece a 1 compañía; compañía 0..N puestos	FK workstations.companyId → companies.id; filtros de contexto	Inventario Assets	Shell y URL
Sede	Puesto 0..1 sede; sede 0..N puestos	siteId → company_sites.id; validación de compañía E04	Compañía, inventario	Cabecera; enlace al listado
Responsable	Puesto 0..1 persona; persona 0..N puestos	personId → company_contacts.id; no exclusividad por persona	Compañía, inventario	Cabecera y panel Personas
Miembros	Puesto 0..200 activos actuales; activo como máximo 1 puesto activo	workstation_members; workstation_assets.activeKey reserva única	Inventario, comandos puesto	Equipamiento
Ordenador	Puesto 0..1 activo principal incluido en miembros	computerAssetId → assets.id; E02/E04	Inventario	Destacado; perfiles y software
Revisiones	Puesto 1..N revisiones	workstation_revisions.workstationId	En WorkstationDTO.history	Cronología
Miembros históricos	Revisión 0..200 activos; activo puede aparecer en N revisiones y puestos en el tiempo	workstation_revision_members	Valores de cada revisión	Nombres resueltos en historial
Actores	Revisión 1 usuario de aplicación; usuario 0..N revisiones	actorId → users.id; nombre resuelto E06	DTO de puesto	Autor de revisión

CONFIRMADO E05/E06/E07: workstation_assets es una proyección de todos los miembros alguna vez registrados, con reserva actual opcional. No usar sus filas como lista de activos actuales. Los miembros actuales proceden de workstation_members; los históricos, de cada revisión. Las relaciones están implementadas con FK y SQL parametrizado; no se localizaron asociaciones Sequelize belongsTo/hasMany para la raíz Workstation.

Personas, departamentos y tiempo

CONFIRMADO E09: la ficha selecciona perfiles cuyo companyId coincide y cuyo values.assetId es el computerAssetId actual. Incluye perfiles inactivos. Deduplica personas de esos perfiles y añade al responsable. Esto no identifica necesariamente ocupantes vigentes.

DERIVABLE: «usuarios actuales» puede definirse como personas de perfiles activos del ordenador actual, separadas del responsable. La decisión de excluir inactivos por defecto sería PROPUESTA, no conducta vigente de la ficha. La inversa personWorkstations ya distingue responsabilidad y uso, y para uso considera puestos y perfiles activos (E10).

No hay fechas de inicio/fin de ocupación en Workstation. Se puede reconstruir cuándo se registró un cambio de responsable mediante revisiones; no una asignación laboral efectiva. Sí existen asignaciones temporales a departamentos (company.assignments, E13): persona, departamento, startDate, endDate, cargo y isPrimary. Para mostrar departamento desde el puesto hay que escoger persona y fecha y evaluar el periodo; nunca convertirlo en departamento propio del puesto.

La sede del activo es independiente de la del puesto. No sobrescribir ni deducir igualdad. La persona del perfil tampoco es automáticamente «propietaria» del activo: AssetInputSchema no tiene personId.

Grafo funcional confirmado

Las líneas representan asociaciones por claves/condiciones comprobadas, no todas son FK. En particular, Puesto–Perfil es un join por ordenador y compañía; no hay workstationId en work_profiles.

flowchart TD
  Company[Compañía] -->|0..N| Station[Puesto: Workstation]
  Station -->|0..1 siteId| Site[Sede]
  Station -->|0..1 personId| Person[Persona responsable]
  Station -->|0..200 miembros exclusivos| Asset[Activo]
  Station -->|0..1 computerAssetId incluido| Computer[Activo principal]
  Station -->|1..N| Revision[Revisión de puesto]
  Revision -->|0..200 miembros de esa revisión| Asset
  Revision -->|actorId| Operator[Usuario de aplicación]
  Computer -.->|join por assetId y companyId: 0..N| Profile[Perfil de trabajo]
  Profile -->|1 personId| UserPerson[Persona del perfil]
  UserPerson -->|0..N asignaciones temporales| Department[Departamento]
  Profile -->|0..1 accountId| Account[Cuenta de acceso]
  Profile -->|0..N| Folder[FolderMapping]
  Folder -->|1 needId| Need[Necesidad de persona]
  Folder -->|0..1 accessAccountId| Account
  Need -->|1 resourceId| AccessResource[Recurso de Access]
  Need -->|0..N| Coverage[Cobertura]
  Coverage -->|grantId| Grant[Concesión a cuenta o grupo]
  Coverage -->|accountPersonId| AccountPerson[Asignación cuenta-persona]
  Coverage -->|0..1 membershipId| Membership[Pertenencia a grupo]
  AccountPerson --> Account
  Profile -->|0..N| Config[Correo, aplicación, certificado, impresora]
  Computer -->|0..N| Software[Instalación de software]
  Software -->|aplicación u OS; licencia opcional| Resource[Recurso del inventario]
  Asset -->|0..N publicaciones| Publication[Publicación SMB]
  Publication -->|1 recurso SMB; máximo 1 publicador activo por recurso| Resource
  Asset -->|0..N históricos| Local[Entorno de identidades locales]
  Asset -->|pertenencia de directorio| Domain[Recurso de dominio]
  Asset -->|0..N| Support[Conexión de soporte]
  Asset -->|0..1 configuración con revisiones| Infrastructure[Roles, interfaces y direcciones registradas]
  UserPerson -->|contexto de persona| Remote[Conexión remota y autorización de teletrabajo]
  Remote -->|origen/destino opcional según tipo| Asset
  UserPerson -->|0..N| Process[Proceso de alta, cambio o baja]

Equipamiento y relaciones entre activos

CONFIRMADO E14: los activos tienen plantillas, características y estados técnicos operational, broken, maintenance, retired; available/in_use son estados de presentación derivados de reserva, no salud online. Las revisiones pueden conservar estados antiguos.

Ordenador, monitor, teléfono o dispositivo de red son datos de plantilla/capacidad del activo. El puesto no dispone de una enumeración propia de funciones. La ficha actual llama «periféricos» a todos los miembros salvo el principal (E11); esa etiqueta no demuestra que todos lo sean.

PROPUESTO: agrupar por plantilla real y distinguir el ordenador principal. Las impresoras utilizadas por un perfil pueden ser compartidas y no estar en assetIds; deben ir en «Configuraciones del perfil», con su procedencia, sin incorporarlas al equipamiento exclusivo. Las relaciones genéricas AssetRelationship (inventario relationships) pueden aportar enlaces, pero no transfieren pertenencia, asignación, permisos ni conectividad transitiva.

Cambiar computerAssetId cambia inmediatamente los perfiles y software seleccionados por la ficha. Sus registros siguen vinculados al activo anterior. Desmantelar el puesto no mueve ni desactiva esos registros. Una cronología que muestre «todos los perfiles históricos del puesto» exigiría una regla temporal adicional y no puede derivarse solo del filtro actual.

Recursos, accesos y SMB

Recorrido	Significado y cardinalidad	Fuente / tablas / API	Clasificación para el dashboard
Puesto → ordenador → perfiles	0..N perfiles del host, cada perfil 1 persona/activo y 0..1 cuenta	E09/E15; work_profiles, revisiones; /api/work-profiles/:companyId	DERIVABLE, contexto de perfil
Perfil → FolderMapping → need → resource	0..N mapeos; cada uno 1 necesidad de la misma persona del perfil	E17/E18; folder_mappings, access_items; /api/folder-mappings/:companyId, /api/access/:scope	Carpeta configurada en ese perfil, no todos los recursos del responsable
Mapping → cuenta elegida	0..1 cuenta, independiente de cuenta de inicio de sesión del perfil	accessAccountId; folderAccountUsable, folderAccountCoverage	Mantener separadas cuenta del perfil y cuenta de acceso a carpeta
Persona → need → coverage → grant	N necesidades y coberturas; concesión a cuenta XOR grupo	E16/E18; access_items, access_references, revisiones	Contexto de autorización documental; no comprobación real contra servidor SMB
Cuenta → account_person → persona	Asignaciones temporales; cuenta compartida admite varias personas según política	AccessPolicy, accessConflict	No atribuir todos sus permisos al puesto
Cuenta → membership → grupo → grant	Pertenencias y concesiones con periodo y configuración	E16/E18	Respetar configuración, vigencia y catálogo activo
Recurso inventariado → integración Access	Recurso con integration.kind=access, tipo y referencia	E19; ResourceIntegrationSchema, escritor de Access; resources y access_items	Resolver la identidad mediante integración; no unir por nombre
Activo → publicación SMB → recurso	Publicador 0..N recursos; recurso máximo 1 publicador activo	E20; asset_network_share_publications; /api/asset-network-share-publications/:companyId	Publicar no concede acceso ni prueba consumo desde el puesto
Perfil → aplicación/certificado/correo/impresora	Cada configuración pertenece a 1 perfil; recurso/buzón/activo destino según tipo	E21; tablas específicas, revisiones y APIs homónimas	Configuraciones contextualizadas, distintas de software instalado en el equipo
Perfil → correo → buzón → uso de persona	Configuración referencia buzón; autorización exige uso vigente de ese buzón por la persona del perfil	E36; mailboxes, mailbox_uses, revisiones; /api/mailboxes/:companyId; mailAuthorized	No inferir acceso a todos los buzones por usar un equipo

AccessWorkspace es un agregado de accesos global o de compañía. No representa un escritorio ni un puesto y no debe enlazarse a Workstation por su nombre (E16).

FolderMappingSchema ya expone permissionsCovered, accessAccountCoverage (unknown, covered, not-covered) y needsReview. folderAccountCoverage filtra por la cuenta elegida y por necesidades/vías pertinentes. Reutilizar esos resultados; no reducir autorización a state === configured. folderAvailable comprueba también persona/perfil/activo/recurso, coincidencia de ruta, catálogo y fechas.

Las publicaciones SMB son explícitas, con inicio, fin, actores y predecessor; el host de una UNC no sustituye esa relación. La referencia canónica SMB y la cobertura son dimensiones separadas. No mostrar «acceso efectivo comprobado»: no se inspeccionaron conexiones reales a SMB ni credenciales.

Conectividad, dominios y entornos

Capacidad	Evidencia	Qué puede afirmarse
Autorización de teletrabajo	CONFIRMADO, TeleworkAuthorizationInputSchema, DTO con status, effective, needsReview; E23	Pertenece a persona; fechas opcionales. No prueba que esté trabajando en remoto
Conexión remota	CONFIRMADO, E22	Persona; origen equipo de compañía/ordenador personal/móvil personal; destino red/activo/recurso; método libre, requiresVpn, configuración y revisión
VPN	CONFIRMADO como booleano en conexión remota y soporte	No hay agregado VPN, túnel activo, credenciales ni telemetría de conexión localizados en contratos inspeccionados
Soporte remoto del activo	CONFIRMADO, E24	Herramienta/recurso, destino, VPN requerida, preferencia, estado; no equivale a autorización de teletrabajo
Interfaces y direcciones de red	CONFIRMADO, E35	Activo 0..1 agregado de infraestructura, 0..32 interfaces y 0..32 direcciones por interfaz; tipo ethernet/wifi/other, MAC, IPv4/IPv6, notas, roles e historial. No prueba conexión actual
Entorno local	CONFIRMADO, E25	access_local_identity_environments: ciclo de vida que vincula entorno Access y activo con identityScope=local-device
Directorio corporativo	CONFIRMADO, E26	DirectoryMembership une activo y recurso de dominio con rol e historial; no demuestra conexión online
Portátil corporativo	DERIVABLE de plantilla/capacidad de activo y compañía	No es una modalidad de Workstation ni prueba movilidad efectiva
Presencia/remoto actual, topología y conectividad online	NO DISPONIBLE en puesto, conexiones/soporte e inventarios inspeccionados	No dibujar mapas de red, estado «conectado» ni ubicación física actual como hechos

Para conexiones remotas: mostrar por separado «conexiones que usan este equipo» (sourceAssetId o destino activo) y «contexto de esta persona» (personId). No asumir que todas las conexiones de una persona usan el ordenador del puesto. Una autorización documental tampoco asegura acceso real a recursos.

Infraestructura persiste en asset_infrastructure, asset_infrastructure_revisions, asset_infrastructure_roles, asset_interface_snapshots y asset_interface_address_snapshots. Tiene FK de compañía/activo, revisiones ordenadas e identidad para interfaces/direcciones. Sus roles son network, server, storage, shared_peripheral; no clasifican el puesto ni convierten un activo en miembro compartido. Puede mostrarse como detalle técnico del equipo sin inventar una topología física.

Tickets, procesos e historial

DOCUMENTADO y CONFIRMADO en composición activa: tickets, intervenciones y plantillas de intervención se retiraron. Se buscaron ticket, incidencia, intervention, workplace y workstationId en módulos, apps y paquetes activos; se contrastaron composition roots, mapa de rutas y remove-archived-support-tables.ts. docs/funcionalidades-archivadas.md describe el código conservado en archive/tickets-and-interventions. No se propone restaurarlo.

NO DISPONIBLE: panel de tickets/incidencias/solicitudes del puesto como capacidad activa. Omitirlo del mockup de capacidades actuales; no mostrar un cero que sugiera un módulo operativo vacío.

CONFIRMADO E27: los procesos de persona (onboarding, change, offboarding) tienen tareas con referencias a perfil, activo, cuenta, necesidad y configuraciones. No admiten referencia tipada workstation. DERIVABLE: localizar procesos de personas relacionadas o tareas que refieran activos/perfiles, explicando la vía. No llamarlos incidencias ni cambios automáticos del puesto.

La actividad propia segura es workstation.history: instantáneas de creación y cambios registrados. Se puede comparar semánticamente cada revisión con la anterior para resumir cambios (DERIVABLE). Los nombres de personas/sedes/activos se resuelven con datos actuales: no prometer fidelidad histórica de sus etiquetas. Un feed combinado de revisiones de varias entidades requeriría agregación, identificadores de origen, deduplicación y una política temporal; queda PROPUESTO.

Discrepancia documental

docs/rutas-del-cliente.md aún describe puestos que agrupan activos «exclusivos o compartidos». El código actual elimina miembros shared y reconstruye únicamente exclusive (E07). Para esta propuesta prevalece la implementación contrastada y se registra la discrepancia sin modificar la guía ajena al alcance.