Version: 1.3.10

FAQ

FAQ Técnico#

Si estoy usando la integración con Araí, ¿debo dar de alta los usuarios en ambos lados o puedo configurar el alta automática de los mismos?#

En la configuración del api-server, en la dimensión auth.saml, existen entre otros estos dos parámetros:

"auth":{
      "saml": {
       ....
        "crearSiNoExiste": false,
       "perfilXDefecto": 1,
        ...
      }
}

Si se coloca true en el campo "crearSiNoExiste", cuando se loguea en Araí, si el usuario no existe en SUDOCU, se creará automáticamente. Lo dará de alta sin ningún tipo de configuración y le asginará el perfil que se setee en "perfilXDefecto", siendo:

1 = administrador: tendrá acceso a todos los módulos.
2 = usuario: tendrá acceso al módulo de Gestión y al MPD.
3 = invitado: sólo tendrá acceso al MPD.

Instalar tzdata en imagen de estampador para corregir fecha y hora#

El contenedor de stamper está en UTC y pone la hora en UTC en la parte gráfica. Se le puede pasar la envvar TZ=America/Argentina/Buenos_Aires pero como la imagen está basada en Alpine, necesita tener tzdata instalado. Para instalarlo se recomienda utilizar un archivo entrypoint en el despliegue del stamper. Para esto es necesario crear en la carpeta expedientes/prod/arai/ de los archivos de despliegue el archivo entrypoint.sh:

entrypoint.sh

#!/usr/bin/env sh

# Se instala tzdata para configurar la zona horaria. Se realiza desde variables de entorno
apk add --no-cache tzdata

