montar polux y dar informe

[BOTOOM]

con el fin de retomar el sistema polux para su desarrollo, teniendo en cuenta que hace algunos meses ocurrió un error de infraestructura, se requiere realizar lo siguiente:

• [x] descargar los repositorios necesarios para el sistema.

• [x] montar en local el cliente con sus apis respectivas que deben ser montadas en local.

• [ ] informar que apis no estan en test y necesitan ser desplegadas.

• [ ] si llegan a haber incoherencia de datos con un api informar.

• [ ] cualquier problema relacionado con la funcionalidad del sistema, listarlo en el presente issue

[BrayanB24]

Se comienza con la ejecución de la tarea

[BrayanB24]

En primera medida se clonará el repositorio cliente y se le harán los respectivos cambios al PATH para adecuarlo a las API que están funcionando luego de el inconveniente con el servidor .254

[BrayanB24]

Al realizar las modificaciones del path las primeras observaciones son las siguientes:

• No se tiene claridad con cual es el servicio "SESIONES_SERVICE", no existe en el inventario de API's de la OAS y es utilizado en el cliente, al parecer aún no se hacen peticiones allí pero hay que averiguar en que punto se necesita.

• Tampoco se tiene claridad sobre el serivicio de "AUTENTICATION_MID_SERVICE" el cual está apuntando a autenticación. De ser así se debe solicitar el acceso a esa API con el token para cliente locales del 9000.

• El menú se encuentra fuera de servicio, se debe verificar cual era la estructura del mismo y así volverlo a crear o solicitar su creación o restauración.

• Se debe tener claridad sobre los tipos de usuarios que pueden iniciar sesión en la plataforma polux, actualmente el servicio que le realiza petición a "autenticacion_mid" está devolviendo error 500 por lo que se relaciona posiblemente con el rol actual de quien inicia sesión. Se debe revisar la documentación para así conocer cuales son los usuarios que pueden iniciar sesión de manera correcta.

• De no estar el servicio de autenticacion_mid este deberá ser levantado de manera local.

@BOTOOM

[BrayanB24]

Luego de en la documentación también sobre cuales usuarios tienen privilegios sobre qué, además del acceso a tablas de menú. Se observa que aún cuando se intenta ingresar con un usuario administrador de todo el sistema, el API "autenticacion_mid" sigue devolviendo el estado 500 de internal server error. En definitiva esta API debe ser montada localmente y pedir ser re desplegada una vez se compruebe su funcionamiento. Tampoco se tiene acceso a los Menú, deberá ser verificado el menú en los servicios del core.

[BrayanB24]

Luego de una reunion para conocer las razones por las cuales se había modificado el servicio de sesiones, en reunion con el core se llega a al acuerdo de que se hará un versionamiento de la API la cual quede en funcionamiento solo para polux y no comprometer el desarrollo antes hecho.

[BrayanB24]

Se levanta el servicio de "autenticacion_mid", el servicio retorna con base en el correo de WSO2 los datos de código, estado, email, rol. El api se levanta en local de manera correcta pero al ingresar con el usuario de WSO2 este no está retornando el correo con el token. También, hay algunos usuarios de prueba en la documentación de polux que no están iniciando sesión correctamente, se deben revisar usuarios y pedir que se devuelva el correo en el token de WSO2

[BrayanB24]

Se solicita con la persona encargada la corrección en la respuesta de WSO2 de manera correcta, se valida y se confirma que esta en funcionamiento correcto. De la misma manera se revisa el servicio de autenticación_mid y se levanta de manera local revisando que esté funcionando de manera correcta. De esta manera polux vuelve a funcionar en su autenticación, ahora se pasa a revisar el servicio de JBPM de académica.

[BrayanB24]

El servicio de JBPM de académica no funciona desde autenticación.portaloas.... por contenido mixto, el arquitecto recomienda deshabilitar CORS y mixed content desde el navegador. El procedimiento se realiza sin obtener éxito por lo que se procede a solicitar endpoint para path sin autenticación.

[BrayanB24]

El servicio de académica JBPM no contiene todos los endpoint desarrollados para polux, es indispensable que se recupere la versión del API que existía de JBPM para polux, de lo contrario no se podrá restaurar de manera correcta el aplicativo. Se queda a la espera para hablar con el arquitecto. @BOTOOM

[BrayanB24]

Se verifica la utilización del servicio de Académica Service en todo el proyecto polux y se crea una lista con todos los endpoint que faltan en el servicio actual de académica para que el responsable del mismo los vuelva a poner en funcionamiento para el proyecto de polux.

La lista puede ser consultada en el siguiente link:

https://docs.google.com/spreadsheets/d/1fG0q-t9zu0_MtxChhzLig-E1kydhzryax_kIbDynghg/edit?usp=sharing

[BrayanB24]

