David
ba562ad06f
- 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.
9.7 KiB
Persistencia relacional
Se mantiene Sequelize 6 y MariaDB. El criterio del proyecto es almacenar datos de negocio en columnas y relaciones, sin documentos JSON. Los objetos values del dominio y el JSON del contrato HTTP no implican columnas JSON.
Modelo de almacenamiento
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 |
|---|---|
| Compañías, personas, departamentos, sedes, usuarios y marcas | Columnas y relaciones |
| Catálogo e inventario de activos | Definiciones, campos tipados, especificaciones y revisiones en columnas y tablas |
| Catálogo e inventario de recursos | Definiciones, opciones, secciones, especificaciones congeladas, valores tipados e integración en columnas/tablas |
| Puestos de trabajo | Nombre, estado y referencias en columnas; activos exclusivos/compartidos por puesto y revisión en tablas |
| Asistencia técnica de activos | Referencia al recurso de asistencia, destino, VPN, preferencia, estado y notas en columnas actuales e históricas |
| Perfiles de usuario | Nombre, estado, notas y referencias en columnas actuales e históricas |
| Teletrabajo | Estado, periodo, notas y persona en columnas actuales e históricas |
| Aplicaciones, certificados, impresoras y carpetas del perfil | Valores escalares y referencias en columnas actuales e históricas |
| Cuentas y accesos | Subtipos en tablas actuales e históricas; permisos de necesidades en asociaciones ordenadas |
| 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 |
| 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.
Recursos
Las tablas principales son resource_definitions, resource_template_fields, resources y resource_revisions. Sus tablas dependientes son:
resource_field_choices: opciones ordenadas de cada campo.resource_template_sections: secciones ordenadas, identificadas por(templateId, id); copiar una plantilla puede conservar los identificadores internos de sus secciones.resource_specification_sections,resource_specification_fieldsyresource_specification_field_choices: definición congelada al crear el recurso.resource_characteristicsyresource_revision_characteristics: valores actuales e históricos con columnas independientes de texto, número, booleano y fecha.
La ausencia de una característica se representa mediante ausencia de fila. Una cadena vacía, 0 y false siguen siendo valores y se conservan. Las fechas se leen como fechas ISO. La especificación congelada no se reemplaza por el estado actual del catálogo.
Los vínculos de integración con buzones y accesos se conservan en columnas con claves foráneas. Eliminar una referencia externa no debe eliminar en cascada el recurso ni sus revisiones. Las proyecciones de compatibilidad de correo/accesos conservan las integraciones y sus identidades; sus lectores y escritores también utilizan columnas y tablas normalizadas.
Puestos, perfiles y configuraciones
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.
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 }).
La lectura reconstruye los Value Objects y agregados desde columnas y relaciones, valida sus referencias e historial y rechaza persistencia inconsistente. Los cambios se guardan mediante transacciones. Repetir la inicialización no añade revisiones ni modifica valores de negocio.
Las pruebas de integración utilizan exclusivamente metis_desk_test y comprueban creación del esquema vacío, operaciones HTTP, restricciones, historial, concurrencia e idempotencia.
Cuentas y accesos
Se conservan las raíces access_workspaces, access_items y access_revisions, y las proyecciones access_references y access_person_references. La raíz identifica compañía/ámbito y tipo; las revisiones mantienen UUID, secuencia, autor e instante. Cada tipo tiene una tabla de valores y otra de valores históricos:
| Tipo | Actual | Histórica |
|---|---|---|
| Sistema | access_system_values | access_system_revision_values |
| Tipo de recurso | access_resource_type_values | access_resource_type_revision_values |
| Permiso | access_permission_values | access_permission_revision_values |
| Plantilla de grupo | access_template_values | access_template_revision_values |
| Entorno | access_environment_values | access_environment_revision_values |
| Cuenta | access_account_values | access_account_revision_values |
| Titular/usuario de cuenta | access_account_person_values | access_account_person_revision_values |
| Grupo | access_group_values | access_group_revision_values |
| Pertenencia a grupo | access_membership_values | access_membership_revision_values |
| Proyección de recurso | access_resource_values | access_resource_revision_values |
| Permiso concedido | access_grant_values | access_grant_revision_values |
| Necesidad | access_need_values | access_need_revision_values |
| Cobertura | access_coverage_values | access_coverage_revision_values |
ownerId es clave primaria y foránea a la raíz o revisión correspondiente. Las referencias entre elementos y personas tienen claves foráneas. access_need_permissions y access_need_revision_permissions conservan permisos y orden; no permiten duplicar un permiso dentro de la misma necesidad. Las vistas access_current_values y access_historical_values unen columnas de los subtipos para lecturas comunes, sin generar JSON SQL.
El catálogo global y los ámbitos de compañía mantienen sus reglas. Se conservan titularidad histórica, cuentas compartidas, caducidad opcional, grupos, permisos, coberturas, bloqueos de concurrencia y proyecciones de referencias.
Correo y accesos remotos
mailboxes, mailbox_uses, mail_configurations y sus revisiones almacenan dirección, tipo/contexto, cuenta vinculada, personas autorizadas, periodo, perfil, protocolo, estado y notas en columnas. snapshotKind identifica el alcance de cada configuración de correo: persona/cuenta/activo o perfil/buzón. Las restricciones SQL exigen las referencias apropiadas a cada variante.
remote_connections y remote_connection_revisions mantienen persona, tipo de origen, activo corporativo cuando corresponde, sede/red, método, VPN, estado y notas. El destino se separa en targetAssetId y targetResourceId, con claves foráneas reales. Las restricciones SQL impiden destinos incompatibles, un origen personal con activo corporativo y acceso al propio equipo como destino.
Los repositorios, lectores de dashboard/procesos y proyecciones de recursos reconstruyen los contratos de dominio. Una persona puede tener múltiples configuraciones y cada cambio conserva el historial.
Procesos
process_templates y process_template_revisions tienen columnas de nombre, tipo, estado y notas. Sus pasos ordenados se guardan en process_template_instructions y process_template_revision_instructions.
person_processes y person_process_revisions tienen persona, plantilla, nombre congelado de plantilla, nombre del proceso, tipo, estado y notas. person_process_tasks y person_process_revision_tasks conservan UUID de tarea, orden, título, estado, notas y referencia de revisión (tipo, UUID, etiqueta y procedencia).
La referencia de una tarea es información congelada para revisar una situación, no una asignación viva. No lleva FK al elemento revisado: debe conservarse aunque ese elemento se retire o elimine. Sí existen claves foráneas entre procesos, personas, plantillas, revisiones y sus tablas dependientes. Las instrucciones originales y tareas históricas no se reemplazan por una plantilla modificada.
Sesiones
http_sessions almacena sid, expiración, fechas de creación/actualización, usuario, versión de autenticación, token CSRF y opciones de cookie. SequelizeSessionStore implementa el contrato de express-session mediante columnas tradicionales.
Se conservan duración original y expiración de la cookie, opciones booleanas, autenticación y protección CSRF. touch renueva la cookie sin sobrescribir autenticación o CSRF de otra petición. Las sesiones vencidas no se recuperan y se purgan al guardar sesiones; la expiración tiene índice. No se necesita temporizador de fondo. El almacén rechaza atributos de sesión desconocidos en lugar de descartarlos.
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 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.