Rodax_Software/metis-desk
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Refactor documentation for clarity and accuracy

Browse Source 
- Updated examples in "estructura-web-por-entidades-y-operaciones.md" to reflect correct entity names and directory structures.
- Clarified modal usage and component interactions in "impresoras-del-perfil.md".
- Adjusted component descriptions in "logotipos-de-companias.md" for consistency.
- Revised persistence model details in "normalizacion-de-la-persistencia.md" to remove outdated references and clarify relationships.
- Enhanced dialog patterns in "patron-de-dialogos.md" with specific guidelines for field labels and validation.
- Specified component reuse in "patron-de-listados-de-entidades.md" to include @repo/rdx-ui components.
- Updated implementation status in "personas-y-departamentos.md" to reflect current features and pending tasks.
- Clarified project scope and initial setup instructions in "plan-de-desarrollo.md" and "puesta-en-marcha.md".
- Improved descriptions of workstation management in "puestos-de-trabajo.md" for better understanding of active/inactive states.
- Enhanced resource management details in "recursos-campos-y-plantillas.md" to clarify relationships and pending features.
- Revised best practices review in "revision-de-buenas-practicas.md" to reflect current project status and components.
- Updated teleworking documentation in "teletrabajo.md" to include references to remote technical assistance.
- Clarified user account management in "usuarios-y-acceso.md" to emphasize the importance of account deactivation.
This commit is contained in:
David Arranz 2026-10-15 17:48:46 +02:00
parent a0f02ced6e
commit ba562ad06f
27 changed files with 112 additions and 889 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/accesos-remotos.md
View File

@ -1,6 +1,6 @@
# Accesos remotos de las personas
Documenta el recorrido «equipo de origen → herramienta → destino». Complementa la autorización de [teletrabajo](teletrabajo.md), sin modificar los permisos ordinarios sobre recursos ni abrir o cerrar conexiones reales. La asistencia técnica remota es un caso separado y queda pendiente.
Documenta el recorrido «equipo de origen → herramienta → destino». Complementa la autorización de [teletrabajo](teletrabajo.md), sin modificar los permisos ordinarios sobre recursos ni abrir o cerrar conexiones reales. La [asistencia técnica remota](asistencia-tecnica-remota.md) está implementada como función separada.
## Datos y referencias
@ -36,7 +36,7 @@ La disponibilidad del recurso se comprueba mediante su estado activo; esta prime
Sección Accesos remotos dentro del espacio de compañía, búsqueda por persona/origen/destino/herramienta y filtro para consultar cerrados. Alta desde la cabecera derecha, edición e historial en modales. Ayuda y ejemplos inmediatamente antes de Guardar y Cancelar.
SelectWithAction permite alta rápida de persona, activo, recurso o sede. Máximo un formulario hijo; cancelarlo conserva el padre. Guardar una referencia la conserva aunque después se cancele el acceso. Los tipos y estados son opciones fijas del proceso y no incorporan botón de alta.
Persona, recurso y sede utilizan SelectWithAction; los activos de origen y destino utilizan AssetSelect con diálogo de selección. Todos conservan alta rápida. Máximo un formulario hijo; cancelarlo conserva el padre. Guardar una referencia la conserva aunque después se cancele el acceso. Los tipos y estados son opciones fijas del proceso y no incorporan botón de alta.
Entorno actual muestra los accesos abiertos de la persona, con sus orígenes explícitos, separados de las configuraciones del perfil. Incluye accesos desde otros equipos o equipos personales de la misma persona. Gestionar abre un listado filtrado; el alta deja fija a la persona. Volver conserva el perfil.

2
docs/arquitectura/capas-del-servidor.md
View File

@ -24,7 +24,7 @@ En módulos existentes y nuevos, el código de `web` debe organizarse por entida
funcional y después por operación, con ámbitos compartidos e índices explícitos según la
[estructura web por entidades y operaciones](../estructura-web-por-entidades-y-operaciones.md).
La primera entrega solo comprueba la vida del proceso. No hay reglas de negocio, agregados, repositorios ni casos de uso artificiales para esta comprobación técnica.
El endpoint de salud solo comprueba la vida del proceso y no necesita agregados, repositorios ni casos de uso. Los módulos de negocio utilizan las capas según sus responsabilidades.
## Dependencias

2
docs/arquitectura/composicion-de-modulos.md
View File

@ -23,5 +23,5 @@ Ese índice compone contratos internos explícitos; no expone automáticamente t
entidades, operaciones o componentes del módulo. `./common` y `./module` mantienen sus
fronteras de contratos compartidos y composición del servidor.
En esta entrega core expone registerCoreRoutes mediante ./module, una frontera de composición del servidor.
Core expone registerCoreRoutes mediante ./module, una frontera de composición del servidor.
./common expone contratos y ./client expone la página y recursos de traducción. No hay dependencias locales del ERP.

4
docs/arquitectura/flujo-http.md
View File

@ -18,7 +18,7 @@ Solo crear un RequestMapper adicional cuando exista adaptación HTTP real, como
Los identificadores de la organización y del actor se obtienen del contexto autenticado.
customerId puede identificar al cliente atendido, pero siempre se comprueba que el actor tenga acceso antes de consultar o modificar sus datos.
## Entrega inicial
## Salud y middleware común
GET /api/__health devuelve status y time. Rechaza parámetros de consulta desconocidos.
Comprueba únicamente que el proceso responde; no demuestra disponibilidad de base de datos ni autorización.
@ -29,4 +29,4 @@ Los errores HTTP tienen code y requestId. No devuelven detalles internos.
El middleware registra método, estado, duración e identificador; no registra URL, query, cabeceras ni cuerpo.
El servidor escucha en 127.0.0.1. La interfaz de desarrollo usa el proxy de Vite para /api.
No hay acceso a datos de clientes ni autenticación en esta entrega. Incorporar ambos de forma conjunta antes de habilitar esos datos.
Las rutas de datos de clientes requieren sesión autenticada y los guards correspondientes. Las escrituras validan origen y CSRF antes de ejecutar la operación.

23
docs/arquitectura/modelo-ddd-e-identificadores.md
View File

@ -2,7 +2,7 @@
## Regla de identidad
Toda entidad de negocio de Metis Desk, tanto raíz de agregado como entidad interna, tiene un identificador global único UniqueID. Se genera como UUID v7, igual que en factuges-erp. Clientes, personas, departamentos, asignaciones, revisiones, sedes/ubicaciones, documentos, tickets, intervenciones, assets, contratos y las demás entidades seguirán esta regla.
Toda entidad de negocio de Metis Desk, tanto raíz de agregado como entidad interna, tiene un identificador global único UniqueID. Se genera como UUID v7, igual que en factuges-erp. Compañías, personas, departamentos, asignaciones, revisiones, sedes, activos, recursos y las demás entidades siguen esta regla.
La identidad no depende de nombres, correos, referencias visibles ni claves numéricas incrementales. No cambia al actualizar, activar o archivar. Las relaciones entre entidades usan el UniqueID de la entidad referenciada.
@ -28,7 +28,7 @@ Se conserva la organización y los nombres del ERP, con tipos estrictos y sin co
Las raíces se declaran en archivos *.aggregate.ts; las entidades internas en *.entity.ts.
Las implementaciones de Value Objects, incluida su base compartida, se declaran en
archivos `*.vo.ts`: por ejemplo, `email-address.vo.ts`, `unique-id.vo.ts` y
`ticket-values.vo.ts`. Los Value Objects específicos de un módulo viven en
`workstation-values.vo.ts`. Los Value Objects específicos de un módulo viven en
domain/value-objects, salvo ámbitos existentes con organización propia, como
`domain/access/access-values.vo.ts`. Esta convención identifica las implementaciones,
no los schemas de entrada ni todos los ficheros que importan un Value Object.
@ -74,7 +74,7 @@ MailConfiguration es el agregado de un buzón configurado en un perfil; MailConf
PrinterConfiguration es la raíz de una impresora configurada en un perfil y PrinterConfigurationRevision conserva cada instantánea con UUID propio. PrinterConfigurationValues encapsula referencias UniqueID, conexión, predeterminada, estado y notas opcionales Maybe. Consultar [Impresoras del perfil](../impresoras-del-perfil.md).
Los módulos de documentos y tickets todavía no existen. Se declararán como agregados o entidades al implementar sus operaciones y reglas de consistencia. La decisión de pertenencia a un agregado se toma por sus invariantes y transacciones; no convierte automáticamente cada tabla en una raíz ni fuerza todo el cliente y sus tickets dentro de un solo agregado.
La decisión de pertenencia a un agregado se toma por sus invariantes y transacciones; no convierte automáticamente cada tabla en una raíz ni fuerza toda la compañía dentro de un solo agregado.
Cada entidad que se incorpore deberá tener UniqueID desde su primera implementación, mapper de persistencia y pruebas de identidad, invariantes, rehidratación y actualización.
@ -101,20 +101,3 @@ ProcessTemplate y PersonProcess son AggregateRoot; sus revisiones y las tareas P
## Asistencia técnica remota
SupportConnection delimita cada método de asistencia de un activo de una compañía. SupportValues encapsula la referencia UniqueID al recurso de asistencia y los valores de configuración; SupportConnectionRevision conserva las instantáneas con actor y fecha. Las herramientas son agregados Resource de la compañía, creados desde una plantilla con uso Asistencia remota; no tienen un catálogo paralelo. Todas las raíces y revisiones nuevas tienen UUID v7. Consultar [Asistencia técnica remota](../asistencia-tecnica-remota.md).
## Tickets
Ticket es AggregateRoot con compañía inmutable, referencia global y TicketValues (Name, UniqueID/Maybe y referencias tipadas TicketTarget). TicketRevision conserva cada instantánea con UUID propio, actor y fecha. Las referencias afectadas son valores sin ciclo de vida independiente, no entidades. Alta idempotente por clave de solicitud y edición condicionada a la última revisión. Consultar [Tickets](../tickets.md).
## Plantillas de intervención
InterventionTemplate es un agregado con ámbito inmutable, clave idempotente y revisiones. InterventionTemplateValues compara semánticamente nombre, descripción, estado y pasos en orden. InterventionTemplateStep e InterventionTemplateRevision son entidades con UUID. Las copias generan nuevos identificadores de pasos; editar o reordenar los conserva. Es un catálogo separado de ProcessTemplate y de las plantillas de activos/recursos.
## Intervenciones
Intervention es AggregateRoot con compañía, referencia, clave idempotente y procedimiento opcional inmutables. InterventionValues es Value Object, InterventionStep e InterventionRevision son DomainEntity. Los pasos mantienen UUID al actualizar/reordenar y generan identidades nuevas al aplicar plantillas. InterventionProcedure captura la identidad, revisión y valores originales de una plantilla mediante un Value Object inmutable. El historial permite conocer quién completó cada paso, incluso tras editar sus notas.
Brand es la raíz del catálogo global de marcas, con Name y BrandLogo como Value Objects, Maybe para el SVG opcional y UniqueID propio. Su repositorio conserva identidad y protege las marcas de serie. AssetValues reconstruye brandId opcional como Maybe<UniqueID>; los activos y sus revisiones conservan una instantánea del nombre junto a la referencia. Consultar [Catálogo global de marcas](../catalogo-global-de-marcas.md).
TemplateSection es una entidad interna de cada plantilla de activos o recursos, con UniqueID y Name. Se persiste dentro de la definición validada; la especificación captura sus valores e identidades. Los catálogos y UUID de ambos módulos permanecen independientes. Consultar [Secciones de campos](../secciones-de-campos-en-plantillas.md).

