Version: 1.4.19

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.

Fuentes cuyo nombre contenga un espacio

En caso de que la fuente a instalar tenga en su nombre un espacio, deberá respetarse de igual manera en el campo "name" dentro del key del archivo config-api-server.json

Ejemplo:

{
  "name": "Rubik Bubbles=rubik bubbles",
  "style": "https://fonts.googleapis.com/css2?family=Rubik+Bubbles&display=swap"
}

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 = CASE 
        WHEN atributos IS NULL THEN 
            '{"contenido": null}'::json
        WHEN (atributos->>'contenido') IS NULL OR (atributos->>'contenido') = '' THEN
            atributos::json
        ELSE
            (atributos::jsonb || '{"contenido": "Lorem ipsum"}'::jsonb)::json
    END
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 = CASE 
        WHEN atributos IS NULL THEN 
            '{"contenido": null}'::json
        WHEN (atributos->>'contenido') IS NULL OR (atributos->>'contenido') = '' THEN
            atributos::json
        ELSE
            (atributos::jsonb || '{"contenido": "Lorem ipsum"}'::jsonb)::json
    END
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(7),
    password = random_string(10),
    username = random_string(8)||'@uunn.edu.ar',
    email = random_string(8)||'@uunn.edu.ar',
    nombre = random_string(8),
    apellido = random_string(8);

UPDATE sudocu.personas
SET nro_doc = random_string(8),
    nombre = random_string(8),
    apellido = random_string(8);

UPDATE sudocu.areas
SET nombre = sigla;

UPDATE sudocu.usuarios_cuentas
SET email = random_string(8) || '@uunn.edu.ar'
WHERE email NOT IN ('admin@sudocu.edu.ar')
AND id_usuario_idp NOT IN ('adminsudocu');

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 4096 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 = 4096M
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. Si existe la sección configs, se deben agregar las siguientes lineas:

apache_memory_limit:
external: true

En caso de no existir, se debe agregar la sección completa 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 la bandeja de documentos personales.

Desde la versión 1.3.10 de SUDOCU, existen 3 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 y usuario sin permiso para Recaratular:
- El usuario podrá recaratular en cualquier momento los expedientes creados por él mismo.
- El usuario no podrá recaratular expedientes creados por otro usuario en ningun momento.
Parámetro "creador_recaratular" con valor false y usuario sin permiso para Recaratular:
- El usuario podrá recaratular únicamente antes del primer pase aquellos expedientes creados por él mismo.
- El usuario no podrá recaratular expedientes creados por otro usuario en ningun momento.

Parametrización de notificaciones por mail#

Los emails que se enviarán como resultado de las notificaciones automáticas, serán enviados con la estructura que se configure en el apartado de "seguimientos" del archivo de configuración del api-server. - CC: Con Copia - CCO: Con Copia Oculta
Si el parámetro "campo_destinatarios" tiene el valor "para", cuando se estructura el mail automático se establecen en el campo "para" todas las direcciones de emails de las personas a ser notificadas. Los campos "CC" y "CCO" quedarán vacíos.

alt text

Si el parámetro "campo_destinatarios" tiene el valor "CC", cuando se estructura el mail automático se establecen en el campo "CC" todas las direcciones de emails de las personas a ser notificadas. El campo "para" se completará con la dirección de mail configurada en el parámetro "remitente" y el campo "CCO" quedará vacío.

alt text

Si el parámetro "campo_destinatarios" tiene el valor "CCO", cuando se estructura el mail automático se establecen en el campo "CCO" todas las direcciones de emails de las personas a ser notificadas. El campo "para" se completará con la dirección de mail configurada en el parámetro "remitente" y el campo "CC" quedará vacío.

alt text

¿Cómo se crea una carpeta MPD pública?#

Es posible crear una carpeta pública en el módulo MPD. De esta manera se visualizarán públicamente los documentos que se incorporen.

Caso de ejemplo:

Mi universidad necesita publicar a toda la comunidad las resoluciones del Consejo Superior.

Antes de crear una carpeta aconsejamos leer el apartado Carpetas.

Configurando la carpeta en SUDOCU

