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:
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
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
Por último eliminar el stack de arai-documentos
y volver a desplegarlo
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:
- En el .yml de deploy agregar en el servicio de pdf el siguiente volumen:
- 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:
- 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:
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:
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.
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.
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-serverlevante siempre en el mismo nodo.
Los cambios a aplicar serían estas líneas en sudocu.yml:
Después:
- Recuperar los archivos ya creados de los otros nodos. Se puede ver en qué nodos se levantó el contenedor con:
En cada nodo donde se haya levantado api-server hay que revisar la ruta donde se creó el volumen:
- Copiar esos datos al nodo en donde va a estar levantado el
api-server:
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:
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.
Para configurar correctamente las notificaciones de eventos por email, es necesario ingresar al archivo de configuración del api-server y parametrizar lo siguiente:
Barra superior con información de commits#
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í:
Ejecutar la siguiente línea para crear un secret con el contenido del certificado:
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:
- Agregar el secret en el bloque de secrets al final del archivo sudocu.yml:
Configurar en config-api-server.json el siguiente parámetro:
Borrar servicio y config de api-server y reiniciar stack 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.expires dentro del archivo config-api-server.json:
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:
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:
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.
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.