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 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:
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. Si existe la sección configs, se deben agregar las siguientes lineas:
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.
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.
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. 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:
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.maxAge 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.
¿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.
- 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.
- 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.
- 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.
¿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
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.
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
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:
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.
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.
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.
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.
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.
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:
Verificación de firmas de la librería VerifyPDF:
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 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.