Implementar flujo de consulta y guardado de tercero si no existe basándose en el código de estudiante o documento del docente

[NeFaWaltPint]

Se requiere verificar al momento de ingresar al componente de evaluación docente si la consulta de id del tercero es exitosa (userService.getPersonaId del localstorage) en caso contrario, consultar si es docente el documento (userService.getUserDocument) o si es estudiante usar (userService.getCodigoEstudiante) [para averiguar los roles puede usar (userService.getUserRoles)].

De ahí usando academica_jbpm/v2/consultar_datos_docente/{documento} puede traer la info del docente y registrar el tercero, y para el estudiante puede usar academica_jbpm/v2/datos_basicos_estudiante/{codigo}. Una vez registrado el tercero se puede relacionar su documento en datos_identificacion teniendo en cuenta el tipo de documento respectivo.

Adicionalmente, para evitar fallo que al consultar nuevamente durante esa misma sesión por userService.getPersonaId de que el id no exista usar la función encrypt() de utils para setear el valor de personaId en el local storage.

Sub Tareas

• [x] Consultar dato de usuario según el rol.
• [x] Con el documento o código consultar la información relacionada del usuario y registrarla en terceros junto con sus datos de identificación.
• [x] Si se crea el tercero setear personaId del localstorage para evitar posible duplicación de tercero si el flujo de consulta se vuelve a realizar durante esa sesión.

Criterios de aceptación

• [x] Ajuste funcional en microcliente.
• [x] Documentación de issue.

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.
• [ ] Criterios de aceptación cumplidos.
• [ ] Documentación de issue realizada.
• [ ] Aprobada por SM/Líder técnico.

[diegofceliv]

Documentación:

Se realiza la validación de los servicios de academica_jbpm.

Consulta con docente: Se identifica que la consulta no trae los datos del docente, solo indica si es de planta

Consulta con estudiante Se identifican que trae los nombres del estudiante y nada mas

Consulta servicio ODIN: Aquí tenemos los documentos y nombres del estudiante y del docente.

Teniendo en cuenta lo anterior, se opta por tomar los datos para validar y registrar contra terceros del servicio de ODIN ya que los llamados hacia academica_jbpm no aportan datos adicionales.

---

Se realiza ajuste para consultar el id de la persona logueada y tomarlo como evaluador, cuando se selecciona un docente, se consulta contra el servicio de terceros por el numero de identificacion y si se encuentra se toma como evaluado, sino existe, se registra.

Pruebas: