Closed diagutierrezro closed 1 month ago
Con Juan Camilo mientras se revisaba en la reunión prevista para esta mañana a las 10, se identificó que cuando la segunda etapa fallaba era por que se estaba enviando un UID de un documento que no correspondía al que se quería firmar y dicho UID corresponde a un documento con el campo activo en "false".
Se intentó iniciar la corrección del error, sin embargo al momento de aprobar los soportes que estaban pendientes para reproducir el error, esta vez funcionaron perfecto, por lo que intentó generar nuevos soportes sin embargo a diferencia del día de ayer o esta mañana sale este aviso:
Revisando las peticiones todas dan un código 200:
Sin embargo con el líder de equipo se identificó que el valor del número de documento del supervisor tenía un valor que al parecer no existía:
Haciendo que el arreglo de dependencias retorne vacío:
Sin embargo luego de hacer varias pruebas en las que se trató de modificar el documento, no se obtuvo una aclaración del motivo de este incoveniente, el cual obstaculiza totalmente la corrección del error ocasional de la segunda firma ya que sin poder probar ni depurar la consulta a la firma múltiple y así poder ver en qué parte del flujo de cumplidos se está colando la información incorrecta, no es posible aplicar la corrección en el código.
Por ende se informó a Juan Camilo de los hallazgos realizados por el lider de grupo, el cual encontró que se había cambiado el supervisor hace un par de días y que por ello podría estar fallando la carga de cumplidos y está evaluando una solución al respecto. Además se notificó al ingeniero Jhon para facilitar el Query que se ejecuta al realizar la consulta en la que se rescatan las dependencias para identificar lo que pueda estar pasando a nivel de persistencia
El día de hoy antes del medio día Juan Camilo logró resolver el problema de las dependencias reestableciendo el supervisor que se tenía antes de los cambios producidos hace un par de días, permitiendo el funcionamiento correcto de la parte de visualización de los soportes en cada contrato.
Sin embargo se encontró que al momento de intentar generar un certificado de cumplimiento para realizar pruebas, se arrojaba un error:
Como se evidencia las peticiones eran correctas y aunque se probase en ambiente de pruebas, el problema persistía. Por ende se realizó una reunión con Juan Camilo para identificar el problema que impedía el correcto funcionamiento de la generación del certificado. Se encontró que la siguiente petición retornaba un XML de error.
Se pasó a realizar una trazabilidad identificando que una de las peticiones que se realizaban a raíz de la anterior expuesta estaba retornando un error en el que identificaba un json vacío. Luego de ello se citó al desarrollador Youssef Ortiz, el cual había realizado cambios en el mid el día de ayer y hoy. Luego de un análisis profundo, se llegó a la conclusión de que el problema residía en las variables de entorno que no se habían cargado correctamente. Se realizó la corrección correspondiente, se realizó PR y se está a la espera de que se dichas variables se cambien en el ambiente que consulta el cliente de cumplidos
Se informó de una novedad por parte de Youseff en la noche y se realizó la prueba, mandando el mismo error pero ahora las peticiones llegan bien sin embargo muestra el siguiente error en consola:
Queda pendiente entonces la confirmación del cambio y las respectivas pruebas para verificar la correcta funcionalidad
A pesar del constante trabajo de Juan Camilo y Youssef aún no se ha podido resolver el error, se sigue a la espera de una solución. Por otra parte el profesor Daza solicitó un cambio a la primera etapa de la firma de cumplidos para que se ejecute cuando se envíen los documentos a revisión, y no cada vez que se crea un nuevo certificado de cumplimiento.
Dada la situación de los errores del certificado sin resolver en cumplidos, con Juan Camilo se tuvo una reunión para adelantar el planteamiento del flujo tanto de rechazo como del cambio solicitado por el profe Daza. De dicha reunión surgieron los requerimientos e incovenientes a superar para poder implementarlo, acordamos entonces elaborar cada uno un flujo y luego unificar ideas para poder tener una propuesta válida.
La idea de Juan Camilo planteaba usar los rótulos de carga de documento, rechazo de supervisor y rechazo de ordenador como guías para saber qué documentos desactivar y cuales no al rechazo:
Sin embargo surgía el inconveniente de que si el contratista generaba un nuevo informe no había forma de diferenciar el borrado del nuevo, por lo que basándome en la idea de Juan Camilo, propuse el siguiente flujo:
En un primer vistazo hubo un consenso en que podría ser una solución viable sin embargo Juan Camilo resaltó la necesidad de realizar varios cambios para que dicha solución pudiese ser implementada.
Por lo tanto la propuesta está pendiente de un análisis más riguroso
Se identificó el cliente de cumplidos ya funciona correctamente y ya se pueden subir otra vez informes de gestión, gracias a ello se hizo un avance el cuál está referido en el issue de implementación de múltiples firmantes en la actualización de hoy, sin embargo aún no se ha corregido el error esporádico que se presenta al firmar el supervisor, ya que el avance es concerniente al nuevo requerimiento para la primera firma solicitado por el profesor Daza
Se requiere realizar la corrección en cumplidos CPS ya que al momento de realizar la última etapa de la firma está consultando un documento que no corresponde al solicitado por lo que la firma está quedando de manera incorrecta.
Sub Tareas
Criterios de aceptación
Requerimientos
No aplica
Definition of Ready - DoR
Definition of Done - DoD - Desarrollo