alt text

1. Nombre de la carpeta. Será público.

2. La carpeta deberá ser pública.

3. La carpeta deberá tener estado habilitado.

4. Se deberán elegir los tipos de documentos que se desean mostrar públicamente. Para el caso de ejemplo, seleccionaremos "Resoluciones del Consejo Superior".

5. SUDOCU determina tres tipos de visibilidad: "Público" para aquellos documentos que pueden ser visualizados por cualquier persona, "Privado" para aquellos documentos que pueden ser visualizados por cualquier usuario con permiso de visibilidad y "Reservado" para aquellos usuarios que poseen permisos de visibilidad de "reservados". Para el caso de ejemplo, las resoluciones del Consejo Superior serán de visibilidad "Pública".

6. La descripción de la carpeta se verá reflejada en el módulo MPD.

alt text

7. Se pueden aplicar diferentes filtros. Para el caso de ejemplo, se publicarán las resoluciones del mes de septiembre de 2022.

Vista de la carpeta desde el módulo MPD

alt text

Recomendación de configuración de la funcionalidad de Verificación de Firmas Digitales#

La verificación de firmas digitales en documentos adjuntos se realiza una sola vez y es al momento de adjuntar cada archivo PDF a SUDOCU. Si un documento no pasó por la verificación de su firma digital en el momento de ser adjuntado, no tendrá otra instancia de verificación.

No obstante, se puede visualizar la verificación realizada en:

el mismo momento en que se adjunta el archivo PDF desde el apartado "Archivos Adjuntos" en la operación "Modificar Documento".
la vista "abrir" de cada documento que posee archivos PDF con firma digital.
la vista previa de un expediente que contiene documentos con archivos firmados digitalmente.

A partir de la versión 1.4.15 de SUDOCU se deprecó la librería VerifyPDF y únicamente existe un solo método de verificación de firma digital:

Stamper.

Se deberá definir un valor diferente a "" en el campo "stamper_host", como por ejemplo "http://stamper:8080/signatures". Así el Stamper se encargará de verificar las firmas digitales.

