metis-desk/docs/auditorias/workplace-dashboard/04-arquitectura-informacion.md

Arquitectura de información propuesta

Fecha: 22 de octubre de 2026. PROPUESTO: esta organización prepara un mockup posterior; no describe un dashboard implementado. Fuentes de los datos: inventario y relaciones.

Preguntas y prioridades

Audiencia asumida: técnico de soporte consultando un puesto concreto. No hay evidencia de entrevistas ni de preferencias de otros roles. Diseñar un resumen operativo de datos registrados, sin sugerir monitorización en tiempo real.

Nivel	Pregunta	Contenido	Justificación
1. Inmediato	¿Qué puesto y qué equipo estoy atendiendo?	Compañía, nombre, estado del puesto, sede, responsable, ordenador principal y estado técnico de este	Evita actuar sobre una compañía/equipo equivocados
1. Inmediato	¿Hay algo registrado que deba revisar?	Perfiles con needsReview; configuraciones pendientes o en revisión, cuando sus consultas estén completas	Reutiliza señales reales; no sintetiza una salud global
2. Operativo	¿Quién lo usa y con qué entorno?	Perfiles y personas; responsable diferenciado; cuenta y resumen de configuraciones por perfil	El ordenador puede servir a varias personas; no hay un ocupante único inferible
2. Operativo	¿Qué equipamiento y software tiene?	Composición actual, plantilla, estado, software del principal y licencia vinculada	Lo necesario para localizar fichas y preparar intervención
2. Operativo	¿Qué recursos están configurados aquí?	Carpetas, correo, aplicaciones, certificados e impresoras de cada perfil	Explica la procedencia y evita atribuir permisos de persona al puesto
2. Operativo	¿Cómo se presta soporte?	Conexiones de soporte del principal, y acceso a su gestión	Pertenece al equipo y facilita consulta técnica; no iniciar conexiones ficticias
3. Secundario	¿Qué contexto organizativo/remoto hay?	Departamento temporal de la persona, teletrabajo, conexiones remotas, identidades locales, dominio	Información indirecta y con sus propias reglas de vigencia
3. Secundario	¿Qué cambió?	Última revisión y acceso al historial completo; procesos vinculados por contexto si se decide incluirlos	Mantiene trazabilidad sin convertir todas las revisiones de otras entidades en actividad propia

La primera vista debe distinguir «estado del puesto», «estado técnico del equipo» y «configuración registrada». No usar un único semáforo «Todo correcto».

Composición recomendada

1. Cabecera de identidad: retorno, contexto de compañía, nombre, estado, sede y responsable explícito aunque esté ausente. Editar como acción principal; menú de ciclo de vida, conservando confirmaciones.
2. Resumen del ordenador y señales de revisión: nombre enlazado, plantilla, estado técnico; resumen de relaciones y señales verificadas. Si no hay ordenador, explicación y acción de completar, sin aparentar error de sistema.
3. Personas y perfiles: perfiles activos primero, con acceso a archivados; responsable independiente. Tabla con perfil, persona, cuenta, estado, revisión y acceso al entorno. La cuenta necesita Access para resolver su etiqueta.
4. Equipamiento: ordenador principal distinguido y lista compacta del resto, agrupación opcional por plantilla. No repetir una tarjeta completa del principal si ya está descrito arriba.
5. Software del ordenador principal: resumen con nombre, versión, licencia y estado, y detalle mediante el panel existente. Diferenciar instalaciones de equipo y aplicaciones configuradas por perfil.
6. Configuraciones por perfil: selector o filtro de perfil explícito, agrupación de carpetas/correo/apps/certificados/impresoras. Mostrar persona y perfil de origen incluso cuando se use una lista agregada.
7. Soporte y contexto técnico: soporte del equipo como bloque operativo; dominio, entorno local y conexiones remotas como detalle contextual, sin mezclar publicación SMB y carpetas consumidas.
8. Último cambio e historial: vista breve de la última revisión; historial íntegro en sección secundaria. No llamarlo «actividad en directo».

Los bloques sin datos se compactan con su motivo y acción pertinente. Los bloques que no existen en el producto (tickets, salud online) se omiten. Un fallo de consulta conserva el bloque con estado recuperable.

Catálogo de widgets candidatos

Todos los componentes sugeridos deben respetar sus APIs reales; E31/E32 identifica las primitivas inspeccionadas. No hay necesidad demostrada de un componente genérico DashboardWidget.

