Version: 1.8.0

Actualizar desde versiones 1.4 a 1.5

Consideraciones

Esta guía lo lleva en el proceso de actualizar una instalación pre-existente de EEI. Tenga en cuenta que:

la versión requerida de EEI en ejecución es la v1.4.0 (última al generar esta guía, no se probaron versiones previas)
se actualiza toda la solución EEI que se despliega con Docker

Sudocu

Antes de actualizar

Antes de actualizar es necesario realizar un backup de la base de datos.

pg_dump -h DB_HOST -U DB_USER -p DB_PORT sudocu > sudocu.$(date -I).sql

Borrar el stack actual:

docker stack rm sudocu

Nota: esto elimina tanto los servicios del stack como los configs (que levantan los archivos .json de configuración). Si necesita, puede actualizarlos en este punto.

Actualizar base PostgreSQL

Finalmente, ejecutamos el proceso de migración de la base de datos.

docker run --rm \
  --env SUDOCU_DB_HOST=ip-host-db-sudocu \
  --env SUDOCU_DB_NAME=sudocu \
  --env SUDOCU_DB_PORT=5432 \
  --env SUDOCU_DB_USER=postgres \
  --env SUDOCU_DB_PASSWORD=postgres \
  ungs/sudocu-db-instalador:1.3.11

Nota: Tener en cuenta que SUDOCU_DB_HOST debe apuntar al host donde corre el PostgreSQL que contiene dicha base.

Control de duplicados

Es posible que, por algunos casos de cambios de configuración que se hayan aplicado en numeradores activos a lo largo de las versiones, se produjeran modificaciones en los objetos del número de los documentos que resultaran en que documentos del mismo tipo tuvieran objetos número diferentes pero en los frontends se visualizaran con el mismo número.

En este sentido, puede ocurrir que si existen casos de este tipo dentro del sistema, ahora al ejecutar la migración de la base de datos a 1.3.5 se produzca un error de llave duplicada con la key "id_tipo_numero_asignado_sudocu_documentos_un". Esto surge a partir de una validación que se incorpora a partir de dicha versión para que no pueda haber en todo el sistema dos documentos del mismo tipo con el mismo número visible en los frontends. La restricción ya operaba a nivel del conjunto de componentes del objeto "número", pero en este caso se refuerza respecto a la cadena ya procesada que da por resultado el número que se visibiliza en los frontends, y no en el conjunto de sus componentes.

Si ocurre el error de llave duplicada, es posible ejecutar la siguiente consulta para revisar cuales son los casos que contienen el "numero asignado" repetido. Esta consulta nos devolverá además del id del documento, el tipo, el número, etc, también una sugerencia para el arreglo del mismo y la información de en que usuario / area se encuentra el documento.

WITH numeros AS (
	SELECT id_tipo, nro->>'numero_asignado' AS numero_asignado, count(*) 
	FROM sudocu.documentos 
	WHERE nro->>'numero_asignado' IS NOT NULL 
	GROUP BY id_tipo, nro->>'numero_asignado'
	HAVING count(*) > 1 ORDER BY count(*) DESC 
), 
numeros_duplicados AS (
	SELECT 
	d.id AS id_documento, 
	id_tipo, 
	de.nombre AS estado,
	dt.nombre AS tipo_documento,
	dt.esencia AS esencia,
	d.nro AS objeto_nro, 	
	d.nro->>'numero_asignado' as numero_asignado, d.nro->>'numero_asignado' || ' *fix-' || ROW_NUMBER() OVER (PARTITION BY d.id_tipo ORDER BY nro->>'numero_asignado') AS  nro_fix,	 
	a.nombre AS area, 
	u.nombre||' '||u.apellido AS usuario,
	v.nombre AS vista
	FROM sudocu.documentos d
	inner JOIN sudocu.documentos_vistas dv ON d.id = dv.id_documento 
	left JOIN sudocu.areas a ON dv.id_area = a.id
	left JOIN sudocu.documentos_estados de ON d.estado = de.id
	LEFT JOIN sudocu.documentos_tipos dt ON d.id_tipo = dt.id
	left JOIN sudocu.usuarios u ON dv.id_usuario = u.id
	LEFT JOIN sudocu.vistas v ON dv.cod_vista = v.codigo 
	WHERE nro->>'numero_asignado' IN (SELECT numero_asignado FROM numeros) AND d.id_tipo IN (SELECT id_tipo FROM numeros) AND v.nombre IS NOT NULL  
	GROUP BY d.id, nro->>'numero_asignado', de.nombre, dt.nombre, dt.esencia, a.nombre, u.nombre, u.apellido, v.nombre
	ORDER BY nro->>'numero_asignado', id_tipo
)
SELECT * FROM numeros_duplicados 