El host del stamper se puede obtener del archivo docs.yml del despliegue de arai-documentos. El parámetro se debe escribir de tal manera que quede el protocolo al principio (http://) y la ruta /signatures al final.

{
"archivos_adjuntos": {
      "max_mb":20

    "lectura_firmas": {
      "max_file_mb": 20 "(no se toma en cuenta el valor de este campo)"
      "stamper_host": "http://stamper:8080/signatures"
            }
}

En la siguiente imagen se puede comprobar el comportamiento de SUDOCU al momento de verificar las firmas de los archivos PDF adjuntos con la configuración antes mencionada.

alt text

Se verifica la firma digital del documento mediante el Stamper.
El documento no posee firma digital.
Se verifica la firma digital del documento mediante el Stamper.

A continuación se podrá visualizar la información mostrada desde el botón "Verificar Firmas" de la vista previa de un expediente

Verificación de firmas del Stamper:

alt text

¿Qué significa el mensaje "El archivo adjunto no se verificó. Estándar de firma no soportado"?#

Actualmente SUDOCU soporta únicamente el Estándar pkcs11. Si un archivo adjunto posee firma digital pero su estándar es anterior al soportado, aparecerá un mensaje informando que ese archivo no pudo ser verificado.

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

En la versión 1.3.12 de SUDOCU se incorpora el parámetro "copiar_archivos_adjuntos" 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 siempre que se copie un documento, cualquiera sea su estado, se copiarán todos sus archivos adjuntos. Y si el valor es false, cuando se copie un documento nunca se copiarán sus archivos adjuntos.

Funcionamiento del parámetro "copiar_archivos_adjuntos"#

El parámetro determina según su valor, si al momento de copiar un documento se copiaran también sus archivos adjuntos. Por defecto el valor es false y no se copiaran los archivos adjuntos al copiar un documento.

Los archivos adjuntos se guardan, según el archivo de configuración del Api-Server de SUDOCU en

"filesystem": {
    // Carpeta donde se guardan los adjuntos
    "rootFolder": "/app/sudocu-files/",
    "cacheFolder": "/app/sudocu-files/cache"

Es sumamente importante que no se eliminen los archivos que se encuentran en la carpeta "rootFolder": "/app/sudocu-files/". Asimismo se recomienda realizar backups regularmente de dicha carpeta dado que allí se almacenan los archivos adjuntos de los documentos creados en SUDOCU.

Mantenimiento preventivo para liberar espacio en la Caché de visualización de Expedientes/Trámites#

Cuando se visualizan expedientes y trámites en SUDOCU se generan archivos en el directorio cache y además se crean registros la tabla sudocu.archivos_cache de la base de datos sudocu.

A medida que las visualizaciones aumentan, los registros son cada vez más voluminosos y resulta recomendable realizar los siguientes pasos para liberar espacio:

1- Eliminar el contenido del directorio cache. La carpeta cache se ubica dentro del directorio sudocu-files, según como se configure en el apartado volumes:files al final del archivo sudocu.yml.

2- Ejecutar la siguiente query en la base de datos de SUDOCU, en el esquema sudocu:

DELETE FROM sudocu.archivos_cache

Funcionamiento del parámetro "vistas"#

El parámetro Vistas es incorporado en la versión 1.4.1 de SUDOCU para configurar específicamente a la Bandeja de Novedades de SUDOCU. Permite la parametrización de la frecuencia de actualización de las novedades logrando una mayor eficiencia con la misma cantidad de recursos y para aquellas instituciones que lo deseen, deshabilitar la Bandeja de Novedades.

Cada institución deberá determinar cuál es la mejor configuración teniendo en cuenta los recursos físicos asignados para SUDOCU y la concurrencia de usuarios conectados a la base de datos.

Configuración#

En primera instancia es posible deshabilitar/habilitar la bandeja a nivel institucional. Para ello se debe setear el parámetro "habilitado" en false si se desea inhabilitar o en true si se desea habilitar la funcionalidad de Bandeja de Novedades.
El parámetro "frecuencia_actualización_cron" determina la frecuencia con que se actualizará la información de la vista "Novedades" y utiliza el concepto de expresiones CRON.

NOTA

"Las expresiones CRON se utilizan para automatizar tareas repetitivas y en este caso se usan para automatizar la actualización de la vista. Es una cadena compuesta de 5 campos que representan valores de la programación. Los campos están separados por un espacio y contienen cualquiera de los valores permitidos con varias combinaciones."

El parámetro "periodo_horas" determina en horas el periodo de tiempo que se tomará en cuenta para brindar las novedades. Si el valor es 1, se informarán las novedades de la última hora. Si el valor es 24 informará las novedades de las últimas 24 hs.

La configuración por defecto es:

La bandeja de Novedades se encuentra habilitada, mostrará las novedades de las últimas 24 horas y se actualizará cada 1 minuto

 "gestion": {
    "vistas": {
      "frecuencia_actualizacion_cron": "* * * * *",
      "inbox": {
        "habilitado": true,
        "periodo_horas": 24
      }
      "busqueda_e_incorporaciones": {
        "periodo_dias": 90
      }
    },

Otros ejemplos de configuración de "frecuencia_actualización_cron"#

Se actualizará cada 1 minuto.

"frecuencia_actualización_cron": "* * * * *"

Se actualizará cada 1 minuto desde las 6 AM hasta las 18 AM, de Lunes a Viernes.

"frecuencia_actualización_cron": "* 6-18 * * MON-FRI"

Se actualizará cada 5 minutos desde las 6 AM hasta las 18 AM, de Lunes a Viernes.

"frecuencia_actualización_cron": "*/5 6-18 * * MON-FRI"

Se actualizará cada 5 minutos.

"frecuencia_actualización_cron": "*/5 * * * *"

NOTA

El siguiente sitio posee un generador de expresiones CRON para poder realizar más combinaciones https://crontab.cronhub.io/

Otros ejemplos de configuración de "habilitado" y "periodo_horas"#

Se informarán las novedades de las últimas 24 hs.

"habilitado": true,
"periodo_horas": 24

Se informarán las novedades de la última hora.

"habilitado": true,
"periodo_horas": 1

La vista de novedades se encuentra deshabilitada para toda la institución.

"habilitado": false,
"periodo_horas": 24

¿Qué es una "providencia automática"?#

El concepto de "providencia automática" es incorporado en la versión 1.4.6 de SUDOCU para definir a un tipo de documento generado automáticamente por SUDOCU, de creación optativa e incorporación automática durante el proceso de remisión de un expediente.

Su utilización está definida bajo demanda del usuario que remite un contenedor o trámite y únicamente para aquellos tipos de contenedores o trámites que admiten la "providencia automática".

Por defecto, todos los tipos de contenedores o trámites tienen definido que nunca se utilizará providencias automáticas en su remisión.

IMPORTANTE

La providencia automática se puede:

Nunca usar
Usar a demanda (a elección) de cada usuario en el proceso de remisión. Pudiendo existir en algunas remisiones y en otras no.

¿Cómo se implementa?#

Para la implementación se debe:

MPC

En cada tipo de contenedor o trámite que se desea incorporar a demanda una providencia al momento de remitir un elemento, seleccionar el valor "A demanda" dentro del campo "Providencia Automática" del formulario del tipo de documento.
Definir un template PDF para el tipo de documento "providencia_automatica".

Gestión

En la herramienta "Remitir" se encuentra el campo "Contenido del documento Providencia Automática" para completar, en caso de que el usuario remitente lo desee, el texto a contener la Providencia Automática que se incorporará al contenedor o trámite en su remisión.

Si el campo "Contenido del documento Providencia Automática" se deja vacio, no se creará la Providencia Automática.

Integrar SUDOCU con los módulos del SIU#

A continuación se adjunta enlace con documentación funcional y técnica para realizar la integración de SUDOCU con los módulos del SIU para consolidar el Ecosistema SIU: https://documentacion.siu.edu.ar/wiki/Ecosistema

¿Qué implica el parámetro validar_intervenciones?#

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

Si el parámetro está en false la búsqueda general mostrará todas las herramientas habilitadas en el bloque "busqueda" del archivo de configuración del api-server, para todos los elementos que resulten de una búsqueda, indistintamente si alguna de las áreas del usuario logueado tuvo o no alguna intervención en el elemento seleccionado (Comportamiento por defecto en SUDOCU).

Si el parámetro en cambio, está en true, las herramientas habilitadas en el bloque "busqueda" se visualizarán solo para aquellos elementos en donde alguna de las áreas del usuario logueado haya tenido alguna intervención en el elemento seleccionado.

A partir de la versión 1.4.8 dicho parámetro interviene en los elementos de esencia contenedor, trámite y documento.

Las herramientas del bloque "búsqueda" son: compartir, vista avanzada, descargar, abrir, mapa y vista previa

"compartir", "descargar" y "vista previa" únicamente son visibles para aquellos elementos que se encuentran en el área activa.

En cambio, "vista avanzada", "mapa" y "abrir" son visibles indistintamente si el elemento se encuentra o no en el área activa.

Ejemplos de configuraciones#

Configuración A#

validar_intervenciones: false

"busqueda": {
"compartir": true,
"vista_avanzada": true,
"descargar": true,
"abrir": true,
"mapa": true,
"vista_previa": true
}

Comportamiento:

Desde el buscador general se podrá realizar la vista avanzada, vista mapa y vista abrir de todos los elementos que resulten de una búsqueda en particular, siempre que el usuario logueado tenga habilitado el permiso para cada herramienta desde el MPC (https://sudocu.dev/docs/documentacion-funcional/mpc/mpc#usuarios)

Las herramientas compartir, descargar y vista previa, serán únicamente posibles para aquellos elementos que se encuentren en el área activa del usuario logueado y además dicho usuario tenga permisos para cada herramienta habilitado desde el MPC.

Configuración B#

validar_intervenciones: true

"busqueda": {
"compartir": true,
"vista_avanzada": true,
"descargar": true,
"abrir": true,
"mapa": true,
"vista_previa": true
}

Comportamiento:

Desde el buscador general se podrá realizar la vista avanzada, vista mapa y vista abrir de aquellos elementos que cumplan con las siguientes 3 condiciones:

resulten de una búsqueda en particular,
el usuario logueado tenga habilitado el permiso para cada herramienta desde el MPC (https://sudocu.dev/docs/documentacion-funcional/mpc/mpc#usuarios),
el área activa o alguna de las áreas asignadas al usuario logueado haya intervenido en el elemento.

Las herramientas compartir, descargar y vista previa, serán únicamente posibles para aquellos elementos que además de cumplir con las 3 anteriores condiciones, se encuentren en el área activa del usuario logueado.

Aumento de memoria heap en sudocu_api-server#

En algunas ocasiones,

a. al trabajar con documentos grandes, aunque el servicio sudocu_api-server esté escalado verticalmente,

b. en instalaciones donde exista mucha concurrencia de usuarios,

Puede presentarse el siguiente error en el log del sudocu_api-server:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

Para resolverlo se recomienda:

1- Verificar memoria heap del sudocu_api-server:

Desde el /bin/bash del servicio (se puede ingresar desde la consola del nodo en cual está corriendo o bien desde Portainer)

Ejecutar la siguiente consulta:

node -e 'console.log(`node heap limit = ${require("v8").getHeapStatistics().heap_size_limit / (1024 * 1024)} Mb`)' 

Habitualmente, la memoria heap del Node es de 2 Gb: node heap limit = 2048 Mb

2- Editar el archivo sudocu.yml. Para ello buscar el servicio api-server: y agregar en enviroment:

… 
  environment: 
    NODE_OPTIONS: "--max-old-space-size=8192"

3- Redeployar el contenedor.

Nota

Tener en cuenta al momento de realizar esta modificación el memory_limit asignado al servicio en el escalado vertical del mismo.

Persistencia de Redis#

Cómo Redis escribe datos en el disco#

La persistencia se refiere a la escritura de datos en un almacenamiento duradero, como un disco de estado sólido (SSD). Redis ofrece una variedad de opciones de persistencia, entre las que se incluyen:

RDB (base de datos Redis): la persistencia de RDB realiza instantáneas de su conjunto de datos en intervalos específicos.

AOF (Append Only File): la persistencia AOF registra cada operación de escritura que recibe el servidor. Estas operaciones pueden reproducirse nuevamente al iniciar el servidor, lo que reconstruye el conjunto de datos original. Los comandos se registran utilizando el mismo formato que el protocolo Redis.

Sin persistencia. Puedes desactivar la persistencia por completo. Esto se utiliza a veces durante el almacenamiento en caché.
RDB + AOF. También puedes combinar AOF y RDB en la misma instancia.

Para casos de uso en los que la pérdida de datos es tolerable solo de forma limitada:

Archivo de solo anexión (AOF): fsync cada 1 segundo: Redis sincronizará con fsync cualquier dato escrito recientemente cada segundo. Esta política equilibra el rendimiento y la durabilidad y se debe utilizar cuando la pérdida mínima de datos sea aceptable en caso de una falla. Esta es la política predeterminada de Redis. Esta política podría resultar en una pérdida de datos de entre 1 y 2 segundos, pero en promedio, esto será más cercano a un segundo.

Nota

Si utiliza AOF para la persistencia, habilite la replicación para mejorar el rendimiento. Cuando ambas funciones están habilitadas para una base de datos, la réplica maneja la persistencia, lo que evita cualquier impacto en el rendimiento de la base de datos maestra.

Archivo de recuperacion#

El archivo appendonly.aof es un archivo de registro en el que Redis almacena todas las operaciones de escritura que se ejecutan en la base de datos. Su propósito es permitir la recuperación de los datos en caso de un fallo del servidor Redis. Aquí tienes una descripción más detallada de su contenido y funcionamiento:

Registro de Escrituras:

Cada vez que se ejecuta una operación que modifica los datos en Redis (por ejemplo, SET, DEL, HSET, etc.), la operación se registra en el archivo AOF.
Esto significa que el archivo AOF contiene una lista ordenada de todos los comandos de escritura que se han ejecutado desde la última vez que se inició Redis con el archivo AOF vacío o desde la última vez que se reescribió el archivo AOF.

Recuperación de Datos:

En caso de un reinicio o un fallo, Redis puede usar el archivo AOF para reconstruir el estado de la base de datos ejecutando nuevamente todas las operaciones registradas en el archivo.
Este proceso asegura que todos los datos escritos en Redis desde el último reinicio o reescritura del AOF estén presentes.

Reescritura del AOF:

Para evitar que el archivo AOF crezca indefinidamente, Redis puede reescribir el archivo de manera compacta. Esto se hace ejecutando un subconjunto de los comandos en el archivo AOF que representan el mismo estado de la base de datos, pero de una manera más compacta.
Esta reescritura puede ser configurada para que ocurra automáticamente, basándose en ciertos criterios de tiempo y tamaño del archivo.

En resumen, el archivo appendonly.aof actúa como un registro persistente de todas las operaciones de escritura en Redis, permitiendo la recuperación del estado completo de la base de datos en caso de un reinicio o un fallo.

Reescritura del AOF (Append-Only File)#

Motivo de la Reescritura:

Crecimiento del Archivo: Con el tiempo, el archivo AOF puede crecer significativamente, ya que cada operación de escritura se agrega al final del archivo. Un archivo grande puede ralentizar el proceso de recuperación y consumir mucho espacio en disco.
Compactación: La reescritura del AOF compacta los comandos, eliminando redundancias y optimizando el espacio utilizado.

Proceso de Reescritura:

Creación de un Nuevo Archivo AOF:

Redis crea un nuevo archivo AOF mientras continúa escribiendo en el archivo original.
Se toma una instantánea del estado actual de la base de datos y se reconstruye el archivo AOF desde cero, incluyendo solo los comandos necesarios para reproducir el estado actual.

Switch de Archivos:

Una vez que el nuevo archivo AOF está listo, Redis comienza a escribir en el nuevo archivo en lugar del antiguo.
Los cambios que ocurrieron durante la reescritura se sincronizan con el nuevo archivo.

Eliminación del Archivo Viejo:

El antiguo archivo AOF se elimina, y el nuevo archivo se convierte en el archivo principal.

Configuración de la Reescritura:

Redis permite configurar cuándo y cómo se debe realizar la reescritura del AOF mediante parámetros en el archivo de configuración redis.conf o mediante comandos.

Parámetros de Configuración:

auto-aof-rewrite-min-size:

Especifica el tamaño mínimo que debe alcanzar el archivo AOF antes de que se considere para reescritura.
Ejemplo: auto-aof-rewrite-min-size 64mb

auto-aof-rewrite-percentage:

Especifica el porcentaje de crecimiento del tamaño del AOF desde la última reescritura para que se inicie una nueva reescritura.
Ejemplo: auto-aof-rewrite-percentage 100

Si el AOF ha crecido un 100% desde la última reescritura y ha alcanzado el tamaño mínimo especificado, Redis iniciará una reescritura del AOF.

Comando Manual de Reescritura:

Puedes iniciar una reescritura manualmente utilizando el comando BGREWRITEAOF.

Ejemplo de Configuración en redis.conf:

appendonly yes
appendfilename "appendonly.aof"
auto-aof-rewrite-min-size 64mb
auto-aof-rewrite-percentage 100

Beneficios de la Reescritura#

Mejora del Rendimiento: Un archivo AOF más pequeño y compacto permite una recuperación más rápida y eficiente.

Optimización del Espacio en Disco: La reescritura elimina comandos redundantes, reduciendo el uso de espacio en disco.

Mantenimiento de la Persistencia: La reescritura asegura que Redis mantenga una copia consistente y optimizada de todas las operaciones de escritura.

La reescritura del AOF es un proceso esencial para mantener la eficiencia y el rendimiento de Redis a lo largo del tiempo, asegurando al mismo tiempo la persistencia y recuperación de datos en caso de fallos.

https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/

https://redis.io/docs/latest/operate/rs/databases/configure/database-persistence/