Widget	Información y decisión	Fuente de datos	Componente sugerido	Prioridad	Viabilidad
Identidad	Reconocer puesto y ámbito	Workstation + Company	Cabecera actual, EntityStatus, BrowserLink, WorkstationActions	1	Reutilización directa y composición
Equipo principal	Identificar host y abrirlo	computerAssetId, AssetDTO	AssetSummaryCard o resumen con DetailField	1	Adaptación menor
Relaciones resumidas	Saber cuánto detalle hay y abrirlo	Miembros, perfiles y personas deduplicados	Contadores de DetailPanel; StatisticCard solo si aporta navegación clara	1–2	Adaptación menor; fórmula definida abajo
Revisión registrada	Localizar perfiles/configuraciones con problemas documentados	DTO needsReview, configuración	Texto/estado con icono y enlace; componentes de estado existentes	1–2	Agregación nueva; no nuevo dato de dominio
Perfiles y usuarios	Comparar persona/cuenta/estado	profileApi + Company + Access	WorkstationProfiles/EntityTable, PersonAvatar	2	Extensión de composición actual
Equipamiento compacto	Comparar miembros al crecer	Inventario + especificaciones	EntityTable, BrowserLink, EntityStatus	2	Adaptación menor; conserva acciones de modal
Software	Consultar instalación y licencia	softwareApi + Resource Inventory + catálogo	SoftwareInstallationsPanel, resumen reducido	2	Panel reutilizable; resumen requiere adaptación
Configuraciones por perfil	Detectar pendientes y navegar	Cinco APIs; DTO de revisión/cobertura	Lógica buildEnvironment, EnvironmentSection como referencia, DetailPanel, EntityTable	2	Integración nueva; evitar copiar su UI completa
Soporte	Consultar destino/herramienta registrados	Support API por activo	AssetSupport	2	Reutilizable, pero revisar acciones y dependencias antes de incrustar
Contexto remoto	Distinguir conexiones de equipo y persona	remoteApi + teleworkApi	RemoteSummary, TeleworkAuthorizationSummary	3	Nuevos filtros y etiquetas de procedencia
Publicaciones / directorio / entorno local	Entender servicios y ámbito del activo	APIs paginadas específicas	Componentes de relación existentes de Assets; sublista compacta	3	Integración dirigida; sin consultas por tarjeta
Última revisión	Saber cuándo cambió el puesto	history del puesto	TimeLine, WorkstationHistory	3, resumen breve visible	Adaptación menor
Procesos relacionados	Consultar trabajo de persona o referencias a activos/perfiles	Process API	Enlaces al proceso y lista contextual	3, opcional	Agregación nueva; no imprescindible para primera versión
Salud, uptime, tickets, tendencias	Sin fuentes activas pertinentes	Ninguna confirmada	Ninguno	Fuera	Funcionalidad no soportada; no simular

Fórmulas de contadores

PROPUESTO, salvo el número actual de miembros de la ficha. Calcular solo tras carga satisfactoria, con ámbito de compañía verificado. Si hay paginación parcial indicar «cargados» o no mostrar total; nunca items.length como total universal.

Etiqueta	Fórmula y alcance
Activos del puesto	Cardinalidad del conjunto values.assetIds; incluye principal una vez. No sumar impresoras configuradas o activos históricos
Perfiles actuales	Perfiles de misma compañía, assetId === computerAssetId y active === true
Personas usuarias actuales	Distintos personId de los perfiles actuales. No sumar al responsable si no tiene perfil
Personas relacionadas	Unión deduplicada de responsable y personas de todos los perfiles del host; reproduce selección actual, pero no equivale a uso vigente
Perfiles en revisión	Perfiles actuales con needsReview === true; es señal de referencia, no incidencia
Configuraciones pendientes	Filas de las cinco familias con profileId en perfiles actuales y state === pending; identidad por familia + id
Retiradas pendientes	Misma población, state === removal_pending
Configuraciones en revisión	Misma población abierta, con needsReview; cobertura insuficiente de carpeta se puede indicar separadamente. No sumar como categorías excluyentes
Software configurado	Instalaciones del principal con state === configured; distinguir de aplicaciones de perfil
Último cambio	Última revisión del puesto, no máximo de todas las revisiones de la compañía

La señal de revisión puede solaparse con pendiente/configurado: no representar esas cantidades como porciones de un total. Mostrar cero cuando esté confirmado; durante carga/error usar el estado del bloque, no cero.

Responsive, accesibilidad y acciones

Escritorio: resumen de host y personas en proximidad; tabla de perfiles de ancho suficiente; equipamiento/configuraciones con jerarquía uniforme. Evitar reproducir navegación global dentro de cada tarjeta.

Portátil/tablet: distribuir por ancho efectivo de contenedor con el shell presente; no adoptar los umbrales de inventario de activos como regla del puesto. Móvil: orden DOM identidad → principal → perfiles → equipamiento → configuraciones/software → soporte/contexto → historial. Tablas con scroll interno y acceso al valor completo; acciones de consulta/edición alcanzables sin hover.

Usar encabezados semánticos, regiones nombradas, estado textual además de color, enlaces reales para destinos y botones para acciones. No ocultar comparaciones esenciales entre pestañas. Pestañas posibles para detalle extenso e historial; la selección de perfil debe seguir visible.

Los formularios se abren en los diálogos existentes; no incrustar alta o edición en el dashboard. Conservar foco de retorno, Escape, estados pendientes, errores y no cerrar antes de éxito. Textos nuevos futuros deben tener es/en. En celdas sin valor usar exclusivamente «—»; estados vacíos completos explican motivo y siguiente acción.

Decisiones abiertas

• Confirmar si «personas usuarias» debe excluir inactivos por defecto y cómo ofrecer los archivados. El responsable siempre conserva rol propio.
• Elegir hasta dónde extender software/soporte: propuesta inicial limitada al principal, con navegación al resto de activos.
• Confirmar si configuraciones agregadas necesitan filtro por perfil o secciones por perfil. Comparar con un puesto de alta densidad antes de decidir.
• Priorizar soporte de equipo frente a contexto de teletrabajo según tareas reales de técnicos.
• Decidir si los procesos aportan valor en esta ficha; quedan fuera del mínimo inicial hasta justificar su consulta.

Estas decisiones no impiden un mockup conceptual basado en las hipótesis indicadas; no autorizan cambiar reglas ni contratos.