Closed diagutierrezro closed 3 weeks ago
Se tiene una reunión con Juan Camilo para resolver ciertas dudas generadas en la implementación del cambio solicitado por el profesor Daza para la primera firma. Gracias a el se pudo completar la implementación ya que siguiendo lo planeado en la propuesta expuesta en el issua de corrección de errores se debían realizar unos cambios en el mid, los cuales se describen a continuación:
Ya que la idea es dejar todos los documentos de un proceso (sin firma, firma contratista, firma de supervisor) en activo hasta que el ordenador los apruebe (si no son rechazados) era necesario cambiar el mid de cumplidos para uqe sólo trajera el certificado de cumplimiento activo más reciente, para ello con ayuda y guía de Juan Camilo se implementó el siguiente cambio enla función TraerEnlacesDocumentosAsociadosPagoMensual en el helper de contratista.go:
Así pues, con algunos apuntes de como terminar de enviar el archivo firmado se realizó la prueba:
Se genera el informe, como se ve ya no tiene la firma al ser generado:
Se envía al supervisor:
Y desde la vista del supervisor:
De esta forma queda completado el cambio en la primera firma. Por lo tanto queda pendiente la corrección del error en la segunda etapa y la implementación del flujo de rechazo
Se corrige el problema presente en la segunda etapa de la firma, es decir cuando el supervisor aprueba y firma los soportes del contratista.
Luego de analizar el flujo, se encontró el punto en el que se podría estar generando la discrepancia de archivos ocasionalmente al momento de firmar, resultando en esta función:
La cual al abrirla nos encontramos con eso:
Como se ve se realiza una petición a soporte_pago_mensual la cual devuelve un json que tiene dentro el UID del archivo que se va a firmar. Sin embargo la respuesta de dicha petición estaba trayendo la información mal ordenada ocasionando los problemas descritos en anteriores issues, además de una nueva problemática que se descubrió con la prueba hecha a continuación:
Se generó un certificado desde la ventana de contratista:
Se recibe por parte del ordenador ya firmado:
El proceso de firma funciona:
Sin embargo al momento de verificar en Nuxeo nos damos cuenta que está tomando el documento sin firma para aplicar la estampa del supervisor:
Esto es causado por lo descrito anteriormente. Se intentó arreglar esta consulta por medio de postman pero no se logró el resultado esperado por lo que se convocó a Juan Camilo, y con su ayuda se estableció que la consulta estaba mal construida, y es que en el crud, se tiene que el orderby hace referencia al orden en el que se rescatan los datos y el sortby se tiene como la columna por la cual se ordena, caso contrario a como se tenía en la consulta de la función de traer informe ya que ahí se usaba orderby para señalar la columna para ordenar sin el sort.
Por tanto se corrigió esto agregando a la consulta el sortby, cambiando el orderby por el order y agregando el desc, además de agregar un nuevo filtro para que sólo traiga los archivos con campo activo = true, de modo que la consulta quedó de la siguiente manera:
Así se inicia una nueva prueba y se obtiene el resultado esperado:
Sin embargo para descartar se realiza una prueba más:
Se crea el informe
Se envía:
Desde el lado del supervisor vemos que el documento fué firmado correctamente por el contratista:
Se aprueba desde el supervisor:
Y se verifica en Nuxeo:
Así bien, queda por finalizada la corrección del error, quedando pendiente únicamente el flujo de rechazo
Se inicia con el flujo de rechazo comenzando con el rechazo por parte del supervisor:
Para este punto del flujo se realiza un barrido por todos los soportes de pago activos anexos al pago mensual en cuestion, rescatando sólo los que sean certificados de cumplimiento, para luego desactivarlos todos menos el original sin firma como se hace en este código:
Así se inicia con la prueba:
Se tiene el siguiente conjunto de soportes:
Se envía al supervisor:
Como se puede verificar ahora mismo hay dos certificados de cumplimiento activos, el original sin firma y el que se acaba de firmar:
Se recibe desde el supervisor:
Se realiza el rechazo:
Y ahora sólo está activo el original sin firmar:
Ahora bien adicional a esto, tanto en caso de que este proceso de rechazo falle tanto para supervisor como para ordenador, se crea un script al momento de enviar a revisión por parte del contratista se desactiven los posibles documentos que hayan quedado activos:
La cual es llamada aquí:
Ahora para el ordenador, el script es casi idéntico al supervisor:
Se realizó la prueba a continuación:
Se envía la solicitud al supervisor:
Se aprueba desde el ordenador:
Como se aprecia a continuación, tenemos activos dos documentos: El original sin firmar y el firmado por el contratista y por el supervisor:
Desde la vista del ordenador:
Se rechaza y se evidencia que sólo esta activo ahora el original sin firmar:
Por tanto los flujos de rechazo quedan correctamente desarrollados y probados. Lo único pendiente es que al aprobar, todos los documentos se desactiven menos el último, es decir, el que ya ha sido firmado por contratista y supervisor.
Se finaliza con la implementación de la desactivación de los documentos antiguos al aprobar el ordenador:
La aprobación del supervisor tiene dos funciones, una para aprobar individualmente solicitudes, y otra para aprobar solicitudes en masa, por lo que se tuvo que implementar en ambas:
Aprobación única:
Aquí no se tuvo que modificar la función que se venía utilizando para el proceso salvo por el cambio de que ahora sólo dejase activo el documento más reciente del proceso, es decir el firmado por contratista y supervisor.
Así se realiza la prueba de funcionamiento:
Desde el usuario de contratista se cargan estos documentos y se envían:
Desde el supervisor se reciben y se aprueban para la revisión del supervisor:
Como se puede ver en postman, actualmente existen el documento original y el firmado por supervisor y contratista:
Ahora desde la vista del ordenador dicho pago se aprueba y si se verifica en postman, se identifica que el documento más reciente fué el que quedó activo:
Aprobación Múltiple:
Para la aprobación múltiple se aprovechó el objeto previamente creado llamado arreglo_aux para extraer de ahí los pagos mensuales mediante un proceso de iteración y así aplicar el algoritmo de desactivación a cada uno de los soportes seleccionados. Se tuvo que implementar en dos partes del flujo ya que hay dos casos en los que se aprueban los soportes:
Así bien se comienzan con las pruebas:
Desde el contratista se crean 3 soportes descritos a continuación:
Los cuales son enviados al supervisor, desde el cual se pueden visualizar:
A continuación se presenta en postman el estado de los documentos estando firmados por el contratista y el documento original respectivamente (por descuido no se tomó captura cuando se envió al supervisor):
Sin embargo consultando la base de datos se encuentra el consecutivo de estos documentos al ser firmados por el supervisor:
Ahora desde la vista de ordenador se visualizan los documentos debidamente firmados:
Los tres son aprobados y si se contrasta con los registros de la base de datos, se notará que los registros restantes son los más recientes firmados por supervisor y contratista:
Siendo así se concluye con la implementación de firma múltiple en cumplidos, se pasa el issue a in review
Se requiere realizar la modificación del proceso de firma electrónica en el flujo de cumplidos CPS, para esto es necesario almacenar el documento original (sin ninguna firma) el cual es el que se mostrará al contratista cuando no se ha enviado a revisión, una vez el contratista envía los documentos para revisión es que se realiza la primera estampa de la firma. Importante tener en cuenta que una vez se realice el rechazo se retorna al documento original sin firmas ya que una vez se vuelva a enviar los documentos se debe realizar una nueva estampa.
Importante hablar con Juan Camilo para obtener la ruta a seguir en estos ajustes.
Sub Tareas
Criterios de aceptación
Requerimientos
No aplica
Definition of Ready - DoR
Definition of Done - DoD - Desarrollo