Version: 1.4.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.

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 = '{"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."}' 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."}' 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 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.

Actualmente hay dos métodos de verificación de firma digital:

Librería VerifyPDF o Stamper.

Se puede utilizar o un método o el otro pero nunca se usará ambos a la vez. Por tal motivo recomendamos:

A- Si se requiere que SUDOCU siempre verifique las firmas de los adjuntos, el funcionamiento estará determinado en primera instancia por el valor del parámetro "archivos_adjuntos":"max_mb"

1.1. Si el valor de "max_mb" es hasta 20mb, se recomienda utilizar la librería VerifyPDF.

A continuación un ejemplo de configuración:

{
  "archivos_adjuntos": {
    "max_mb": 20
  }
}

Para la verificación de firmas, si se debe definir el valor "" en el campo "stamper_host". Así la libreria VerifyPDF verificará las firmas digitales de los archivos que tengan como máximo el tamaño definido en el campo "max_file_mb". Se aconseja que si el campo "max_mb" posee valor 20 o menos, se complete el campo "max_file_mb" con el mismo valor.

{
  "lectura_firmas": {
    "max_file_mb": 20,
    "stamper_host": ""
  }
}

1.2 Si el tamaño de los archivos adjuntos PDF que se adjuntan a SUDOCU es mayor a 20 mb, se recomienda utilizar el Stamper como herramienta para la verificación de las firmas digitales de los documentos adjuntos. Para ello 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.

B- Si no se requiere que SUDOCU siempre verifique las firmas de los adjuntos, la verificación estará determinada en primera instancia por el valor del parámetro "archivos_adjuntos":"max_mb, debido a que este parámetro determina el tamaño máximo de archivos a adjuntar. En segunda instancia estará determinada por el valor del parámetro "lectura_firmas":"max_file_mb"

En el siguiente caso se verificará mediante VerifyPDF archivos hasta 20mb. Si se adjunta un archivo de más de 20mb no se verificará su firma.

{
"archivos_adjuntos": {
      "max_mb":100

    "lectura_firmas": {
      "max_file_mb": 20,
      "stamper_host": ""
                  }
}

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 la librería VerifyPDF, porque el archivo posee un tamaño menor a 20 mb (valor configurado en el parámetro "max_file_mb")
El documento no posee firma digital.
No se verifica la firma digital del documento porque el tamaño del archivo posee un tamaño mayor a 20 mb (valor configurado en el parámetro "max_file_mb")

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

Verificación de firmas de la librería VerifyPDF:

alt text

La librería no muestra quién autorizó el documento ni tampoco la fecha de autorización. El Stamper no muestra la fecha de validez del certificado que se stampa en el documento autorizado.

¿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