2
docs/auditoria-centralizada.md
View File

@ -46,7 +46,7 @@ Las operaciones masivas agrupan sus eventos. Si permiten resultados parciales, c
- Compañías, personas, sedes, departamentos, puestos de trabajo y perfiles de usuario.
- Activos y recursos; campos, agrupaciones, plantillas, marcas y catálogos globales o particulares.
- Cuentas, grupos, accesos, configuraciones de correo, aplicaciones, carpetas, impresoras, certificados y demás entidades existentes.
- Tickets, intervenciones, plantillas de intervención, pasos y procesos de personas.
- Procesos de personas, sus tareas y plantillas.
- Sustitución y eliminación de fotos y logotipos, registrando el hecho y la referencia segura, no el contenido binario.
- Gestión de usuarios y seguridad: cambios de contraseña, autenticación y resultados relevantes de acceso, sin almacenar credenciales.
- Importaciones, operaciones masivas, tareas automáticas y scripts de mantenimiento integrados.

8
docs/auditoria-de-separacion-logica-del-cliente.md
View File

@ -1,5 +1,11 @@
# Auditoría de separación lógica del cliente
Informe de una revisión anterior, no un inventario ni una instrucción de implementación
vigente. Las cifras y resultados corresponden al cierre de aquella revisión. Para trabajar
sobre el código actual, consultar `AGENTS.md`, las guías normativas y las
[funcionalidades archivadas](funcionalidades-archivadas.md).
## Alcance y referencia
Revisión de `modules/core/src/web`, `modules/identity/src/web`, `modules/assets/src/web`,
@ -19,7 +25,7 @@ sus dependencias, factories, tipos genéricos, memoización o servicios ajenos a
- Resources: catálogos, plantillas, editor, valores iniciales e integraciones de recursos.
- Companies: compañías, logos, personas, departamentos, sedes, asignaciones, accesos,
dashboard y workspace; correo, usos de buzón, perfiles, carpetas, aplicaciones,
certificados e impresoras; tickets, intervenciones, plantillas, procesos, teletrabajo y remotos.
certificados e impresoras; procesos y sus plantillas, teletrabajo y remotos.
La inspección combina inventario y análisis sintáctico del código, revisión de dependencias,
lectura de las responsabilidades y diffs afectados y comprobaciones por módulos.

2
docs/campos-y-plantillas-de-activos.md
View File

@ -11,7 +11,7 @@ Un campo representa una característica reutilizable: texto, texto largo, númer
Una plantilla reúne campos para un tipo de activo. No representa un activo concreto ni un modelo comercial. Cada campo comienza como opcional; el técnico puede marcarlo obligatorio en plantillas propias. Se pueden añadir y retirar campos. Retirar una asociación no elimina la definición del campo. El orden de incorporación se conserva.
El selector de campos reutiliza SelectWithAction: el botón «+» abre el alta de campo, conserva los datos de la plantilla y añade el nuevo campo como opcional. Cancelar el modal adicional conserva la plantilla. Un campo guardado permanece en el catálogo aunque se cancele después la plantilla.
«Añadir campo» abre CatalogFieldPickerDialog desde el grupo de destino. Permite seleccionar varios campos existentes o abrir el alta rápida desde el pie. Confirmar incorpora el lote como opcional; cancelar conserva la plantilla. Un campo guardado permanece en el catálogo aunque se cancele después la plantilla.
## Datos de serie

26
docs/componentes-de-interfaz.md
View File

@ -161,7 +161,7 @@ La paginación es local sobre los conjuntos que las API actuales ya devuelven. N
Los inventarios de activos y recursos componen las primitivas Tabs de shadcn/ui con EntityTable para filtrar por plantilla. La barra admite desplazamiento horizontal y navegación por teclado; incluye «Todo» y las plantillas del catálogo de la compañía. Un único panel conserva la tabla, su ordenación y sus columnas al cambiar de pestaña. `filterKey` reinicia la página; `filtersApplied` y `onClearFilters` integran el filtro con los estados vacíos y la limpieza común del listado.
EntityTable separa internamente la configuración de columnas/ordenación, el contenido semántico y la paginación; useEntityTable concentra el estado de representación. entityLabel permite contar «plantillas», «campos» o «tickets» aunque el título del espacio sea más amplio. Los tamaños disponibles son 10, 25, 50 y 100; una opción vacía nunca cambia el tamaño a cero.
EntityTable separa internamente la configuración de columnas/ordenación, el contenido semántico y la paginación; useEntityTable concentra el estado de representación. entityLabel permite contar «plantillas», «campos» o «recursos» aunque el título del espacio sea más amplio. Los tamaños disponibles son 10, 25, 50 y 100; una opción vacía nunca cambia el tamaño a cero.
Se declara @tanstack/react-table en el paquete compartido porque es quien consume ahora la librería; se reutiliza la versión 8.21.3 que ya utilizaba Compañías. No se introduce un segundo sistema de tablas.
@ -314,9 +314,9 @@ El desplazamiento vertical se conserva cuando el contenido supera la altura disp
## Resumen de compañía
La pantalla `CompanyOverview` tiene composición independiente de `DashboardPage` (Inicio). Comparte tarjetas, bloques de trabajo/avisos/actividad y consultas existentes, siempre fijando el ámbito al UUID de la compañía. El encabezado «De un vistazo» precede las acciones rápidas (ticket, intervención, activo y recurso), cuatro indicadores operativos y una franja navegable de personas, departamentos y sedes. No muestra compañías activas ni el resumen por compañías. La variante compacta de `StatisticCard` mejora la jerarquía del valor y la etiqueta sin modificar la presentación de Inicio.
La pantalla `CompanyOverview` tiene composición independiente de `DashboardPage` (Inicio). Comparte tarjetas, bloques de avisos/actividad y consultas existentes, siempre fijando el ámbito al UUID de la compañía. El encabezado «De un vistazo» precede las acciones rápidas (activo y recurso), dos indicadores operativos y una franja navegable de personas, departamentos y sedes. No muestra compañías activas ni el resumen por compañías. La variante compacta de `StatisticCard` mejora la jerarquía del valor y la etiqueta sin modificar la presentación de Inicio.
La navegación de compañía empieza por Resumen, Tickets e Intervenciones; después agrupa Personas, Puestos de trabajo y Perfiles de usuario y finalmente las demás secciones. Los grupos tienen separación visual. Las operaciones de usuario permanecen en el menú superior y dejan de repetirse al pie del menú de compañía.
La navegación de compañía empieza por Resumen; después agrupa Personas, Puestos de trabajo y Perfiles de usuario y finalmente las demás secciones. Los grupos tienen separación visual. Las operaciones de usuario permanecen en el menú superior y dejan de repetirse al pie del menú de compañía.
## Fichas de consulta y resumen lateral
@ -379,7 +379,7 @@ La edición conserva UUID, clave de serie y las identidades de asociaciones que
## Texto de ayuda de campos de activos y recursos
El atributo `description` de las definiciones de campo se presenta como «Texto de ayuda (opcional)», con una explicación de dónde aparecerá. En los formularios de alta y edición se muestra bajo el control, con tipografía pequeña, color `muted-foreground` y saltos de línea conservados. Se reutiliza `FieldDescription` de shadcn/ui y se vincula mediante `aria-describedby`, incluidos desplegables y el selector de marca.
El atributo `description` de las definiciones de campo se presenta como «Texto de ayuda», con una explicación de dónde aparecerá. En los formularios de alta y edición se muestra bajo el control, con tipografía pequeña, color `muted-foreground` y saltos de línea conservados. Se reutiliza `FieldDescription` de shadcn/ui y se vincula mediante `aria-describedby`, incluidos desplegables y el selector de marca.
La ayuda se consulta en el catálogo de cada ámbito por el identificador del campo, manteniendo separados activos y recursos. En edición se utiliza la ayuda vigente del catálogo sin modificar los tipos, etiquetas ni valores de la especificación capturada. Actualizar un texto de ayuda no requiere alterar datos ni historial de los activos o recursos existentes. Si el texto está vacío o falta la definición, no se muestra un bloque vacío.
@ -456,7 +456,7 @@ largo. Cada tipo utiliza así sus propios campos, incluidos los personalizados,
basadas en nombres ni cambios de persistencia. Si no hay características, se muestra solo el
nombre. El resumen ocupa como máximo dos líneas y su texto completo está disponible en `title`.
El selector se aplica a activos del puesto (adición múltiple), ordenador principal (único entre miembros), extremo de relaciones, impresora por perfil, origen/destino de conexiones remotas y activos afectados de tickets (adición múltiple). Cada caso conserva exclusiones, referencias fijas y altas rápidas. Añadir varios activos a un puesto es una sola actualización de composición; solo se propone automáticamente el ordenador cuando la composición resultante contiene un único activo.
El selector se aplica a activos del puesto (adición múltiple), ordenador principal (único entre miembros), extremo de relaciones, impresora por perfil, origen/destino de conexiones remotas. Cada caso conserva exclusiones, referencias fijas y altas rápidas. Añadir varios activos a un puesto es una sola actualización de composición; solo se propone automáticamente el ordenador cuando la composición resultante contiene un único activo.
## Panel lateral y resumen de recursos
@ -566,3 +566,19 @@ sitúa Continuar en ese pie y lo deshabilita mientras falta una selección o una
`SoftwareInstallationEditorDialog`, `SoftwareResourceCreateDialog` y `EntityTableColumnsDialog`
encapsulan sus interacciones en ficheros independientes. Sus consumidores conservan apertura,
selección, datos y callbacks; los formularios y controles mantienen sus contratos anteriores.
## Etiquetas y campos obligatorios
`FormLabel`, en `@repo/rdx-ui/components/form-label`, compone la primitiva `Label` de
shadcn/ui y conserva sus props y la asociación `htmlFor`. La prop `required` añade al
final un único asterisco con color `destructive`, mediante `RequiredIndicator`. El indicador
es visual; el control mantiene sus atributos de validación y su semántica accesible.
La etiqueta de un campo optativo contiene solo su texto, sin sufijos de opcionalidad.
Los módulos aportan nombres traducidos sin asteriscos y la condición de obligatoriedad.
Las características de activos y recursos conservan su unidad; las referencias y fechas
condicionales utilizan la condición de su contrato. No se deduce obligatoriedad de que
un valor esté vacío, de su estado deshabilitado ni de que un booleano sea `false`.
Los grupos de campos, como permisos, reutilizan `RequiredIndicator` en su leyenda,
sin marcar cada checkbox como obligatorio. La configuración de obligatoriedad de las
plantillas conserva sus switches y su significado.

2
docs/cuentas-grupos-y-recursos.md
View File