java -Xms512m -Xdebug -cp /app/resources:/app/classes:/app/libs/* ar.com.nomi.necro.estampatodo.Application

Luego en el archivo docs.yml, en el bloque correspondiente a "stamper" agregar el entrypoint y la variable de entorno "TZ" con el valor "America/Buenos_Aires".

docs.yml

...

  stamper:
    image: ungs/sudocu-estampador:latest
    ports:
      - "8086:8080"
    # Variable de entorno TZ
    environment:
      TZ: "America/Buenos_Aires"
    # Entrypoint
    entrypoint: "/app/entrypoint.sh"
    deploy:
      placement:
        constraints: [node.hostname == granja121]
    configs:
      - source: application_properties
        target: /app/resources/application.properties
      - source: signature_image
        target: /app/resources/firma.png
      # Entrypoint provisorio
      - source: entrypoint
        target: /app/entrypoint.sh
        mode: 0755
    secrets:
      - source: key_store_location
        target: /app/resources/sudocu.p12

...

Por último eliminar el stack de arai-documentos

docker stack rm docs

y volver a desplegarlo

docker stack deploy --with-registry-auth -c docs.yml docs

Configuración para agregar Fuentes Tipográficas externas#

Pasos para agregar fuentes a los template de PDF:

En config-api-server.json agregar dentro del key gestion lo siguiente:

"gestion":{
 "fonts":[
    {
       "name":"Oswald=oswald",
       "style":"https://fonts.googleapis.com/css2?family=Oswald&display=swap"
    }
 ]
}

En el .yml de deploy agregar en el servicio de pdf el siguiente volumen:

volumes:

 -./fonts:/usr/share/fonts/truetype/sudocu

En la carpeta del deploy crear la carpeta fonts y por cada fuente que se agrega en el config crear una carpeta y copiar dentro de ella todos los archivos TrueType de la familia que se establezca en la configuración. Por ejemplo para fuentes de google descargar el zip y descomprimirlo dentro de la carpeta de manera que quede:

/fonts
-- /Oswald
---- /OFL.txt
---- /Oswald-Bold.ttf
---- /Oswald-ExtraLight.ttf
---- /Oswald-Light.ttf
---- /Oswald-Medium.ttf
---- /Oswald-Regular.ttf
---- /Oswald-SemiBold.ttf
---- /Oswald-VariableFont_wght.ttf
---- /README.txt

Finalmente eliminar stack sudocu y volver a realizar el deploy.

Caso de fuentes que no son de Google

En caso de necesitar cargar fuentes que no sean de google, la url colocada en el config-api-server.json tendría que apuntar a un archivo .CSS que tenga las definciones de las fuentes. Si se ingresa a la url mencionada anteriormente https://fonts.googleapis.com/css2?family=Oswald&display=swap se puede observar que devuelve un css con una serie de estilos. En el caso de una fuente no-google se debe replicar lo mismo con una url propia. Existen generadores de font-face online, por ejemplo: https://transfonter.org.

Anonimizar la base de datos SUDOCU#

Los pasos generales para anonimizar una base de datos de SUDOCU son:

Hacer un backup de la base de datos que se desea anonimizar.
Levantar ese backup a una base de datos de prueba.
Correr los scripts para anonimizar en la base de datos de prueba.

Se detallan a continuación los scripts para anonimizar documentos, usuarios y personas sin necesidad de instalar librerías externas a postgres:

WITH docs AS (SELECT d.id, d.nro->>'nro' AS nro, d.nro->>'anio' AS anio, dt.nombre_singular FROM sudocu.documentos d
INNER JOIN sudocu.documentos_tipos dt ON d.id_tipo=dt.id)
UPDATE sudocu.documentos SET titulo = docs.nombre_singular || ' nro:' || COALESCE (docs.nro,'#') || '/' || COALESCE (docs.anio, '#'), atributos = '{"contenido": "Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut fringilla. Suspendisse convallis viverra nunc. Etiam magna. Etiam nunc. Praesent leo nibh, lacinia at, blandit ac, congue eget, nunc. Sed nec dui. Proin tincidunt turpis nec justo. Vivamus gravida interdum elit. Etiam scelerisque. Quisque leo orci, placerat vel, lobortis in, eleifend quis, massa. Pellentesque lobortis. Maecenas pede. D."}' FROM docs
WHERE documentos.id = docs.id;


WITH docs AS (SELECT d.id, d.nro->>'nro' AS nro, d.nro->>'anio' AS anio, dt.nombre_singular FROM sudocu.documentos d
INNER JOIN sudocu.documentos_tipos dt ON d.id_tipo=dt.id)
UPDATE sudocu.documentos_versiones SET titulo = docs.nombre_singular || ' nro:' || COALESCE (docs.nro,'#') || '/' || COALESCE (docs.anio, '#'), atributos = '{"contenido": "Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut fringilla. Suspendisse convallis viverra nunc. Etiam magna. Etiam nunc. Praesent leo nibh, lacinia at, blandit ac, congue eget, nunc. Sed nec dui. Proin tincidunt turpis nec justo. Vivamus gravida interdum elit. Etiam scelerisque. Quisque leo orci, placerat vel, lobortis in, eleifend quis, massa. Pellentesque lobortis. Maecenas pede. D."}' FROM docs
WHERE documentos_versiones.id_original = docs.id;


Create or replace function random_string(length integer) returns text as
$$
declare
chars text[] := '{0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z,a,b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u,v,w,x,y,z}';
result text := '';
i integer := 0;
begin
if length < 0 then
  raise exception 'Given length cannot be less than 0';
end if;
for i in 1..length loop
  result := result || chars[1+random()*(array_length(chars, 1)-1)];
end loop;
return result;
end;
$$ language plpgsql;



UPDATE sudocu.usuarios SET dni = random_string(10), password = random_string(20), username = random_string(5)||'@ungs.edu.ar', email = random_string(5)||'@ungs.edu.ar', apellido = random_string(7);

UPDATE sudocu.personas SET nro_doc = random_string(10), apellido = random_string(7);

Ampliación de memory_limit y post_max_size en apache#

Para los entornos productivos del ecosistema de expediente electrónico, es necesario ampliar los valores de memory_limit y post_max_size en el apache / php del servicio de Arai-documentos. Los mismos ya fueron ampliados a 1024 MB el memory_limit y a 256 MB el post_max_size. A continuación se describen los pasos que se siguieron, por si fuera necesario modificar estos valores en el futuro:

El objetivo es modificar el memory-limit del Apache de documentos. A tal efecto vamos a crear una carpeta “config” en el directorio ./prod/arai y dentro esa carpeta creamos el archivo de texto apache.ini.

El contenido del archivo apache.ini debe ser:

memory_limit = 1024M
post_max_size = 256M

Expresado siempre en megas, pueden ser estos valores o el límite que necesiten. Luego de guardar el archivo y dentro de la carpeta ./prod vamos a crear el config de docker para poder modificar la configuración del deploy.

docker config create apache_memory_limit ./config/apache.ini

Luego vamos a editar el archivo docs.yml y al final del mismo vamos a agregar las siguientes líneas para vincular el config creado con el deploy siempre respetando la identación y cerciorándose de que la misma sea con espacios y no con tabs.

configs:
apache_memory_limit:
external: true

En el mismo archivo para el bloque “api” vamos a agregar la vinculación del config con el archivo de configuración de apache siempre respetando la identación igual que en el caso anterior.

services: api: configs:

source: apache_memory_limit target: /etc/php7/conf.d/app.ini

Con esto el último paso va a ser borrar el deploy y volverlo a levantar.

En caso de querer modificar algún otro parámetro de apache, alcanza con modificar el archivo creado apache.ini, agregar el parámetro deseado, borrar el config, volver a crearlo con el archivo modificado y re-ployar.

Volumen de adjuntos#

El api-server de sudocu almacena los archivos adjuntos de los documentos en un volumen local de docker. Cuando el sistema es desplegado en un cluster swarm con varios nodos, es necesario que el volumen se replique en cada uno de ellos. Hay herramientas como NFS o GusterFS que resuelven esta tarea, tal como se muestra en expedientes.siu.edu.ar y esta es la solución recomendada. No obstante, en algunos escenarios hay una solución alternativa que es anclar el despliegue del api-server en el mismo nodo donde se encuentra el volumen local. En este sentido mostramos aquí como implementar esta solución alternativa y también como resolver el problema de haber levantado api-server en un cluster sin haber contemplado la implementación de NFS.

Hacer que api-server levante siempre en el mismo nodo.

Los cambios a aplicar serían estas líneas en sudocu.yml:

 services:
       traefik-public:
       red-siu:
     deploy:
+      placement:
+        constraints:
+          - node.labels.sudocu.sudocu_files == true
       resources:
         limits:
           cpus: '0.50'

Después:

export NODE_ID=$(docker info -f '{{.Swarm.NodeID}}')
docker node update --label-add sudocu.sudocu_files=true $NODE_ID

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

Recuperar los archivos ya creados de los otros nodos. Se puede ver en qué nodos se levantó el contenedor con:

docker service ps sudocu_api-server

En cada nodo donde se haya levantado api-server hay que revisar la ruta donde se creó el volumen:

docker volume inspect sudocu_files
[
    {
        "CreatedAt": "2021-06-17T16:01:19Z",
        "Driver": "local",
        "Labels": {
            "com.docker.stack.namespace": "sudocu"
        },
        "Mountpoint": "[ruta_volumen_remoto]/sudocu_files/_data",
        "Name": "sudocu_files",
        "Options": null,
        "Scope": "local"
    }
]

Copiar esos datos al nodo en donde va a estar levantado el api-server:

rsync -av -e 'ssh' usuario@host: [ruta_volumen_remoto]/sudocu_files/_data/ [ruta_volumen_local]/sudocu_files/_data/

Cambiar el texto correspondiente a los Términos y Condiciones al agregar un nuevo canal de comunicación#

Para cambiar el texto correspondiente a Términos y Condiciones a aceptar en la operación para agregar un nuevo canal de notificaciones en la portada del sistema, se debe acceder a la Base SUDOCU, tabla config del schema SUDOCU y escribir la siguiente consulta:

UPDATE sudocu.config
SET valor= '{"texto":"texto elegido como términos y condiciones"}'
WHERE contexto='sudocu' and clave='acuerdo_canales'

Configuración de seguimientos y notificaciones por email#

SUDOCU permite recibir notificaciones por email al momento en que ocurren ciertos eventos con los documentos y/o contenedores. Para ello es importante establecer escenarios en que se desea notificar por email y que los usuarios de SUDOCU (a los cuales se desea notificar) tengan cargado al menos un correo electrónico válido como canal de comunicación, operación que se realiza desde la pantalla de portada de SUDOCU. El valor configurado para campo_destinatarios determinará si la casilla de email remitente recibirá o no una copia de los emails enviados como notificaciones. Se recomienda que el valor por defecto sea "para".

Para configurar correctamente las notificaciones de eventos por email, es necesario ingresar al archivo de configuración del api-server y parametrizar lo siguiente:

"email": {
   // Configuración de funcionalidad seguimientos
   "seguimientos": {
     "notificaciones": {
       // Variables disponibles para asunto y cuerpo: $novedad $tipo $numero $caratula $area_usuario_origen $estado $permalink
       "campo_destinatarios": "para|cc|cco", // Opciones: para|cc|cco|. Cuando el valor es "para" la notificación será enviada solo a la cuenta destinataria. Cuando el valor sea "cc" o "cco" también se enviará la misma notificación a la cuenta remitente.
       "asunto":"$novedad ($tipo)",
       "cuerpo":"Tipo: $tipo<br/>Número: $numero <br/>Carátula: $caratula<br/>Area y usuario de origen: $area_usuario_uario_origen <br/>Novedad: $novedad<br/>Estado: $estado<br/>link: $permalink<br/>",
       "escenarios": "compartir|enviar", // Opciones: remitir|enviar|solicitar|autorizar|rechazar|compartir
       "novedades":  {
         // Permite especificar el texto para cada evento
         "remitir": "Se remite un expediente",
         "enviar": "Se envía un documento",
         "solicitar": "Solicitud de autorización",
         "autorizar": "Solicitud autorizada",
         "rechazar": "Rechazo solicitud de autorización",
         "compartir": "Se comparte un documento" 
       }
     },
     // Configuración servidor de email
     "_comment": "Modo puede ser smtp o gmail",
     // "modo": "gmail" ó "modo": "smtp" 
     "modo": "gmail",
     // smtp
     "smtp": {
       "remitente": "",
       "host": "",
       "port": "",
       // "secure": false ó "secure": true
       "secure": true,
       "auth": {
         "user": "",
         "pass": "" 
       }
     },
     // gmail
     "gmail": {
       "remitente": "SUDOCU",
       "client_id": "",
       "client_secret": "",
       "refresh_token": "",
       "auth": {
               "user": "" 
       }
     }
   }
 },

Barra superior con información de commits#

alt text

En cada módulo de SUDOCU se encuentra disponible para visualizar información sobre branch y último commit en el que se encuentra el proyecto. Para poder visualizar esta información es necesario acceder a la base de datos SUDOCU y colocar en la tabla sudocu.config el valor de ambiente.desarrollo = true.

¿Qué implica el parámetro "mostrar_alerta_documento_ya_existente"?#

En la versión 1.3.1 de SUDOCU se incorpora el parámetro "mostrar_alerta_documento_ya_existente" en el archivo de configuración del api-server, con dos posibles valores: true o false.

Para el caso de que el valor sea true, al momento de incorporar un contenedor a otro contenedor, se alerta de la existencia de un mismo documento en ambos contenedores. Y si el valor es false, no se alertará sobre la presencia de un mismo documento entre contenedores a incorporar uno en otro.

Configuración del certificado para el IDP en la integración Araí - Usuarios#

A partir de la versión 1.3.0 es obligatorio configurar un certificado para el IDP en la integración con Araí - Usuarios. Por esto es necesario generar un certificado .pem a partir del .crt que se encuentra en el proyecto de deploy de expedientes (expedientes.siu.edu.ar). Una vez generado el .pem es necesario seguir una serie de pasos para configurar el deploy de SUDOCU con este certificado.

Obtener el certificado de IDP convirtiendo el archivo .crt ubicado en la ruta en donde se generó el .crt de araí:
openssl x509 -in certificado_idp.crt -out certificado_idp.pem -outform PEM
Ejecutar la siguiente línea para crear un secret con el contenido del certificado:
docker secret create sudocu_idp_cert_pem certificado.pem
Verificar en el archivo sudocu.yml que contenga las siguientes línes. En caso contrario agregarlas en la sección de secrets del bloque de api-server en sudocu.yml:

secrets:
  ...
  - source: sudocu_idp_cert_pem         
    target: /etc/ssl/certs/certificado_idp.pem

Agregar el secret en el bloque de secrets al final del archivo sudocu.yml:

secrets:
  sudocu-api-server:
      external: true
  sudocu_idp_cert_pem:
      external: true

Configurar en config-api-server.json el siguiente parámetro:
...
"auth": {
...
"saml": {
...
"cert_pem" : "/etc/ssl/certs/certificado_idp.pem"
}
}
...
Borrar servicio y config de api-server y reiniciar stack sudocu:
docker service rm sudocu_api-server
docker config rm sudocu_api-server_config
docker stack deploy --compose-file sudocu.yml sudocu

Configuración de duración de sesión#

Para modificar la duración de la sesión de SUDOCU se debe editar el parámetro servidor.seguro.cookies.maxAge dentro del archivo config-api-server.json:

"servidor":{
  ...
  "seguro": {
    ...
    "cookies": {
      "maxAge": 3600000 // Milisegundos en los expirará la cookie
    }
  }
  ...
}

Configuración del parámetro saltRounds para solucionar error el crear usuarios#

El problema se da porque aún se sigue utilizando el valor del parámetro saltRounds para generar un password aleatorio cuando se crea un usuario y si bien el bloque de seguridad fue deprecado en el config, el parámetro saltRounds se sigue utilizando y no tenía un valor por defecto. A partir de la versión 1.3.3 se agregó el valor por defecto en el config del api-server. Si surge el problema en versiones anteriores a 1.3.3 se puede resolver agregando al config del api-server:

"seguridad": { 
   "saltRounds": 5 
},

Query para detectar numeración repetida#

En la versión 1.3.5 se agrega una restricción en la tabla de documentos para evitar que puedan existir documentos con el número visible repetido. Si bien los números de documento ya poseen una restricción que evita que haya objetos de números repetidos a través de la comparación de cada una de sus claves, es posible que ante cambios en numeradores o antiguos bugs haya documentos que posean el objeto número con una clave única, pero que el valor de "numero_asignado" (que es el valor visible en el frontend) este repetido. Por este motivo, para detectar si hay números visibles repetidos se puede ejecutar la siguiente consulta que devuelve el id del documento, el id del tipo de documento, el objeto nro, el "numero_asignado" y la sugerencia de arreglo:

WITH numeros AS (
 SELECT id_tipo, nro->>'numero_asignado' AS numero_asignado, array_agg(id) AS ids, count(*) 
 FROM sudocu.documentos 
 WHERE nro->>'numero_asignado' IS NOT NULL AND estado NOT IN (22)
 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' || ' *#' || 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 d.id = ANY(SELECT unnest(ids) 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

Si se encontraran números repetidos con la consulta anterior, es recomendable analizar caso por caso para ver cual fue el problema y corregirlo. No obstante, si no se dispone del tiempo suficiente para hacer esto, la siguiente consulta reemplaza todos los números repetidos agregandole en el número asignado la sugerencia de arreglo de la consulta anterior (#fix-1, #fix-2, #fix-3, etc) por cada grupo de números repetidos de un mismo tipo.

WITH numeros AS (
 SELECT id_tipo, nro->>'numero_asignado' AS numero_asignado, array_agg(id) AS ids, count(*) 
 FROM sudocu.documentos 
 WHERE nro->>'numero_asignado' IS NOT NULL AND estado NOT IN (22)
 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' || ' *#' || 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 d.id = ANY(SELECT unnest(ids) 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

Una vez hecho esto se podrá actualizar a la versión 1.3.5 sin problemas, y luego se podrá buscar aquellos documentos que hayan quedado marcados con el #fix- para estudiar caso por caso.

¿Qué implicancias tienen el parámetro "creador_recaratular" y el permiso para recaratular?#

En la acción recaratular interviene el parámetro "creador_recaratular", presente en el archivo de configuración del api-server y el permiso específico en el módulo "MPC".

En todo momento y bajo cualquier tipo de configuración, cualquier usuario podrá recaratular todos los documentos en estado borrador que se encuentren en las bandejas de documentos personales o en la bandeja de documentos de un área.

Desde la versión 1.3.10 de SUDOCU, existen 2 escenarios posibles de configuración para la acción recaratular Expedientes o Trámites:

Parámetro "creador_recaratular" con valor true/false y usuario con permiso para Recaratular:
El usuario podrá recaratular todos los expedientes y trámites en cualquier momento. No existe limitación.
Parámetro "creador_recaratular" con valor true/false y usuario sin permiso para Recaratular:
El usuario solo podrá recaratular expedientes y trámites creados por el mismo usuario antes del primer pase. No podrá recaratular expedientes/trámites creados por otro usuario.