Un posible paliativo es revisar caso por caso los números de documentos duplicados y ver de que manera se resuelven manualmente. Si no es posible hacerlo en el momento, es posible correr el siguiente SQL para agregarles un prefijo a cada núméro de documento duplicado, en la forma "*fix-" que permita identificarlos en una revisión posterior. La cadena "*fix-" puede ser también reemplazada por el señalamiento que cada uno desee agregar al final del número con el problema.

WITH numeros AS (
	SELECT id_tipo, nro->>'numero_asignado' AS numero_asignado, count(*) 
	FROM sudocu.documentos 
	WHERE nro->>'numero_asignado' IS NOT NULL 
	GROUP BY id_tipo, nro->>'numero_asignado'
	HAVING count(*) > 1 ORDER BY count(*) DESC 
), 
numeros_duplicados AS (
	SELECT 
	d.id AS id_documento, 
	id_tipo, 
	de.nombre AS estado,
	dt.nombre AS tipo_documento,
	dt.esencia AS esencia,
	d.nro AS objeto_nro, 	
	d.nro->>'numero_asignado' as numero_asignado, d.nro->>'numero_asignado' || ' *fix-' || ROW_NUMBER() OVER (PARTITION BY d.id_tipo ORDER BY nro->>'numero_asignado') AS  nro_fix,	 
	a.nombre AS area, 
	u.nombre||' '||u.apellido AS usuario,
	v.nombre AS vista
	FROM sudocu.documentos d
	inner JOIN sudocu.documentos_vistas dv ON d.id = dv.id_documento 
	left JOIN sudocu.areas a ON dv.id_area = a.id
	left JOIN sudocu.documentos_estados de ON d.estado = de.id
	LEFT JOIN sudocu.documentos_tipos dt ON d.id_tipo = dt.id
	left JOIN sudocu.usuarios u ON dv.id_usuario = u.id
	LEFT JOIN sudocu.vistas v ON dv.cod_vista = v.codigo 
	WHERE nro->>'numero_asignado' IN (SELECT numero_asignado FROM numeros) AND d.id_tipo IN (SELECT id_tipo FROM numeros) AND v.nombre IS NOT NULL  
	GROUP BY d.id, nro->>'numero_asignado', de.nombre, dt.nombre, dt.esencia, a.nombre, u.nombre, u.apellido, v.nombre
	ORDER BY nro->>'numero_asignado', id_tipo
)
UPDATE sudocu.documentos 
SET nro = jsonb_set(nd.objeto_nro,'{numero_asignado}', to_jsonb(nd.nro_fix)) 
FROM numeros_duplicados nd
WHERE id = nd.id_documento

Con esto, se puede proceder a correr el proceso de migración de la base de datos PostgreSQL. Luego es cuestión de filtrar los documentos por este prefijo "fix-" o la cadena que uno haya elegido y resolver su situación particular.

Aclaramos que la ejecución de este script automático no afecta de ninguna manera a los numeradores activos, simplemente marca visualmente al número que se ve en el frontend, solo en los casos que se encuentran duplicados. Por ejemplo, si tenemos dos documentos que desde el frontend se ven como NOTA 23 / 2020, ejecutando este script se verá:

NOTA 23 / 2020 *fix-1
NOTA 23 / 2020 *fix-2

El script no modificará ni afectará ningún número asignado antes o después de los números duplicados.

Desplegar la nueva versión

Realizar nuevo deploy:

docker stack deploy --with-registry-auth --compose-file sudocu.yml sudocu

Nota: Tener en cuenta que hay nuevas opciones en los JSON de configuración (archivo config-api-server.json), que requieren ser actualizados. Estos nuevos parámetros son:

limite_tamanio_vista_previa_expedientes, valor por defecto: -1, se encuentra en gestion->expedientes->limite_tamanio_vista_previa_expedientes
reutilizar_numeros_documentos_anulados, valor por defecto: false, se encuentra en gestion->reutilizar_numeros_documentos_anulados

Consideraciones​

Sudocu​

Antes de actualizar​

Actualizar base PostgreSQL​

Control de duplicados​

Desplegar la nueva versión​