Los servicios se restauran de manera correcta pero estos deben ser añadidos en el AM de WSO2 uno a uno, a medida de que se vayan necesitando se van solicitando. Por otro lado la función de menú debió ser actualizada para que tomara la propiedad correspondiente del JSON del payload de la autenticación.

[BrayanB24]

Se seguirá entonces el plan de pruebas funcionales dejado como documentación del sistema para llevar el control del funcionamiento del sistema, así mismo si surge un error corregirlo de forma que se llegue a un funcionamiento completo del sistema. de la misma manera se llevará un documento como control de la ejecución de las pruebas funcionales para conocer el estado de cada una, el documento se encuentra en el siguiente link:

https://docs.google.com/document/d/1s9LwkgO-FIgBKDkjqDwXnf5T0yVBVDKpZ4Y8S2Rttvs/edit?usp=sharing

@Eduargonzalez @BOTOOM

[BrayanB24]

Realizando las pruebas funcionales de las áreas de conocimiento, presenta un error el sistema con el SweetAlert y con los swal de notificación de proceso que debe revisarse, este muestra un error de swal indefinido, pero al hacer la respectiva importación del módulo en el index.html , al compilar el cliente esta compilación lo borra por lo que habrá que revisar de fondo los módulos de cada sistema.

[BrayanB24]

Siguiendo el plan de pruebas funcionales se completa el registro del área de conocimiento de manera correcta. Es necesario para el correcto desarrollo de las pruebas un usuario que cumpla las condiciones descritas para la primera parte que es el proceso de modalidad de grado por pasantía. El plan de pruebas describe las siguientes condiciones:

• Haber aprobado el 80% de los créditos académicos del plan de estudios.

• Tener acuerdo de voluntad, convenio o contrato avalado por la unidad de extensión.

• Tener una propuesta avalada por un docente interno.

• Máximo 2 estudiantes.

Se debe buscar este usuario en el sistema, se buscará el servicio antiguo que realizaba la busqueda. @BOTOOM @Eduargonzalez

[BrayanB24]

se debe solicitar el registro ahora del endpoint de JBPM en WSO2 de datos_estudiante. Se hace la solicitud a la persona encargada.

[BrayanB24]

El registro de EndPoints ha quedado completo en WSO2 informado por el ingeniero encargado. Por otro lado se detecta que el servicio de "datos_estudiante" no retornaba de manera correcta el porcentaje cursado de los estudiantes que ingresan al sistema, por lo que fue solicitado este cambio y fue realizado por el arquitecto dentro de los servicios de JBPM validando que desde condor se calcule el porcentaje y pueda ser incluido en el mismo para el correcto funcionamiento del sistema. Se da por validado el proceso con el arquitecto. @BOTOOM @Eduargonzalez

[BrayanB24]

Se hace la validación de los susuarios, estos deben ser buscados a mano y ser validados en el servicio de jbpm, para así lograr encontrar los que son relevantes dentro del sistema. El proceso se continúa de manera correcta con el usuario de WSo2 del líder técnico, y permite llegar de manera correcta a la revisión de las modalidades de grado, la modificación del servicio de JBPM fue crucial.

[BrayanB24]

Se modificó el servicio de de crear solicitud parar que fuera compatible con el nuevo JSON enviado por JBPM y se corrobora funcionamiento.

[BrayanB24]

Sigueindo con la solicitud de pasantía, polux no está validando de forma correcta los requisitos de cada estudiante, al parecer, el mid y el crud siguen apuntando en algunas partes al servidor 254, por lo que hay que hacer la revisión de las API y re asignar las variables de entorno, se procede a realizar el procedimiento.

[BrayanB24]

El principal problema resulta ser el Ruler Api el cual estba apuntando al servidor .254, se hace el respectivo cambio al ruler desplegado en test en donde se encuentran ya desplegadas las reglas de polux, es de aclarar que en test la variable del ruler api debe ser la que apunta a preprod (pruebas...). Luego de esto se presenta un problema en un API de JBPM el cual se validará con el ingeniero encargado.

[BrayanB24]

El error ocurre a causa de falta de permisos en el usuario que consulta la base de datos de ese servicio. Se debe hacer la correspondiente solicitud de los permisos necesarios para dicho usuario, los datos de base y tabla fueron comunicados ya a el lider técnico @BOTOOM y se queda a la espera de la solución del mismo.

[BOTOOM]

en el siguiente kamban se realiza la peticion de permisos a la base de datos con el usuario respectivo:

https://tuleap.udistrital.edu.co/plugins/tracker/?aid=34458

se le asigna al ingeniero German.

aunque segun nos informan ningún DBA tiene contrato y entregaron las claves

[BOTOOM]

https://tuleap.udistrital.edu.co/plugins/tracker/?aid=34488 se solicita permisos de lectura para el esquema de sesiones en produccion