CIT - Verifica turnos y solicitudes al asignar demanda

[ma7payne]

Requerimiento

https://proyectos.andes.gob.ar/browse/CIT-344

Funcionalidad desarrollada

1. Pide datos de solicitudes pendientes asociadas al paciente y la prestación
2. Si existen solicitudes se muestra modal informando de las mismas
3. Finaliza cierre de demanda al cerrar modal

Requerimiento

https://proyectos.andes.gob.ar/browse/CIT-345

Funcionalidad desarrollada

1. Pide datos de turnos futuros asociados al paciente y la prestación
2. Si existe turno se evita el guardado de la demanda y se muestra modal notificando los datos del turno

UserStory llegó a completarse

• Si
• No
• No corresponde

Requiere actualizaciones en la base de datos

• Si
• No

Requiere actualizaciones en la API

• Si CIT - implementa control de turnos y solicitudes pendientes api#1981
• No

Requiere actualizaciones en andes-test-integracion

• Si
• No

[MCele]

Mati estuvimos revisando y los modal se ven y funcionan perfecto, pero al momento de cerrar una demanda falla el request a la api

Por otro lado, por lo que estuvimos viendo y analizando es que el post que se modifica en la api da respuestas distintas dependiendo del caso y por ahi nos queda dudas si eso es apropiado, es decir:

1. si existe un turno, esta bien que no lo guarde, pero la respuesta quizás no deba ser status 200, porque no fue exitosa la operación.
2. si no existen turnos, y si existen solicitudes, eso quizás debería ser un control externo al post, ya que no modifican su comportamiento. Lo que vimos también en ese caso, es que la app en ventanilla-citas, ya resuelve ese mismo request de solicitudes, quizás se pueda desde ahí reutilizar ese servicio. De no ser así, habría que evaluar si es necesario en api generar una consulta nueva y no utilizar la que ya tiene prestaciones, que es dónde debería estar la consulta a la BD.

Mati cualquier duda consultanos a mi o a Lauchita y lo charlamos

[ma7payne]

@MCele y @negro89 estan realizados los siguientes cambios:

• Llama al servicio correspondiente para guardar la demanda.
• Si existe turno API devuelve un error 500 y muestra un modal con los detalles del turno. Se interrumpe el flujo para que no se recuperen las solicitudes pendientes.
• Si el guardado es exitoso, consulta las solicitudes relacionadas desde APP, invocando PrestacionesService. Si encuentra solicitudes asociadas, las muestra en un modal. Se utiliza switchMap para evitar subscribes anidados.
• Si no hay solicitudes, muestra un mensaje confirmando que la demanda fue guardada con éxito y cierra el flujo.
• Se agrega la opción { showError: false } en listaEspera.service para evitar mostrar el modal de error por defecto.

Quedo atento a las correcciones!

[ma7payne]

Con respecto al error de guardado de demandas, queda solucionado con el fix en #3113.