@ -4,7 +4,7 @@
- Catálogos informáticos, en la navegación principal: sistemas, tipos de recurso, permisos disponibles y plantillas de grupos comunes.
- Compañías → ficha → Cuentas y accesos: cuentas, relaciones con personas, grupos, miembros, permisos concedidos, necesidades, cobertura y entornos. También permite añadir sistemas, tipos y permisos propios de la compañía.
- Los botones de alta están a la derecha de la cabecera. Los formularios sencillos se abren en modal; los extensos sustituyen el listado por una página de formulario. Edición e historial son acciones explícitas.
- Los botones de alta están a la derecha de la cabecera. Los formularios se abren en modales con anchura y desplazamiento adaptados a su contenido. Edición e historial son acciones explícitas.
Los catálogos comienzan vacíos. Definir primero los sistemas comunes que se utilicen, como Dominio, Correo, Microsoft 365 o ERP. Las altas posteriores seleccionan esas definiciones; no se crean datos de ejemplo en la base de trabajo.

223
docs/diagrama-entidad-relacion-completo.mmd
View File

@ -608,136 +608,6 @@ erDiagram
int id PK
char initialAdminId FK "nullable"
}
intervention_counter {
int id PK
int nextNumber
}
intervention_procedure_steps {
char ownerId PK,FK
char stepId PK
int position
varchar title
text instructions
tinyint required
}
intervention_procedures {
char interventionId PK,FK
char templateId FK
char revisionId FK
varchar name
text description
tinyint active
}
intervention_revision_steps {
char ownerId PK,FK
char stepId PK
int position
varchar title
text instructions
tinyint required
varchar state
text notes
}
intervention_revision_targets {
char ownerId PK,FK
int position PK
char personId FK "nullable"
char workstationId FK "nullable"
char assetId FK "nullable"
char resourceId FK "nullable"
}
intervention_revisions {
char id PK
char interventionId FK
char actorId FK
char ticketId FK "nullable"
char assigneeId FK "nullable"
varchar recordedAt
int position
varchar subject
varchar state
varchar modality
date plannedDate "nullable"
varchar startedAt "nullable"
varchar endedAt "nullable"
int minutes "nullable"
text diagnosis
text workPerformed
text resolution
}
intervention_steps {
char ownerId PK,FK
char stepId PK
int position
varchar title
text instructions
tinyint required
varchar state
text notes
}
intervention_targets {
char ownerId PK,FK
int position PK
char personId FK "nullable"
char workstationId FK "nullable"
char assetId FK "nullable"
char resourceId FK "nullable"
}
intervention_template_lock {
int id PK
}
intervention_template_revision_steps {
char ownerId PK,FK
char stepId PK
int position
varchar title
text instructions
tinyint required
}
intervention_template_revisions {
char id PK
char templateId FK
char actorId FK "nullable"
varchar recordedAt
int position
varchar name
text description
tinyint active
}
intervention_template_steps {
char ownerId PK,FK
char stepId PK
int position
varchar title
text instructions
tinyint required
}
intervention_templates {
char id PK
char companyId FK "nullable"
char requestKey
varchar name
text description
tinyint active
}
interventions {
char id PK
char companyId FK
varchar reference
char requestKey
char ticketId FK "nullable"
char assigneeId FK "nullable"
varchar subject
varchar state
varchar modality
date plannedDate "nullable"
varchar startedAt "nullable"
varchar endedAt "nullable"
int minutes "nullable"
text diagnosis
text workPerformed
text resolution
}
mail_configuration_revisions {
char id PK
char configurationId FK
@ -1144,53 +1014,6 @@ erDiagram
varchar expiresOn "nullable"
text notes "nullable"
}
ticket_counter {
int id PK
int nextNumber
}
ticket_revision_targets {
char ownerId PK,FK
int position PK
char personId FK "nullable"
char workstationId FK "nullable"
char assetId FK "nullable"
char resourceId FK "nullable"
}
ticket_revisions {
char id PK
char ticketId FK
char actorId FK
char requesterId FK "nullable"
char assigneeId FK "nullable"
varchar recordedAt
int position
varchar subject
text description
varchar channel
varchar state
varchar priority
}
ticket_targets {
char ownerId PK,FK
int position PK
char personId FK "nullable"
char workstationId FK "nullable"
char assetId FK "nullable"
char resourceId FK "nullable"
}
tickets {
char id PK
char companyId FK
varchar reference
char requestKey
char requesterId FK "nullable"
char assigneeId FK "nullable"
varchar subject
text description
varchar channel
varchar state
varchar priority
}
users {
char id PK
varchar name
@ -1430,35 +1253,6 @@ erDiagram
work_profiles ||..o{ folder_mappings : "profileId"
users |o..o{ http_sessions : "userId"
users |o..o{ identity_state : "initialAdminId"
intervention_procedures ||..o{ intervention_procedure_steps : "ownerId"
intervention_template_revisions ||..o{ intervention_procedures : "revisionId"
intervention_template_revisions ||..o{ intervention_procedures : "templateId, revisionId"
intervention_templates ||..o{ intervention_procedures : "templateId"
interventions ||..o| intervention_procedures : "interventionId"
intervention_revisions ||..o{ intervention_revision_steps : "ownerId"
assets |o..o{ intervention_revision_targets : "assetId"
company_contacts |o..o{ intervention_revision_targets : "personId"
intervention_revisions ||..o{ intervention_revision_targets : "ownerId"
resources |o..o{ intervention_revision_targets : "resourceId"
workstations |o..o{ intervention_revision_targets : "workstationId"
interventions ||..o{ intervention_revisions : "interventionId"
tickets |o..o{ intervention_revisions : "ticketId"
users ||..o{ intervention_revisions : "actorId"
users |o..o{ intervention_revisions : "assigneeId"
interventions ||..o{ intervention_steps : "ownerId"
assets |o..o{ intervention_targets : "assetId"
company_contacts |o..o{ intervention_targets : "personId"
interventions ||..o{ intervention_targets : "ownerId"
resources |o..o{ intervention_targets : "resourceId"
workstations |o..o{ intervention_targets : "workstationId"
intervention_template_revisions ||..o{ intervention_template_revision_steps : "ownerId"
intervention_templates ||..o{ intervention_template_revisions : "templateId"
users |o..o{ intervention_template_revisions : "actorId"
intervention_templates ||..o{ intervention_template_steps : "ownerId"
companies |o..o{ intervention_templates : "companyId"
companies ||..o{ interventions : "companyId"
tickets |o..o{ interventions : "ticketId"
users |o..o{ interventions : "assigneeId"
access_items |o..o{ mail_configuration_revisions : "accountId"
assets |o..o{ mail_configuration_revisions : "assetId"
company_contacts |o..o{ mail_configuration_revisions : "personId"
@ -1574,23 +1368,6 @@ erDiagram
users ||..o{ telework_authorization_revisions : "actorId"
companies ||..o{ telework_authorizations : "companyId"
company_contacts ||..o| telework_authorizations : "personId"
assets |o..o{ ticket_revision_targets : "assetId"
company_contacts |o..o{ ticket_revision_targets : "personId"
resources |o..o{ ticket_revision_targets : "resourceId"
ticket_revisions ||..o{ ticket_revision_targets : "ownerId"
workstations |o..o{ ticket_revision_targets : "workstationId"
company_contacts |o..o{ ticket_revisions : "requesterId"
tickets ||..o{ ticket_revisions : "ticketId"
users ||..o{ ticket_revisions : "actorId"
users |o..o{ ticket_revisions : "assigneeId"
assets |o..o{ ticket_targets : "assetId"
company_contacts |o..o{ ticket_targets : "personId"
resources |o..o{ ticket_targets : "resourceId"
tickets ||..o{ ticket_targets : "ownerId"
workstations |o..o{ ticket_targets : "workstationId"
companies ||..o{ tickets : "companyId"
company_contacts |o..o{ tickets : "requesterId"
users |o..o{ tickets : "assigneeId"
access_items |o..o{ work_profile_revisions : "accountId"
assets |o..o{ work_profile_revisions : "assetId"
company_contacts |o..o{ work_profile_revisions : "personId"

220
docs/diagrama-entidad-relacion.md
View File

@ -1,8 +1,13 @@
# Diagrama de entidad relación de la base de datos
Esquema físico consultado en MariaDB el **14 de octubre de 2026** mediante `information_schema`. Esta instantánea refleja las tablas y restricciones existentes, no un diseño propuesto ni únicamente los modelos de Sequelize. No se han consultado registros de negocio ni modificado la base de datos.
Esquema derivado de la captura de MariaDB del **14 de octubre de 2026** mediante
`information_schema`, depurado el **15 de octubre de 2026** según la migración activa
`removeArchivedSupportTables`. Se excluyen las 19 tablas retiradas; sus fuentes y
contratos se conservan en [el archivo](funcionalidades-archivadas.md).
No se ha realizado una nueva consulta a MariaDB ni ejecutado migraciones para esta revisión.
Los demás metadatos conservan los tipos y restricciones de la captura original.
**130 tablas y 2 vistas SQL · 999 columnas · 1054 restricciones FK · 355 relaciones distintas** (agrupando restricciones con idénticas columnas, destino y reglas).
**111 tablas y 2 vistas SQL · 860 columnas · 1008 restricciones FK · 309 relaciones distintas** (agrupando restricciones con idénticas columnas, destino y reglas).
- [Diagrama completo, con todas las columnas (Mermaid)](diagrama-entidad-relacion-completo.mmd).
- [Diccionario completo de tablas, columnas y claves foráneas](diccionario-del-esquema-actual.md).
@ -27,11 +32,9 @@ erDiagram
company_contacts
company_departments
company_sites
interventions
person_department_assignments
resource_definitions
resources
tickets
users
work_profiles
workstation_assets
@ -45,9 +48,6 @@ erDiagram
companies ||..o{ company_contacts : "companyId"
companies ||..o{ company_departments : "companyId"
companies ||..o{ company_sites : "companyId"
companies ||..o{ interventions : "companyId"
tickets |o..o{ interventions : "ticketId"
users |o..o{ interventions : "assigneeId"
companies ||..o{ person_department_assignments : "companyId"
company_contacts ||..o{ person_department_assignments : "personId, companyId"
company_departments ||..o{ person_department_assignments : "departmentId, companyId"
@ -57,9 +57,6 @@ erDiagram
resource_definitions |o..o{ resources : "contextFieldId"
resource_definitions |o..o{ resources : "referenceFieldId"
resource_definitions ||..o{ resources : "templateId"
companies ||..o{ tickets : "companyId"
company_contacts |o..o{ tickets : "requesterId"
users |o..o{ tickets : "assigneeId"
assets ||..o{ work_profiles : "assetId"
companies ||..o{ work_profiles : "companyId"
company_contacts ||..o{ work_profiles : "personId"
@ -87,7 +84,6 @@ erDiagram
| Activos y catálogo | 18 |
| Compañías y personas | 8 |
| Usuarios y sesión | 3 |
| Tickets e intervenciones | 19 |
| Procesos de personas | 9 |
| Teletrabajo y conexiones remotas | 4 |
| Recursos y catálogo | 13 |
@ -857,198 +853,6 @@ erDiagram
users |o..o{ identity_state : "initialAdminId"
```
## Tickets e intervenciones
Tablas propias: `intervention_counter`, `intervention_procedure_steps`, `intervention_procedures`, `intervention_revision_steps`, `intervention_revision_targets`, `intervention_revisions`, `intervention_steps`, `intervention_targets`, `intervention_template_lock`, `intervention_template_revision_steps`, `intervention_template_revisions`, `intervention_template_steps`, `intervention_templates`, `interventions`, `ticket_counter`, `ticket_revision_targets`, `ticket_revisions`, `ticket_targets`, `tickets`.
```mermaid
erDiagram
direction LR
assets {
char id PK
char companyId FK
char templateId FK
char siteId FK "nullable"
char brandId FK "nullable"
}
companies {
char id PK
}
company_contacts {
char id PK
char companyId FK
}
intervention_counter {
int id PK
}
intervention_procedure_steps {
char ownerId PK,FK
char stepId PK
}
intervention_procedures {
char interventionId PK,FK
char templateId FK
char revisionId FK
}
intervention_revision_steps {
char ownerId PK,FK
char stepId PK
}
intervention_revision_targets {
char ownerId PK,FK
int position PK
char personId FK "nullable"
char workstationId FK "nullable"
char assetId FK "nullable"
char resourceId FK "nullable"
}
intervention_revisions {
char id PK
char interventionId FK
char actorId FK
char ticketId FK "nullable"
char assigneeId FK "nullable"
}
intervention_steps {
char ownerId PK,FK
char stepId PK
}
intervention_targets {
char ownerId PK,FK
int position PK
char personId FK "nullable"
char workstationId FK "nullable"
char assetId FK "nullable"
char resourceId FK "nullable"
}
intervention_template_lock {
int id PK
}
intervention_template_revision_steps {
char ownerId PK,FK
char stepId PK
}
intervention_template_revisions {
char id PK
char templateId FK
char actorId FK "nullable"
}
intervention_template_steps {
char ownerId PK,FK
char stepId PK
}
intervention_templates {
char id PK
char companyId FK "nullable"
}
interventions {
char id PK
char companyId FK
char ticketId FK "nullable"
char assigneeId FK "nullable"
}
resources {
char id PK
char companyId FK
char templateId FK
char addressFieldId FK "nullable"
char contextFieldId FK "nullable"
char accountId FK "nullable"
char referenceFieldId FK "nullable"
char resourceTypeId FK "nullable"
char systemId FK "nullable"
char environmentId FK "nullable"
}
ticket_counter {
int id PK
}
ticket_revision_targets {
char ownerId PK,FK
int position PK
char personId FK "nullable"
char workstationId FK "nullable"
char assetId FK "nullable"
char resourceId FK "nullable"
}
ticket_revisions {
char id PK
char ticketId FK
char actorId FK
char requesterId FK "nullable"
char assigneeId FK "nullable"
}
ticket_targets {
char ownerId PK,FK
int position PK
char personId FK "nullable"
char workstationId FK "nullable"
char assetId FK "nullable"
char resourceId FK "nullable"
}
tickets {
char id PK
char companyId FK
char requesterId FK "nullable"
char assigneeId FK "nullable"
}
users {
char id PK
}
workstations {
char id PK
char companyId FK
char siteId FK "nullable"
char personId FK "nullable"
char computerAssetId FK "nullable"
}
intervention_procedures ||..o{ intervention_procedure_steps : "ownerId"
intervention_template_revisions ||..o{ intervention_procedures : "revisionId"
intervention_template_revisions ||..o{ intervention_procedures : "templateId, revisionId"
intervention_templates ||..o{ intervention_procedures : "templateId"
interventions ||..o| intervention_procedures : "interventionId"
intervention_revisions ||..o{ intervention_revision_steps : "ownerId"
assets |o..o{ intervention_revision_targets : "assetId"
company_contacts |o..o{ intervention_revision_targets : "personId"
intervention_revisions ||..o{ intervention_revision_targets : "ownerId"
resources |o..o{ intervention_revision_targets : "resourceId"
workstations |o..o{ intervention_revision_targets : "workstationId"
interventions ||..o{ intervention_revisions : "interventionId"
tickets |o..o{ intervention_revisions : "ticketId"
users ||..o{ intervention_revisions : "actorId"
users |o..o{ intervention_revisions : "assigneeId"
interventions ||..o{ intervention_steps : "ownerId"
assets |o..o{ intervention_targets : "assetId"
company_contacts |o..o{ intervention_targets : "personId"
interventions ||..o{ intervention_targets : "ownerId"
resources |o..o{ intervention_targets : "resourceId"
workstations |o..o{ intervention_targets : "workstationId"
intervention_template_revisions ||..o{ intervention_template_revision_steps : "ownerId"
intervention_templates ||..o{ intervention_template_revisions : "templateId"
users |o..o{ intervention_template_revisions : "actorId"
intervention_templates ||..o{ intervention_template_steps : "ownerId"
companies |o..o{ intervention_templates : "companyId"
companies ||..o{ interventions : "companyId"
tickets |o..o{ interventions : "ticketId"
users |o..o{ interventions : "assigneeId"
assets |o..o{ ticket_revision_targets : "assetId"
company_contacts |o..o{ ticket_revision_targets : "personId"
resources |o..o{ ticket_revision_targets : "resourceId"
ticket_revisions ||..o{ ticket_revision_targets : "ownerId"
workstations |o..o{ ticket_revision_targets : "workstationId"
company_contacts |o..o{ ticket_revisions : "requesterId"
tickets ||..o{ ticket_revisions : "ticketId"
users ||..o{ ticket_revisions : "actorId"
users |o..o{ ticket_revisions : "assigneeId"
assets |o..o{ ticket_targets : "assetId"
company_contacts |o..o{ ticket_targets : "personId"
resources |o..o{ ticket_targets : "resourceId"
tickets ||..o{ ticket_targets : "ownerId"
workstations |o..o{ ticket_targets : "workstationId"
companies ||..o{ tickets : "companyId"
company_contacts |o..o{ tickets : "requesterId"
users |o..o{ tickets : "assigneeId"
```
## Procesos de personas
Tablas propias: `person_process_revision_tasks`, `person_process_revisions`, `person_process_tasks`, `person_processes`, `process_catalog_lock`, `process_template_instructions`, `process_template_revision_instructions`, `process_template_revisions`, `process_templates`.
@ -1476,12 +1280,16 @@ erDiagram
## Observaciones del esquema físico
Los 132 objetos consultados son **130 tablas y 2 vistas SQL**: `access_current_values` y `access_historical_values`. Las vistas no tienen FK propias y se representan como objetos independientes; no se inventan relaciones físicas para ellas.
Los 113 objetos representados son **111 tablas y 2 vistas SQL**: `access_current_values` y `access_historical_values`. Las vistas no tienen FK propias y se representan como objetos independientes; no se inventan relaciones físicas para ellas.
Se han encontrado **17 relaciones con varias restricciones FK equivalentes**: 699 restricciones adicionales. Se han agrupado únicamente en la representación; no se han eliminado. El diccionario conserva todos los nombres de restricciones. Conviene revisar por separado el origen de estas duplicaciones.
La captura conservada contiene **17 relaciones con varias restricciones FK equivalentes**: 699 restricciones adicionales. Se han agrupado únicamente en la representación; no se han eliminado. El diccionario conserva todos los nombres de restricciones. Conviene revisar por separado el origen de estas duplicaciones.
Solo se dibujan relaciones declaradas en MariaDB. Un identificador sin FK no implica una relación física garantizada; las referencias polimórficas y las validaciones de aplicación pueden tener relaciones adicionales. Las tablas de revisiones forman parte del esquema actual y se incluyen. Esta documentación no implica que exista ya la auditoría centralizada diseñada para una implementación futura.
## Validación
Generación verificada contra la misma captura de metadatos: 130 tablas y 2 vistas SQL, 999 columnas y 355 relaciones distintas incluidas en el archivo completo; todas las tablas asignadas a un área. Las reglas ON DELETE/ON UPDATE se recogen en el diccionario. No se han ejecutado migraciones ni cambios de datos.
La depuración documental se ha contrastado con la lista explícita de tablas de la migración
activa. El diccionario y el diagrama completo coinciden en 111 tablas y 2 vistas SQL,
860 columnas y 309 relaciones distintas; todas las tablas se asignan a un área.
Las reglas ON DELETE/ON UPDATE se recogen en el diccionario. Esta comprobación revisa
los documentos y la migración, no certifica el estado de una base de datos en ejecución.

330
docs/diccionario-del-esquema-actual.md
View File

@ -1,6 +1,6 @@
# Diccionario del esquema actual
Instantánea de MariaDB del **14 de octubre de 2026**. Complementa el [diagrama de entidad relación](diagrama-entidad-relacion.md). `NULL` indica si la columna admite ausencia de valor. Se conservan los tipos SQL exactos y todos los nombres de las restricciones FK, incluidas las equivalentes. No se incluyen valores predeterminados ni registros de negocio.
Documentación derivada de la captura de MariaDB del **14 de octubre de 2026**, depurada el **15 de octubre de 2026** según la migración `removeArchivedSupportTables`. Se excluyen las 19 tablas retiradas de la aplicación; no se ha realizado una nueva consulta a MariaDB. El código y la documentación de esas funciones se conservan en [el archivo](funcionalidades-archivadas.md). Complementa el [diagrama de entidad relación](diagrama-entidad-relacion.md). `NULL` indica si la columna admite ausencia de valor. Se conservan los tipos SQL exactos y todos los nombres de las restricciones FK, incluidas las equivalentes. No se incluyen valores predeterminados ni registros de negocio.
## access_account_person_revision_values
@ -1161,243 +1161,6 @@ Instantánea de MariaDB del **14 de octubre de 2026**. Complementa el [diagrama
| --- | --- | --- | --- |
| `initialAdminId` | `users(id)` | RESTRICT / RESTRICT | `identity_state_ibfk_1` |
## intervention_counter
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `id` | `int(11)` | No | PK |
| `nextNumber` | `int(11)` | No | — |
## intervention_procedure_steps
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `ownerId` | `char(36)` | No | PK, FK |
| `stepId` | `char(36)` | No | PK |
| `position` | `int(11)` | No | — |
| `title` | `varchar(200)` | No | — |
| `instructions` | `text` | No | — |
| `required` | `tinyint(1)` | No | — |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `ownerId` | `intervention_procedures(interventionId)` | CASCADE / RESTRICT | `intervention_procedure_steps_ibfk_1` |
## intervention_procedures
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `interventionId` | `char(36)` | No | PK, FK |
| `templateId` | `char(36)` | No | FK |
| `revisionId` | `char(36)` | No | FK |
| `name` | `varchar(160)` | No | — |
| `description` | `text` | No | — |
| `active` | `tinyint(1)` | No | — |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `revisionId` | `intervention_template_revisions(id)` | RESTRICT / RESTRICT | `intervention_procedures_ibfk_3` |
| `templateId`, `revisionId` | `intervention_template_revisions(templateId, id)` | RESTRICT / RESTRICT | `intervention_procedure_template_revision` |
| `templateId` | `intervention_templates(id)` | RESTRICT / RESTRICT | `intervention_procedures_ibfk_2` |
| `interventionId` | `interventions(id)` | CASCADE / RESTRICT | `intervention_procedures_ibfk_1` |
## intervention_revision_steps
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `ownerId` | `char(36)` | No | PK, FK |
| `stepId` | `char(36)` | No | PK |
| `position` | `int(11)` | No | — |
| `title` | `varchar(200)` | No | — |
| `instructions` | `text` | No | — |
| `required` | `tinyint(1)` | No | — |
| `state` | `varchar(20)` | No | — |
| `notes` | `text` | No | — |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `ownerId` | `intervention_revisions(id)` | CASCADE / RESTRICT | `intervention_revision_steps_ibfk_1` |
## intervention_revision_targets
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `ownerId` | `char(36)` | No | PK, FK |
| `position` | `int(11)` | No | PK |
| `personId` | `char(36)` | Sí | FK |
| `workstationId` | `char(36)` | Sí | FK |
| `assetId` | `char(36)` | Sí | FK |
| `resourceId` | `char(36)` | Sí | FK |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `assetId` | `assets(id)` | RESTRICT / RESTRICT | `intervention_revision_targets_ibfk_4` |
| `personId` | `company_contacts(id)` | RESTRICT / RESTRICT | `intervention_revision_targets_ibfk_2` |
| `ownerId` | `intervention_revisions(id)` | CASCADE / RESTRICT | `intervention_revision_targets_ibfk_1` |
| `resourceId` | `resources(id)` | RESTRICT / RESTRICT | `intervention_revision_targets_ibfk_5` |
| `workstationId` | `workstations(id)` | RESTRICT / RESTRICT | `intervention_revision_targets_ibfk_3` |
## intervention_revisions
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `id` | `char(36)` | No | PK |
| `interventionId` | `char(36)` | No | FK |
| `actorId` | `char(36)` | No | FK |
| `ticketId` | `char(36)` | Sí | FK |
| `assigneeId` | `char(36)` | Sí | FK |
| `recordedAt` | `varchar(30)` | No | — |
| `position` | `int(11)` | No | — |
| `subject` | `varchar(200)` | No | — |
| `state` | `varchar(20)` | No | — |
| `modality` | `varchar(20)` | No | — |
| `plannedDate` | `date` | Sí | — |
| `startedAt` | `varchar(30)` | Sí | — |
| `endedAt` | `varchar(30)` | Sí | — |
| `minutes` | `int(11)` | Sí | — |
| `diagnosis` | `text` | No | — |
| `workPerformed` | `text` | No | — |
| `resolution` | `text` | No | — |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `interventionId` | `interventions(id)` | RESTRICT / RESTRICT | `intervention_revisions_ibfk_1` |
| `ticketId` | `tickets(id)` | RESTRICT / RESTRICT | `intervention_revisions_ibfk_3` |
| `actorId` | `users(id)` | RESTRICT / RESTRICT | `intervention_revisions_ibfk_2` |
| `assigneeId` | `users(id)` | RESTRICT / RESTRICT | `intervention_revisions_ibfk_4` |
## intervention_steps
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `ownerId` | `char(36)` | No | PK, FK |
| `stepId` | `char(36)` | No | PK |
| `position` | `int(11)` | No | — |
| `title` | `varchar(200)` | No | — |
| `instructions` | `text` | No | — |
| `required` | `tinyint(1)` | No | — |
| `state` | `varchar(20)` | No | — |
| `notes` | `text` | No | — |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `ownerId` | `interventions(id)` | CASCADE / RESTRICT | `intervention_steps_ibfk_1` |
## intervention_targets
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `ownerId` | `char(36)` | No | PK, FK |
| `position` | `int(11)` | No | PK |
| `personId` | `char(36)` | Sí | FK |
| `workstationId` | `char(36)` | Sí | FK |
| `assetId` | `char(36)` | Sí | FK |
| `resourceId` | `char(36)` | Sí | FK |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `assetId` | `assets(id)` | RESTRICT / RESTRICT | `intervention_targets_ibfk_4` |
| `personId` | `company_contacts(id)` | RESTRICT / RESTRICT | `intervention_targets_ibfk_2` |
| `ownerId` | `interventions(id)` | CASCADE / RESTRICT | `intervention_targets_ibfk_1` |
| `resourceId` | `resources(id)` | RESTRICT / RESTRICT | `intervention_targets_ibfk_5` |
| `workstationId` | `workstations(id)` | RESTRICT / RESTRICT | `intervention_targets_ibfk_3` |
## intervention_template_lock
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `id` | `int(11)` | No | PK |
## intervention_template_revision_steps
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `ownerId` | `char(36)` | No | PK, FK |
| `stepId` | `char(36)` | No | PK |
| `position` | `int(11)` | No | — |
| `title` | `varchar(200)` | No | — |
| `instructions` | `text` | No | — |
| `required` | `tinyint(1)` | No | — |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `ownerId` | `intervention_template_revisions(id)` | CASCADE / RESTRICT | `intervention_template_revision_steps_ibfk_1` |
## intervention_template_revisions
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `id` | `char(36)` | No | PK |
| `templateId` | `char(36)` | No | FK |
| `actorId` | `char(36)` | Sí | FK |
| `recordedAt` | `varchar(30)` | No | — |
| `position` | `int(11)` | No | — |
| `name` | `varchar(160)` | No | — |
| `description` | `text` | No | — |
| `active` | `tinyint(1)` | No | — |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `templateId` | `intervention_templates(id)` | RESTRICT / RESTRICT | `intervention_template_revisions_ibfk_1` |
| `actorId` | `users(id)` | RESTRICT / RESTRICT | `intervention_template_revisions_ibfk_2` |
## intervention_template_steps
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `ownerId` | `char(36)` | No | PK, FK |
| `stepId` | `char(36)` | No | PK |
| `position` | `int(11)` | No | — |
| `title` | `varchar(200)` | No | — |
| `instructions` | `text` | No | — |
| `required` | `tinyint(1)` | No | — |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `ownerId` | `intervention_templates(id)` | CASCADE / RESTRICT | `intervention_template_steps_ibfk_1` |
## intervention_templates
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `id` | `char(36)` | No | PK |
| `companyId` | `char(36)` | Sí | FK |
| `requestKey` | `char(36)` | No | UNIQUE |
| `name` | `varchar(160)` | No | — |
| `description` | `text` | No | — |
| `active` | `tinyint(1)` | No | — |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `companyId` | `companies(id)` | RESTRICT / RESTRICT | `intervention_templates_ibfk_1` |
## interventions
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `id` | `char(36)` | No | PK |
| `companyId` | `char(36)` | No | FK |
| `reference` | `varchar(40)` | No | UNIQUE |
| `requestKey` | `char(36)` | No | UNIQUE |
| `ticketId` | `char(36)` | Sí | FK |
| `assigneeId` | `char(36)` | Sí | FK |
| `subject` | `varchar(200)` | No | — |
| `state` | `varchar(20)` | No | — |
| `modality` | `varchar(20)` | No | — |
| `plannedDate` | `date` | Sí | — |
| `startedAt` | `varchar(30)` | Sí | — |
| `endedAt` | `varchar(30)` | Sí | — |
| `minutes` | `int(11)` | Sí | — |
| `diagnosis` | `text` | No | — |
| `workPerformed` | `text` | No | — |
| `resolution` | `text` | No | — |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `companyId` | `companies(id)` | RESTRICT / RESTRICT | `interventions_ibfk_1` |
| `ticketId` | `tickets(id)` | RESTRICT / RESTRICT | `interventions_ibfk_2` |
| `assigneeId` | `users(id)` | RESTRICT / RESTRICT | `interventions_ibfk_3` |
## mail_configuration_revisions
| Columna | Tipo SQL | NULL | Clave |
@ -2138,97 +1901,6 @@ Instantánea de MariaDB del **14 de octubre de 2026**. Complementa el [diagrama
| `companyId` | `companies(id)` | RESTRICT / RESTRICT | `telework_authorizations_ibfk_1` |
| `personId` | `company_contacts(id)` | RESTRICT / RESTRICT | `telework_authorizations_ibfk_2` |
## ticket_counter
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `id` | `int(11)` | No | PK |
| `nextNumber` | `int(11)` | No | — |
## ticket_revision_targets
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `ownerId` | `char(36)` | No | PK, FK |
| `position` | `int(11)` | No | PK |
| `personId` | `char(36)` | Sí | FK |
| `workstationId` | `char(36)` | Sí | FK |
| `assetId` | `char(36)` | Sí | FK |
| `resourceId` | `char(36)` | Sí | FK |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `assetId` | `assets(id)` | RESTRICT / RESTRICT | `ticket_revision_targets_ibfk_4` |
| `personId` | `company_contacts(id)` | RESTRICT / RESTRICT | `ticket_revision_targets_ibfk_2` |
| `resourceId` | `resources(id)` | RESTRICT / RESTRICT | `ticket_revision_targets_ibfk_5` |
| `ownerId` | `ticket_revisions(id)` | CASCADE / RESTRICT | `ticket_revision_targets_ibfk_1` |
| `workstationId` | `workstations(id)` | RESTRICT / RESTRICT | `ticket_revision_targets_ibfk_3` |
## ticket_revisions
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `id` | `char(36)` | No | PK |
| `ticketId` | `char(36)` | No | FK |
| `actorId` | `char(36)` | No | FK |
| `requesterId` | `char(36)` | Sí | FK |
| `assigneeId` | `char(36)` | Sí | FK |
| `recordedAt` | `varchar(30)` | No | — |
| `position` | `int(11)` | No | — |
| `subject` | `varchar(200)` | No | — |
| `description` | `text` | No | — |
| `channel` | `varchar(20)` | No | — |
| `state` | `varchar(20)` | No | — |
| `priority` | `varchar(20)` | No | — |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `requesterId` | `company_contacts(id)` | RESTRICT / RESTRICT | `ticket_revisions_ibfk_3` |
| `ticketId` | `tickets(id)` | RESTRICT / RESTRICT | `ticket_revisions_ibfk_1` |
| `actorId` | `users(id)` | RESTRICT / RESTRICT | `ticket_revisions_ibfk_2` |
| `assigneeId` | `users(id)` | RESTRICT / RESTRICT | `ticket_revisions_ibfk_4` |
## ticket_targets
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `ownerId` | `char(36)` | No | PK, FK |
| `position` | `int(11)` | No | PK |
| `personId` | `char(36)` | Sí | FK |
| `workstationId` | `char(36)` | Sí | FK |
| `assetId` | `char(36)` | Sí | FK |
| `resourceId` | `char(36)` | Sí | FK |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `assetId` | `assets(id)` | RESTRICT / RESTRICT | `ticket_targets_ibfk_4` |
| `personId` | `company_contacts(id)` | RESTRICT / RESTRICT | `ticket_targets_ibfk_2` |
| `resourceId` | `resources(id)` | RESTRICT / RESTRICT | `ticket_targets_ibfk_5` |
| `ownerId` | `tickets(id)` | CASCADE / RESTRICT | `ticket_targets_ibfk_1` |
| `workstationId` | `workstations(id)` | RESTRICT / RESTRICT | `ticket_targets_ibfk_3` |
## tickets
| Columna | Tipo SQL | NULL | Clave |
| --- | --- | --- | --- |
| `id` | `char(36)` | No | PK |
| `companyId` | `char(36)` | No | FK |
| `reference` | `varchar(40)` | No | UNIQUE |
| `requestKey` | `char(36)` | No | UNIQUE |
| `requesterId` | `char(36)` | Sí | FK |
| `assigneeId` | `char(36)` | Sí | FK |
| `subject` | `varchar(200)` | No | — |
| `description` | `text` | No | — |
| `channel` | `varchar(20)` | No | — |
| `state` | `varchar(20)` | No | — |
| `priority` | `varchar(20)` | No | — |
| FK: columnas | Referencia | DELETE / UPDATE | Restricciones |
| --- | --- | --- | --- |
| `companyId` | `companies(id)` | RESTRICT / RESTRICT | `tickets_ibfk_1` |
| `requesterId` | `company_contacts(id)` | RESTRICT / RESTRICT | `tickets_ibfk_2` |
| `assigneeId` | `users(id)` | RESTRICT / RESTRICT | `tickets_ibfk_3` |
## users
| Columna | Tipo SQL | NULL | Clave |

62
docs/estructura-web-por-entidades-y-operaciones.md
View File

@ -13,7 +13,7 @@ El orden obligatorio es módulo → entidad o área funcional → operación →
modules/<module>/src/web/<entity>/<operation>/<responsibility>/
```
Por ejemplo, `web/tickets/create/ui/`, no `web/create/tickets/` ni un directorio global
Por ejemplo, `web/people/create/ui/`, no `web/create/people/` ni un directorio global
`web/components/` para componentes de entidades distintas. Utilizar nombres en inglés y
kebab-case. Las áreas sin una entidad de negocio propia, como `dashboard` o `workspace`,
siguen el mismo orden con operaciones descriptivas como `view`.
@ -25,68 +25,50 @@ cada directorio debe contener una responsabilidad real de la implementación act
## Ubicación de las responsabilidades
Ejemplo real de tickets en `modules/companies/src/web/`:
Ejemplo real de personas en `modules/companies/src/web/` (ficheros seleccionados):
```text
tickets/
create/
ui/
intervention-ticket-create-dialog.tsx
ticket-quick-editor.tsx
ticket-quick-forms.tsx
ticket-target-create-dialog.tsx
index.ts
index.ts
people/
detail/
ui/
ticket-detail.tsx
ticket-detail-dialog.tsx
person-details.tsx
current-workstations.tsx
index.ts
index.ts
list/
controllers/
use-tickets-page-controller.ts
index.ts
helpers/
tickets-filtering.ts
index.ts
types/
tickets-page-props.ts
index.ts
ui/
tickets-page.tsx
people-section.tsx
index.ts
index.ts
shared/
api/
ticket-api.ts
save-person.api.ts
index.ts
adapters/
build-person-request.ts
index.ts
controllers/
use-ticket-form-controller.ts
use-person-form-controller.ts
index.ts
helpers/
ticket-target-options.ts
schemas/
person-form.schema.ts
index.ts
types/
ticket-form-props.ts
person-form-props.ts
index.ts
ui/
ticket-form.tsx
ticket-editor-dialog.tsx
ticket-targets.tsx
ticket-classification-fields.tsx
ticket-feedback.tsx
ticket-help.tsx
person-form.tsx
person-editor-dialog.tsx
person-photo-field.tsx
index.ts
tickets.test.tsx
index.ts
index.ts
```
El árbol muestra las ubicaciones, no implica exportar todos los ficheros. Los índices declaran
únicamente los símbolos que sus consumidores necesitan. Las operaciones sin una responsabilidad
propia no reciben directorios vacíos: por ejemplo, el editor común de alta y edición permanece
en `tickets/shared/ui/`.
propia no reciben directorios vacíos: el editor común de alta y edición permanece
en `people/shared/ui/`.
- `ui`: componentes y formularios. Un componente principal por fichero, sin nuevas
subdivisiones de JSX trivial.
@ -121,7 +103,7 @@ y `history`. Las operaciones particulares conservan nombres explícitos, como `c
Áreas antes agrupadas por una categoría amplia quedan identificadas por sus entidades:
`mailboxes`, `mailbox-uses` y `mail-configurations`; `work-profiles` y `work-environments`;
`processes` y `process-templates`; `interventions` e `intervention-templates`.
`processes` y `process-templates`.
Los componentes de dashboard y workspace siguen el mismo criterio funcional.
Un nuevo módulo conserva los niveles de entidad y operación aunque inicialmente contenga
@ -138,8 +120,8 @@ compartidos siguen [componentes de interfaz](componentes-de-interfaz.md).
Los formularios y diálogos que sirven tanto para crear como para editar se mantienen en el
`shared/ui` de su entidad. No se duplican ni se introducen wrappers de alta y edición sin
comportamiento propio. Un diálogo de alta de tickets pertenece a `tickets/create`, aunque
se abra desde una intervención; el consumidor no determina la identidad del componente.
comportamiento propio. El diálogo de inicio de un proceso pertenece a `processes/start`, aunque
se abra desde otra pantalla; el consumidor no determina la identidad del componente.
Situar el acceso HTTP en el ámbito más específico que corresponda a sus consumidores:
`<entity>/<operation>/api`, `<entity>/shared/api` o `web/shared/api`. Los clientes existentes

2
docs/impresoras-del-perfil.md
View File

@ -8,7 +8,7 @@ Cada configuración vincula un perfil (persona y dispositivo) con una impresora
La asignación del activo, la relación física entre activos y la configuración de la impresora en un perfil son independientes. Una impresora puede servir a varios perfiles y una persona puede usar varias impresoras. Registrar una configuración no instala controladores ni cambia físicamente el equipo.
Los desplegables de perfil e impresora reutilizan SelectWithAction para alta rápida. El perfil creado o el activo creado se seleccionan al guardar. Cancelar el modal hijo conserva el formulario padre. Los elementos guardados permanecen aunque se cancele el padre. Solo hay un modal adicional y no se permite otro nivel de alta. La ayuda con finalidad, ámbito y ejemplos aparece antes del pie Guardar/Cancelar. Textos en español e inglés.
El perfil utiliza SelectWithAction; la impresora utiliza AssetSelect, que abre el listado de activos en un diálogo de selección. Ambos conservan su alta rápida. El perfil creado o el activo creado se seleccionan al guardar. Cancelar el modal hijo conserva el formulario padre. Los elementos guardados permanecen aunque se cancele el padre. Solo hay un modal adicional y no se permite otro nivel de alta. La ayuda con finalidad, ámbito y ejemplos aparece antes del pie Guardar/Cancelar. Textos en español e inglés.
## Reglas

2
docs/logotipos-de-companias.md
View File

@ -13,7 +13,7 @@ Los datos generales y el logotipo se guardan en dos peticiones. Si falla la segu
## Componentes
- `CompanyAvatar`: logotipo con carga diferida y dimensiones reservadas; iniciales como alternativa. Usa la consulta compartida de compañías cuando un listado solo aporta identificador y nombre.
- `CompanyIdentity`: avatar y nombre alineados, utilizado en directorio, dashboard, tickets, intervenciones, búsqueda y detalle. El tamaño se ajusta mediante clases existentes.
- `CompanyIdentity`: avatar y nombre alineados, utilizado en directorio, dashboard, búsqueda y detalle. El tamaño se ajusta mediante clases existentes.
- `CompanySelect`: opciones y selección de compañías con avatar, reutilizando los controles shadcn/ui y conservando etiquetas de texto para búsquedas por teclado.
- `CompanyLogoField`: selección con validación local de peso y MIME, mensajes accesibles y acciones de quitar/deshacer. No decodifica el original en el navegador; la imagen optimizada aparece después de guardar.

28
docs/normalizacion-de-la-persistencia.md
View File

@ -4,7 +4,7 @@ Se mantiene Sequelize 6 y MariaDB. El criterio del proyecto es almacenar datos d
## Modelo de almacenamiento
El modelo utiliza columnas y relaciones para activos, recursos, configuraciones, cuentas y accesos, correo, procesos, tickets, intervenciones y sesiones HTTP. Los contratos HTTP utilizan JSON como transporte; el almacenamiento es relacional.
El modelo utiliza columnas y relaciones para activos, recursos, configuraciones, cuentas y accesos, correo, procesos y sesiones HTTP. Los contratos HTTP utilizan JSON como transporte; el almacenamiento es relacional.
| Ámbito | Persistencia actual |
| --- | --- |
@ -20,7 +20,6 @@ El modelo utiliza columnas y relaciones para activos, recursos, configuraciones,
| Correo | Buzones, usos y configuraciones en columnas actuales e históricas |
| Accesos remotos | Origen, destinos con claves foráneas independientes, VPN y estado en columnas actuales e históricas |
| Procesos y plantillas de procesos | Columnas escalares y tablas de instrucciones/tareas actuales e históricas |
| Tickets e intervenciones | Columnas actuales e históricas; afectados, pasos, procedimientos congelados y plantillas en tablas relacionadas |
| Sesiones HTTP | Almacén Sequelize propio: autenticación, CSRF y opciones de cookie en columnas; sin documento serializado |
Las columnas `data` de fotos y logotipos son datos binarios; no son documentos JSON de negocio.
@ -40,31 +39,10 @@ Los vínculos de integración con buzones y accesos se conservan en columnas con
## Puestos, perfiles y configuraciones
`workstation_members` conserva la composición actual del puesto, con tipo `exclusive` o `shared` y posición. `workstation_revision_members` conserva la composición de cada revisión. `workstation_assets` sigue siendo la proyección técnica que protege referencias históricas y reserva activos exclusivos de puestos vigentes; no es otra asignación de negocio.
`workstation_members` conserva la composición actual del puesto, con tipo `exclusive` y posición. `workstation_revision_members` conserva la composición de cada revisión. `workstation_assets` sigue siendo la proyección técnica que protege referencias históricas y reserva activos exclusivos de puestos vigentes; no es otra asignación de negocio.
Los perfiles y configuraciones mantienen sus reglas de unicidad, transiciones y cierre. Las referencias de las revisiones se conservan mediante claves foráneas.
## Tickets, intervenciones y plantillas
Los registros tickets, ticket_revisions, interventions, intervention_revisions, intervention_templates e intervention_template_revisions almacenan sus atributos en columnas. Asunto, descripción, estados, prioridad, canal, modalidad, fechas, minutos, diagnóstico, trabajo realizado, resolución, nombre y estado de la plantilla tienen columnas tradicionales según la entidad. `plannedDate` es una fecha SQL; los instantes ISO conservan su representación exacta en columnas de texto para no perder precisión del historial.
Las diez tablas dependientes son:
| Información | Actual | Histórica |
| --- | --- | --- |
| Afectados de tickets | `ticket_targets` | `ticket_revision_targets` |
| Afectados de intervenciones | `intervention_targets` | `intervention_revision_targets` |
| Ejecución de pasos | `intervention_steps` | `intervention_revision_steps` |
| Pasos de plantillas | `intervention_template_steps` | `intervention_template_revision_steps` |
| Procedimiento congelado | `intervention_procedures` | Procedencia inmutable de la intervención |
| Pasos originales del procedimiento | `intervention_procedure_steps` | Copia independiente del catálogo |
Un afectado tiene exactamente una referencia: persona, puesto, activo o recurso, con clave foránea real para cada tipo. Las asociaciones se identifican por propietario y posición; los pasos mantienen su UUID y un orden único dentro de cada propietario. Las claves foráneas restringen eliminar destinos referenciados, mientras que las filas dependientes pertenecen a su ticket, revisión, plantilla o procedimiento y se eliminan en cascada con su propietario.
El procedimiento conserva plantilla, revisión concreta, nombre, descripción, estado original y pasos. La base comprueba que la revisión pertenece a esa plantilla. No se sustituye esa copia por el catálogo vigente. Una intervención sencilla puede no tener procedimiento, pasos, técnico o ticket, según las reglas existentes.
Los repositorios reconstruyen los mismos Value Objects y agregados. Se mantienen las rutas, DTO, UUID, autores, fechas, contadores, reintentos idempotentes, revisión esperada, conflictos concurrentes y reglas para cerrar o reabrir. Los lectores del dashboard consultan las columnas normalizadas tanto del estado actual como de las revisiones.
## Inicialización del esquema
Los módulos preparan explícitamente sus tablas, índices y restricciones antes de exponer las rutas. Las columnas obligatorias se declaran al crear cada tabla; las tablas dependientes se crean de manera idempotente. No se utiliza sync({ alter: true }).
@ -121,6 +99,6 @@ Se conservan duración original y expiración de la cookie, opciones booleanas,
## Comprobaciones de persistencia
La auditoría de information_schema en desarrollo no encuentra tipos JSON, restricciones JSON_VALID ni columnas values, specification, characteristics, procedure u otros documentos serializados. Las columnas instructions de intervenciones son texto de instrucciones de un paso; data en fotos/logotipos es binario.
La auditoría de information_schema en desarrollo no encuentra tipos JSON, restricciones JSON_VALID ni columnas values, specification, characteristics, procedure u otros documentos serializados. Las columnas data en fotos/logotipos son binarias.
La persistencia no declara DataTypes.JSON ni interpreta documentos serializados. El uso de JSON en HTTP, traducciones y logs es independiente del almacenamiento de negocio.

8
docs/patron-de-dialogos.md
View File

@ -18,6 +18,14 @@ el [inventario de modales](inventario-de-modales.md) recoge las implementaciones
## Grupos, títulos y separación
- Las etiquetas de campos utilizan `FormLabel` de `@repo/rdx-ui`. Añadir `required`
solo cuando el campo sea obligatorio: muestra un asterisco al final en color
`destructive`. Los campos optativos muestran únicamente su nombre, sin «(opcional)».
- La marca sigue las mismas condiciones que la validación del campo, también en selectores,
características de plantillas y fechas condicionales. Conservar `htmlFor`, los atributos
de validación y la ayuda accesible del control. No incluir el asterisco en las traducciones
ni en el nombre de la característica. Los grupos con leyenda reutilizan `RequiredIndicator`.
- Usar `FormSectionTitle` para los títulos de grupo: texto pequeño, seminegrita, mayúsculas,
espaciado entre letras y color atenuado (`text-xs font-semibold uppercase tracking-wide
text-muted-foreground mb-4`). Conservar el nivel semántico del encabezado; las mayúsculas

2
docs/patron-de-listados-de-entidades.md
View File

@ -95,7 +95,7 @@ Las instrucciones/historiales que antes estaban expandidos dentro de catálogos
## Implementación y verificación
Se reutilizan Table, Button, Input, SelectWithAction, Dialog y los tokens existentes de @repo/shadcn-ui. Las consultas, DTO, endpoints, permisos y mutaciones permanecen en sus módulos. Los componentes comunes no conocen entidades ni invocan API.
Se reutilizan los componentes propios de @repo/rdx-ui, incluidos SelectWithAction y EntityTable, sobre Table, Button, Input, Dialog y los tokens existentes de @repo/shadcn-ui. Las consultas, DTO, endpoints, permisos y mutaciones permanecen en sus módulos. Los componentes comunes no conocen entidades ni invocan API.
La validación debe incluir tipos, estilo, pruebas y compilación, además de interacción real para búsqueda/limpieza, columnas, ordenación, cambios de página/tamaño, apertura/cancelación de fichas y panel de activos. Verificar español e inglés y una anchura móvil.

2
docs/personas-y-departamentos.md
View File

@ -58,7 +58,7 @@ Implementado: personas, clasificación como contacto, departamentos, puestos esp
Cuentas informáticas, grupos, recursos, autorizaciones y necesidades se gestionan en Cuentas y accesos de la compañía. No implican acceso de estas personas a Metis Desk.
Los perfiles, sus configuraciones y el inventario de activos están implementados. La [autorización de teletrabajo](teletrabajo.md) también está disponible. Quedan pendientes las conexiones remotas y los procesos y plantillas de alta/cambio/salida.
Los perfiles, sus configuraciones y el inventario de activos están implementados. La [autorización de teletrabajo](teletrabajo.md) también está disponible. También están disponibles los [accesos remotos](accesos-remotos.md) y los [procesos y plantillas de alta/cambio/salida](procesos-de-personas.md).
Los [procesos de personas](procesos-de-personas.md) organizan el alta, cambio y salida, conservando listas de comprobación, resultados e historial por compañía. Admiten personas inactivas para revisar accesos conservados; completar un proceso no desactiva ni elimina a la persona.

21
docs/plan-de-desarrollo.md
View File

@ -6,7 +6,7 @@ El proyecto es independiente de factuges-erp y comparte sus convenciones de prog
## Entrega 0: base técnica
Incluye monorepo PNPM y Turborepo, TypeScript estricto, Biome, Express, React, Vite, Tailwind, TanStack Query, shadcn/ui con Base UI, Zod y traducciones es/en.
La página inicial muestra la conexión real con la API. No contiene datos ficticios de clientes.
El endpoint de salud comprueba la vida del proceso. La pantalla Inicio muestra indicadores, avisos y actividad de los datos registrados; véase [Dashboard de inicio](dashboard-inicio.md).
## Acceso y usuarios: implementado
@ -24,7 +24,7 @@ Distinguir:
- Contacto: persona del cliente.
- Usuario de un equipo: persona asignada a un puesto; no implica acceso a la aplicación.
La adopción de una sola organización o de varias se decidirá antes del modelo persistente.
El modelo persistente actual identifica compañías clientes. La adopción de una sola organización de soporte o de varias sigue pendiente.
No crear un sistema multiempresa complejo sin necesidad, companyId identifica a la compañía cliente; no se utiliza como identificador de tenant.
## Personas y departamentos: implementado
@ -93,15 +93,7 @@ Este orden se concreta antes de cada entrega. El registro de licencias como recu
Activos por compañía, plantilla capturada, sede opcional, cuatro estados, características tipadas y revisiones con actor y fecha. La persona se relaciona mediante puestos de trabajo y perfiles de usuario. Altas rápidas y consulta del historial mediante modales. Consultar [Inventario de activos](inventario-de-activos.md).
Las [relaciones entre activos](relaciones-entre-activos.md) están implementadas: catálogo global y local, cinco tipos de serie, vínculos en ambos sentidos y retirada con auditoría. Los [puestos de trabajo](puestos-de-trabajo.md) están implementados, sin anidación, con sede y persona opcionales, composición exclusiva, recursos compartidos entre puestos vigentes e historial.
## Tickets: implementados
Tickets por compañía y consulta global con búsqueda/filtros, referencia corta global además de UUID, solicitante y responsable opcionales, canales, estados, prioridades y varios elementos afectados. Modales, altas rápidas, historial, altas idempotentes y protección de edición concurrente. Consultar [Tickets](tickets.md).
## Intervenciones: implementadas
Consulta global y por compañía, técnico, tiempos, diagnóstico, trabajo realizado, resultado y elementos afectados. Varias intervenciones por ticket o actuaciones internas sin ticket. Pasos opcionales, procedimientos versionados, comprobaciones obligatorias al finalizar, historial, idempotencia y control de concurrencia. Consultar [Intervenciones y plantillas](intervenciones-y-plantillas.md).
Las [relaciones entre activos](relaciones-entre-activos.md) están implementadas: catálogo global y local, cinco tipos de serie, vínculos en ambos sentidos y retirada con auditoría. Los [puestos de trabajo](puestos-de-trabajo.md) están implementados, sin anidación, con sede y responsable, composición exclusiva, ordenador principal e historial. El alta exige sede, al menos un activo y ordenador principal; el responsable es opcional.
## Licencias de software: registro implementado
@ -114,12 +106,7 @@ Las credenciales se resolverán con una solución específica; no almacenarlas c
## Decisiones pendientes
Permisos por técnico si llegan a necesitarse, despliegue, backups, recuperación administrativa y modelo de organización. El acceso y los usuarios ya están implementados; la base de compañías clientes, personas, departamentos, asignaciones y sedes está implementada. El inventario está implementado; los tickets están implementados; las intervenciones están implementadas.
## Plantillas de intervención
Implementadas las plantillas globales y propias por compañía con pasos ordenados, historial y seis procedimientos iniciales. Véase [Intervenciones y plantillas](intervenciones-y-plantillas.md). Las intervenciones concretas y la ejecución de los pasos están implementadas; las actuaciones sencillas admiten registro sin plantilla.
Permisos por técnico si llegan a necesitarse, despliegue, backups, recuperación administrativa y modelo de organización. El acceso y los usuarios ya están implementados; la base de compañías clientes, personas, departamentos, asignaciones y sedes está implementada. El inventario está implementado. Tickets, intervenciones y sus plantillas están [archivados](funcionalidades-archivadas.md) y no forman parte del alcance activo.
## Catálogo global de marcas: implementado

4
docs/puesta-en-marcha.md
View File

@ -18,7 +18,7 @@ pnpm db:up genera .env con secretos locales si no existe e inicia MariaDB en un
Abrir http://localhost:5173. La primera apertura permite crear el administrador inicial; las siguientes muestran el acceso. La API escucha en 127.0.0.1:3001 y la base de datos en 127.0.0.1:3307.
Una vez autenticado, Inicio utiliza `/dashboard` y cada sección tiene URL propia.
Se pueden abrir o recargar directamente `/tickets`, `/catalogs` o
Se pueden abrir o recargar directamente `/dashboard`, `/catalogs` o
`/companies/:companyId`. Consultar [Rutas del cliente](rutas-del-cliente.md) para
las fichas, los filtros y el requisito de fallback de la SPA en producción.
@ -87,6 +87,6 @@ pnpm --filter @metis/server start
## Alcance
Hay acceso, sesiones persistentes, gestión de usuarios, compañías clientes con contactos y sedes y una página inicial que comprueba la conexión. Inventario y tickets siguen pendientes. Las tablas nuevas se crean al arrancar la API mediante migraciones explícitas.
Hay acceso, sesiones persistentes, gestión de usuarios, compañías con personas, departamentos y sedes, inventario, recursos, puestos, perfiles y configuraciones. Inicio muestra indicadores, avisos y actividad. El [plan de desarrollo](plan-de-desarrollo.md) recoge las funciones disponibles y los pendientes; las funciones retiradas se describen en [funcionalidades archivadas](funcionalidades-archivadas.md). Las tablas nuevas se crean al arrancar la API mediante migraciones explícitas.
La API compilada todavía no sirve la interfaz estática. El despliegue, proxy HTTPS, backups y recuperación de acceso se definirán en una entrega posterior.

4
docs/puestos-de-trabajo.md
View File

@ -12,7 +12,7 @@ La ayuda aparece inmediatamente antes de Guardar y Cancelar. El listado permite
Un activo solo puede pertenecer a un puesto activo. El formulario marca como ocupados los activos reservados por otros puestos. El servidor valida la reserva bajo bloqueo de compañía en una transacción y la base de datos la protege con una clave única. Dos altas concurrentes no pueden reservar el mismo activo.
Desactivar un puesto conserva su composición y libera sus reservas. Un activo puede figurar en composiciones de puestos inactivos. Reactivar comprueba de nuevo la disponibilidad: si un activo está ocupado, hay que retirarlo de uno de los puestos antes de guardar. Retirar un activo del puesto no elimina el activo ni sus relaciones.
La operación de desactivación vacía la composición actual y libera sus reservas; conserva las revisiones. Un puesto inactivo anterior puede conservar composición. Reconstruirlo y reactivarlo comprueba de nuevo la disponibilidad de sus activos. Retirar un activo del puesto no elimina el activo ni sus relaciones.
Persona, sede y activos deben pertenecer a la misma compañía. Una persona debe estar activa para una nueva asignación. Si se desactiva después, se conserva la asignación anterior para revisión y puede retirarse. La persona no recibe acceso a Metis Desk.
@ -55,7 +55,7 @@ El listado y la ficha completa ofrecen **Desactivar** y **Eliminar definitivamen
Desactivar deja el puesto inactivo, vacía sus activos y retira el ordenador principal y responsable. Conserva nombre, sede, UUID e historial. Las asociaciones anteriores permanecen en las revisiones, pero no reservan activos ni representan usos vigentes. Repetir la desactivación no añade revisiones. También se puede aplicar a un puesto ya inactivo que conserve composición. Se puede editar posteriormente para reconstruirlo y reactivarlo, comprobando las reservas actuales.
Eliminar definitivamente borra el puesto, revisiones y asociaciones técnicas en una transacción y libera sus reservas, incluso si seguía activo. Conserva los activos, personas y sedes. Las referencias externas, incluidos tickets e intervenciones actuales o históricos, impiden la eliminación con `WORKSTATION_IN_USE`; la alternativa es desactivar. La comprobación utiliza las claves foráneas declaradas para proteger también futuras referencias. Un error no elimina parcialmente la composición ni sus reservas.
Eliminar definitivamente borra el puesto, revisiones y asociaciones técnicas en una transacción y libera sus reservas, incluso si seguía activo. Conserva los activos, personas y sedes. Las referencias externas declaradas mediante claves foráneas impiden la eliminación con `WORKSTATION_IN_USE`; la alternativa es desactivar. La comprobación utiliza las claves foráneas declaradas para proteger también futuras referencias. Un error no elimina parcialmente la composición ni sus reservas.
El puesto mantiene un único conjunto de activos. Los perfiles de usuario, correo, permisos, certificados y software pertenecen a personas, cuentas o al ordenador, y no son asignaciones directas del puesto. La desactivación libera la composición del puesto; conserva esos registros y no simula desinstalaciones ni retirada de accesos externos. Los perfiles sin un puesto vigente permanecen para revisión. La ficha actualiza los datos después de confirmar la operación; tras eliminar vuelve al listado.

4
docs/recursos-campos-y-plantillas.md
View File

@ -6,7 +6,7 @@ El catálogo global de recursos se abre desde Catálogos globales → Catálogo
Campos y plantillas de recursos son independientes de los de activos. Aunque se llamen igual, tienen UUID, datos, disponibilidad y referencias diferentes. El servidor rechaza campos de activos en plantillas de recursos y plantillas de activos al registrar recursos, y viceversa. El módulo resources no depende del módulo assets.
Las altas y ediciones se abren en modal desde la cabecera o una acción explícita del listado. La ayuda está antes del pie con Guardar y Cancelar. Los selectores de campo y plantilla ofrecen alta rápida mediante SelectWithAction. Se permite un modal adicional; ese formulario no abre un tercer nivel. Una definición guardada permanece aunque se cancele el formulario principal.
Las altas y ediciones se abren en modal desde la cabecera o una acción explícita del listado. La ayuda está antes del pie con Guardar y Cancelar. La selección de campos utiliza CatalogFieldPickerDialog con selección múltiple y alta rápida; los selectores de plantilla utilizan SelectWithAction. Se permite un modal adicional; ese formulario no abre un tercer nivel. Una definición guardada permanece aunque se cancele el formulario principal.
## Definiciones y ámbitos
@ -87,7 +87,7 @@ Nombre, plantilla y estado siguen el contrato común. Todas las características
Se reutilizan proveedor, referencia, caducidad y descripción del catálogo de recursos. Los siete campos nuevos y la plantilla se incorporan de forma idempotente al arrancar, sin cambiar identidades, fichas existentes ni disponibilidad configurada. La plantilla de serie se puede editar globalmente o copiar para personalizarla en una compañía; se puede desactivar globalmente o para una compañía. La ayuda específica aparece al final del modal, antes de Guardar y Cancelar.
La ficha captura su especificación y conserva revisiones como cualquier recurso. Registrar una licencia no crea asignaciones, vínculos con aplicaciones/cuentas/equipos, avisos de vencimiento ni cálculos de capacidad. Estas relaciones y avisos quedan pendientes de una entrega posterior.
La ficha captura su especificación y conserva revisiones como cualquier recurso. Registrar una licencia no crea asignaciones ni calcula capacidad disponible. Está implementado el vínculo informativo con instalaciones de aplicaciones y sistemas operativos del ordenador, así como los avisos de vencimiento; véanse [Software del ordenador](software-del-ordenador.md) y [Dashboard de inicio](dashboard-inicio.md). Las asignaciones por cuenta/persona y la capacidad disponible siguen pendientes.
## Organización de campos

10
docs/revision-de-buenas-practicas.md
View File

@ -1,5 +1,11 @@
# Revisión de buenas prácticas
Informe de una revisión anterior, no un inventario ni una instrucción de implementación
vigente. Las cifras y resultados corresponden al cierre de aquella revisión. Para trabajar
sobre el código actual, consultar `AGENTS.md`, las guías normativas y las
[funcionalidades archivadas](funcionalidades-archivadas.md).
Revisión realizada el 2026-10-08 conforme a AGENTS.md y a los documentos de arquitectura
de capas, composición, flujo HTTP, contratos, pruebas y modelo DDD e identificadores.
Se consultaron también el patrón de listados y los componentes de interfaz.
@ -19,7 +25,7 @@ El inventario final contiene 756 archivos TypeScript/TSX propios, incluidas prue
| apps/web | 8 | Composición React, idioma, proveedores, dashboard integrado y pruebas |
| modules/core | 11 | Contratos de salud, rutas, acceso HTTP y pantalla técnica |
| modules/identity | 38 | Usuarios, sesiones, autenticación, contraseñas y formularios |
| modules/companies | 460 | Compañías, personas, departamentos, sedes, accesos, perfiles, correo, carpetas, aplicaciones, certificados, impresoras, teletrabajo, remotos, procesos, tickets, intervenciones, plantillas y dashboard |
| modules/companies | 460 | Compañías, personas, departamentos, sedes, accesos, perfiles, correo, carpetas, aplicaciones, certificados, impresoras, teletrabajo, remotos, procesos, plantillas de procesos y dashboard |
| modules/assets | 136 | Catálogos, marcas, inventario, relaciones, puestos y asistencia |
| modules/resources | 63 | Catálogos, inventario, características e integraciones |
| packages/rdx-ddd y rdx-utils | 9 | Identidad, entidades, agregados, Value Objects, Result y Maybe |
@ -38,7 +44,7 @@ packages/shadcn-ui/src/styles/globals.css. No se imprimieron ni versionaron arch
1. Inspección global y lectura normativa, con clasificación de patrones y riesgos.
2. Componentes propios compartidos, composición de identidad y formularios de accesos.
3. Catálogos e inventarios de activos y recursos; asistencia y relaciones.
4. Compañías, perfiles, configuraciones, procesos, tickets e intervenciones.
4. Compañías, perfiles, configuraciones, procesos y sus plantillas.
5. Fronteras HTTP, contraseñas, datos persistidos, logging y ciclo de vida del servidor.
6. Inventario completo y separación de modales, incluidos wrappers y altas anidadas.
7. Paneles del dashboard, navegación lateral y búsqueda global.

2
docs/teletrabajo.md
View File

@ -1,6 +1,6 @@
# Teletrabajo: autorización por persona
Primera parte del bloque de teletrabajo y accesos remotos. Documenta la autorización para trabajar fuera de la sede. Los equipos de origen, conexiones VPN y destinos se documentan en [Accesos remotos](accesos-remotos.md). La asistencia técnica remota queda pendiente y es independiente.
Primera parte del bloque de teletrabajo y accesos remotos. Documenta la autorización para trabajar fuera de la sede. Los equipos de origen, conexiones VPN y destinos se documentan en [Accesos remotos](accesos-remotos.md). La [asistencia técnica remota](asistencia-tecnica-remota.md) está implementada como función independiente.
## Reglas

2
docs/usuarios-y-acceso.md
View File

@ -12,7 +12,7 @@ Por ahora no existe un catálogo de roles. La cuenta inicial tiene una condició
La pantalla «Usuarios» está disponible en `/settings/users`, desde el menú global y el menú de cuenta del administrador. El listado se muestra dentro del espacio de Metis Desk; las altas, ediciones y restablecimientos de contraseña se abren en formularios modales.
Desde «Usuarios» el administrador puede crear cuentas, editar nombre y correo, activar/desactivar usuarios y restablecer contraseñas. No se borran cuentas: la desactivación conserva su identidad para las futuras relaciones con tickets e intervenciones.
Desde «Usuarios» el administrador puede crear cuentas, editar nombre y correo, activar/desactivar usuarios y restablecer contraseñas. No se borran cuentas: la desactivación conserva su identidad y la atribución de los cambios registrados en los historiales.
El administrador cambia su propia contraseña en «Mi contraseña», proporcionando la contraseña actual. El restablecimiento de otro usuario invalida sus sesiones. Su nueva contraseña debe comunicarse por un canal privado; no hay envío automático de correos.