Modelo de datos¶

Esta app comparte una única base de datos SQLite (ssigner.db, journal_mode=WAL) con el servicio de documentos ("Envío de Documentos y Mantenimiento"). No hay un servidor de base de datos aparte — es un archivo, en una ruta fija del servidor.

Diagrama de relaciones¶

erDiagram
    clientes ||--o{ procesos : "es dueño de"
    clientes ||--o{ usuarios : "tiene"
    certificados ||--o{ procesos : "usa"
    usuarios }o--o{ procesos : "usuario_procesos (N:N)"
    procesos ||--o{ documentos : "genera"
    clientes_api ||--o{ documentos : "origina (opcional)"

Qué escribe y qué lee esta app¶

Tabla	Quién la escribe	Esta app la...
`certificados`	Esta app	Escribe
`procesos`	Esta app	Escribe
`clientes`	Servicio de documentos	Solo lee (combo al configurar/editar un proceso)
`usuarios`	Servicio de documentos	No la usa
`usuario_procesos`	Servicio de documentos	No la usa
`clientes_api`	Servicio de documentos	No la usa
`documentos`	Servicio de documentos	No la usa directamente — esta app trabaja con archivos en disco, no con esta tabla; el servicio de documentos es quien correlaciona el archivo firmado con su fila en `documentos`

`certificados`¶

id                     INTEGER PRIMARY KEY
alias                  TEXT NOT NULL
serial                 TEXT NOT NULL UNIQUE
common_name            TEXT
repositorio            TEXT NOT NULL          -- 'Windows-My' | 'PKCS11'
ruta_pkcs11_libreria   TEXT
pkcs11_pin_cifrado     TEXT                    -- AES-256-GCM
fecha_emision          TEXT
fecha_expiracion       TEXT
estado_cache           TEXT NOT NULL DEFAULT 'DESCONOCIDO'
ultima_verificacion    TEXT
fecha_creacion         TEXT
fecha_modificacion     TEXT

`procesos`¶

Es, con diferencia, la tabla con más columnas del sistema (~50) — casi todas relacionadas a la apariencia de la firma. Las más relevantes para entender el flujo:

id                       INTEGER PRIMARY KEY   -- este es el idProcesoFirma
nombre                   TEXT NOT NULL
activo                   INTEGER NOT NULL DEFAULT 1
eliminado                INTEGER NOT NULL DEFAULT 0
certificado_id           INTEGER NOT NULL REFERENCES certificados(id)
cliente_id               INTEGER REFERENCES clientes(id)   -- nullable
ruta_entrada             TEXT NOT NULL
ruta_salida              TEXT NOT NULL
ruta_error               TEXT
retencion_habilitada     INTEGER NOT NULL DEFAULT 0
retencion_cantidad       INTEGER
retencion_unidad         TEXT
perfil_firma             TEXT
algoritmo_hash           TEXT DEFAULT 'SHA256'
firma_visible            INTEGER DEFAULT 1
firma_pagina             TEXT DEFAULT '1'
firma_paginas_varias     INTEGER DEFAULT 0

-- posición del recuadro de firma, perfil vertical
firma_x, firma_y, firma_ancho, firma_alto                              REAL

-- posición del recuadro de firma, perfil horizontal (independiente del vertical)
firma_x_horizontal, firma_y_horizontal,
firma_ancho_horizontal, firma_alto_horizontal                          REAL

-- apariencia: estilo, texto, imagen, alineaciones, paddings (~30 columnas más)
-- ver el código fuente (Proceso.java) para el listado completo

tsa_url, tsa_usuario, tsa_password_cifrado                             TEXT
glosa_habilitar, glosa_url, glosa_contenido,
glosa_qr_habilitar, glosa_barras_habilitar                             ...

fecha_creacion, fecha_modificacion                                     TEXT

Ver Configuración de procesos para el significado funcional de estos campos.

Migraciones¶

Esta app corre las migraciones de esquema al arrancar, para toda la base compartida (no solo sus propias tablas):

schema.sql usa CREATE TABLE IF NOT EXISTS — nunca destruye una tabla existente, solo crea las que faltan (una instalación nueva sobre una base ya poblada no pierde datos).
Agregar una columna nueva a una tabla ya desplegada necesita un paso aparte: un mecanismo idempotente verifica con PRAGMA table_info si la columna ya existe, y si no, ejecuta el ALTER TABLE ADD COLUMN correspondiente. Esto es lo que permite instalar una versión nueva de esta app encima de una base de datos de producción existente, sin tocarla a mano ni perder nada.

Esto aplica también a las columnas que "pertenecen" al servicio de documentos (por ejemplo, cuando se agregaron clientes/usuarios para el modelo multi-tenant) — la migración corre desde acá para toda la base, sin importar cuál de los dos componentes sea el dueño habitual de esa tabla.