udistrital / core_documentacion

0 stars 0 forks source link

Modificar proceso de firma. #206

Closed diagutierrezro closed 3 weeks ago

diagutierrezro commented 4 weeks ago

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

Skyrus1203 commented 4 weeks ago

ACTUALIZACIÓN 15/10/24

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:

image

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:

image

Se envía al supervisor:

image

Y desde la vista del supervisor:

image

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

Skyrus1203 commented 3 weeks ago

ACTUALIZACIÓN 16/10/24

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:

image

La cual al abrirla nos encontramos con eso:

Captura de pantalla 2024-10-16 164529

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:

Captura de pantalla 2024-10-16 165312

Se recibe por parte del ordenador ya firmado:

Captura de pantalla 2024-10-16 165347

El proceso de firma funciona:

Captura de pantalla 2024-10-16 165408

Sin embargo al momento de verificar en Nuxeo nos damos cuenta que está tomando el documento sin firma para aplicar la estampa del supervisor:

Captura de pantalla 2024-10-16 174305

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:

Captura de pantalla 2024-10-16 180150

Así se inicia una nueva prueba y se obtiene el resultado esperado:

Captura de pantalla 2024-10-16 180224

Sin embargo para descartar se realiza una prueba más:

Se crea el informe

Captura de pantalla 2024-10-16 181129

Se envía:

Captura de pantalla 2024-10-16 181150

Desde el lado del supervisor vemos que el documento fué firmado correctamente por el contratista:

Captura de pantalla 2024-10-16 181444

Se aprueba desde el supervisor:

Captura de pantalla 2024-10-16 181504

Y se verifica en Nuxeo:

Captura de pantalla 2024-10-16 181536

Así bien, queda por finalizada la corrección del error, quedando pendiente únicamente el flujo de rechazo

Skyrus1203 commented 3 weeks ago

ACTUALIZACIÓN 17/10/24

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:

image

Así se inicia con la prueba:

Se tiene el siguiente conjunto de soportes:

Captura de pantalla 2024-10-17 204254

Se envía al supervisor:

Captura de pantalla 2024-10-17 204442

Como se puede verificar ahora mismo hay dos certificados de cumplimiento activos, el original sin firma y el que se acaba de firmar:

Captura de pantalla 2024-10-17 204447

Se recibe desde el supervisor:

Captura de pantalla 2024-10-17 204509

Captura de pantalla 2024-10-17 204516

Se realiza el rechazo:

Captura de pantalla 2024-10-17 204537

Y ahora sólo está activo el original sin firmar:

Captura de pantalla 2024-10-17 204554 Captura de pantalla 2024-10-17 204610

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:

image

La cual es llamada aquí:

image

Ahora para el ordenador, el script es casi idéntico al supervisor:

image

Se realizó la prueba a continuación:

Se envía la solicitud al supervisor:

Captura de pantalla 2024-10-17 204625

Se aprueba desde el ordenador:

Captura de pantalla 2024-10-17 204644

Como se aprecia a continuación, tenemos activos dos documentos: El original sin firmar y el firmado por el contratista y por el supervisor:

Captura de pantalla 2024-10-17 221311

Desde la vista del ordenador:

Captura de pantalla 2024-10-17 221249

Se rechaza y se evidencia que sólo esta activo ahora el original sin firmar:

Captura de pantalla 2024-10-17 221338

Captura de pantalla 2024-10-17 221345

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.

Skyrus1203 commented 3 weeks ago

ACTUALIZACIÓN 18/10/24

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.

image

Así se realiza la prueba de funcionamiento:

Desde el usuario de contratista se cargan estos documentos y se envían:

Captura de pantalla 2024-10-18 174729

Captura de pantalla 2024-10-18 174758

Desde el supervisor se reciben y se aprueban para la revisión del supervisor:

Captura de pantalla 2024-10-18 174824

Captura de pantalla 2024-10-18 174850

Como se puede ver en postman, actualmente existen el documento original y el firmado por supervisor y contratista:

Captura de pantalla 2024-10-18 174911

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:

Captura de pantalla 2024-10-18 175015

Captura de pantalla 2024-10-18 175023

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:

Captura de pantalla 2024-10-18 193726

Captura de pantalla 2024-10-18 193748

Así bien se comienzan con las pruebas:

Desde el contratista se crean 3 soportes descritos a continuación:

Captura de pantalla 2024-10-18 182700

Captura de pantalla 2024-10-18 182758

Captura de pantalla 2024-10-18 182920

Los cuales son enviados al supervisor, desde el cual se pueden visualizar:

Captura de pantalla 2024-10-18 183013

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):

Captura de pantalla 2024-10-18 183237 Captura de pantalla 2024-10-18 183244 Captura de pantalla 2024-10-18 183248

Sin embargo consultando la base de datos se encuentra el consecutivo de estos documentos al ser firmados por el supervisor:

Captura de pantalla 2024-10-18 185406

Ahora desde la vista de ordenador se visualizan los documentos debidamente firmados:

Captura de pantalla 2024-10-18 183413 Captura de pantalla 2024-10-18 184550 Captura de pantalla 2024-10-18 184628

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:

Captura de pantalla 2024-10-18 184657 Captura de pantalla 2024-10-18 184741 Captura de pantalla 2024-10-18 184805 Captura de pantalla 2024-10-18 184930

Siendo así se concluye con la implementación de firma múltiple en cumplidos, se pasa el issue a in review