Continuar implementación de notificaciones - Parte 3

[diagutierrezro]

Se requiere realizar la continuación en la implementación de notificaciones, para este sprint se implementará en:

• Verificar el funcionamiento en las solicitudes faltantes (todas excepto cambio de titulo y solicitud inicial).
• Para la solicitud de revisión implementar notificación a todos los usuarios (estudiante, docente director y evaluadores en caso de tenerlos) una vez el coordinador aprueba.
• Notificar al estudiante y docente director, en caso de que el docente evaluador solicite correcciones. Definir con @mantnicot si se puede usar alguna de las plantillas existentes o es necesario la creación de una nueva.
• Notificar al docente director una vez el docente evaluador registra la nota.
• Notificar al estudiante y a la coordinación del proyecto curricular cuando el docente director registre la nota.

Sub Tareas

• [x] Verificar notificaciones de solicitudes faltantes.
• [x] Desarrollar notificaciones para solicitud de revisión.
• [x] Desarrollar notificaciones para solicitud de correcciones por parte del docente evaluador.
• [x] Desarrollar notificaciones cuando el docente evaluador registra nota.
• [x] Desarrollar notificaciones cuando el docente director registra nota.
• [x] Probar funcionamiento correcto de las notificaciones.

Criterios de aceptación

• [x] Verificación de solicitudes faltantes realizada.
• [x] Desarrollo de notificaciones en solicitud de revisión realizado.
• [x] Desarrollo de notificaciones en solicitud de correcciones realizado.
• [x] Desarrollo de notificaciones en registro de nota del docente evalador realizado.
• [x] Desarrollo de notificaciones en registro de nota del docente director realizado.
• [x] Pruebas de funcionamiento correcto realizadas.
• [x] Documentación de issue realizada.

Requerimientos

No aplica

Definition of Ready - DoR

• [x] Está refinada y estimada en puntos de historia por el equipo.
• [x] Incluye la descripción y criterios de aceptación, con el detalle funcional y especificaciones técnicas, de forma entendible por cualquier miembro del equipo.
• [x] No tiene bloqueos que impidan su ejecución.
• [x] Las dependencias están identificadas y resueltas.
• [x] Puede ser probada dentro del Sprint.

Definition of Done - DoD - Desarrollo

• [x] Desarrollo en local.
• [x] Push en Feature.
• [x] Pruebas locales (funcionales).
• [x] PR a Develop.
• [x] Criterios de aceptación cumplidos.
• [x] Documentación de issue realizada.
• [x] Aprobada por SM/Líder técnico.

[JuanDHernandezA]

• Verificación de notificación en las demás solicitudes: Se verifica que se realicen las 3 notificaciones durante el flujo completo de la solicitud

  • Solicitud de prórroga
  • Solicitud de cambio de evaluador
  • Solicitud de cambio de director interno
  • Solicitud de cambio de objetivos
  • Solicitud de cancelación de Modalidad
  • Solicitud de cambio de codirector
  • Solicitud de revisión de trabajo de grado

• Plantilla para la notificación al momento en que el Docente Evaluador solicita corrección de trabajo de grado:

Se revisaron las plantillas actuales y se encontró que la plantilla _POLUX_PLANTILLA_REVISIONDOC, la cual se usa al momento en que se agregan nuevos comentarios en la revisión de documento y ya había sido modificada, aún presenta una inconsistencia en su título debido a que el Docente no es el único que responde a estas revisiones:

Se consulta y propone a @mantnicot la opción de cambiar el título a "Nueva Respuesta A Revisión De Trabajo De Grado " con el fin de corregir la plantilla y adicional, usarla al momento en que el Docente Evaluador solicita corrección dentro del flujo de Revisión de Trabajo de Grado. Se aprueba el cambio y se modifica la plantilla, dando como resultado el siguiente correo:

[JuanDHernandezA]

Se comenzó el desarrollo de una función encargada de recuperar el correo y el nombre del vinculado según el rol que tenga, con el fin de recuperar la información del docente director y docente evaluador donde se requiera. Al probar la funcionalidad, ocurre el mismo error que se presentó durante el desarrollo del envío de múltiples archivos al gestor documental, no "espera" a que la petición se complete para almacenar la información recuperada a pesar de estar dentro de una función asíncrona y tener la palabra reservada await cuando realiza la petición. Se continua analizando posibles soluciones para dicho error.

A la par, se fue implementando la plantilla mencionada en el comentario anterior para cuando el docente evaluador solicita una corrección al trabajo de grado. Se probó la funcionalidad y se obtuvo el siguiente correo, en donde se puede observar que el nombre del usuario corresponde al Docente Evaluador y el comentario realizado si es el adjuntado por este usuario:

[JuanDHernandezA]

Se revisa la lógica desarrollada y se observa que en todas las partes del flujo en las que se responde a la solicitud está realizando la consulta para obtener los correos de los docentes vinculados, cuando debería ser únicamente cuando la coordinación aprueba la solicitud de revisión de trabajo de grado. Se elimina la función creada y se realizan las consultas dentro de un condicional en donde se entra cuando ocurre la situación mencionada. Se prueba la nueva funcionalidad y se observa que se almacenan los correos de forma correcta:

Ahora, se desea obtener el correo del estudiante que realiza la solicitud. Se revisan los datos que se han obtenido y dentro del campo detallesSolicitud se encuentra el código del estudiante, el cual se usará en la API de autenticacion_mid y recuperar el correo. Se implementa la lógica y se obtiene el siguiente listado de correos al momento en que la coordinación aprueba la solicitud de revisión, los cuales son: El correo del estudiante, del Docente Director y del Docente Evaluador

[JuanDHernandezA]

Se desarrolla la funcionalidad para notificar al Docente Director cuando el Docente Evaluador carga la nota del trabajo de grado. Se consulta desde la base de datos al vinculado del tabajo de grado cuyo rol sea el Docente Director y obtener el número de documento del usuario. Con este dato, se realiza la consulta en Autenticación_mid para obtener el correo.

Se recupera la demás información que se va a adjuntar en la plantilla de la notificación, para este caso se usa la plantilla _POLUX_PLANTILLA_REGISTRONOTA, se prueba la funcionalidad y da como resultado el siguiente correo:

[JuanDHernandezA]

Se desarrolla la funcionalidad para notificar al estudiante y a la coordinación cuando el Docente Director carga la nota y el acta de sustentación en el aplicativo Polux. Al igual que con el Docente Evaluador, se busca la información del destinatario por medio de Autenticacion_mid, recuperando el correo del estudiante:

Para la notificación, se usa la misma plantilla usada para notificar al Docente Director del cargue de la nota por parte del Docente Evaluador, dando como resultado el siguiente correo:

Queda pendiente el obtener el correo de la coordinación del proyecto curricular al que pertenece el estudiante.

Con respecto a la implementación de las notificaciones, falta probar el flujo para la modalidad de pasantía, incluyendo la notificación al cargar y responder la ARL. También, agregar los destinatarios para la solicitud inicial, las demás solicitudes y en el flujo de revisión de documento

[diagutierrezro]

Se debe realizar las averiguaciones sobre como se podría obtener el correo de las diferentes coordinaciones. Muy buen trabajo Juan Diego.