DMRamirezZarta
commented
1 month ago Feedback Read Appointments
- Find Appointment by ID
se hicieron busquedas por el Id del turno usando el jwt de los diferentes roles y el sistema trajo la informacion sin problema.
- Find Appointments by Patient ID
Prueba con JWT del Tutor: La búsqueda utilizando el JWT del tutor devolvió correctamente los turnos asignados al paciente. Esto indica que el sistema está manejando adecuadamente la autorización para los tutores.
Prueba con JWT del Paciente: La búsqueda utilizando el JWT del paciente también mostró correctamente los turnos asignados al paciente. El sistema está funcionando correctamente para los pacientes en este caso.
Prueba con JWT del Médico: La búsqueda con el JWT del médico arrojó el error esperado, ya que un médico no debería acceder a los turnos de los pacientes. Esto indica que el sistema está manejando correctamente la autorización.
- Find Appointments by Patient ID and Date
Prueba con Fecha Existente: Al buscar con la fecha de una cita existente, el sistema devolvió la información correcta. Esto indica que el sistema maneja adecuadamente las búsquedas de citas para fechas específicas.
Prueba con Fecha Sin Turnos: Al usar una fecha en la que el paciente no tiene turnos asignados, el sistema devolvió un 200 OK sin mensaje informativo. Recomendación: Mejorar la respuesta del sistema para incluir un mensaje informativo o indicación clara cuando no existan turnos para la fecha proporcionada, para una mejor experiencia del usuario.
- Find Appointments by Doctor ID and Date
Prueba con Fecha Existente: La búsqueda con la fecha de una cita existente mostró correctamente la información de los turnos del doctor.
Prueba con Fecha Sin Turnos: Similar al caso anterior, el sistema devolvió un 200 OK sin resultados cuando no había turnos en la fecha especificada. Recomendación: Implementar un mensaje o indicación clara en caso de que no existan turnos para la fecha proporcionada, para mejorar la experiencia del usuario.
- Find Appointments by Doctor ID Between Dates
Pruebas con Fechas Correctas: La búsqueda entre las fechas correctas (por ejemplo, de 07:00 a 18:00 del mismo día) mostró los turnos asignados correctamente.
Uso Sin Rango de Fechas: Cuando se realizó una búsqueda sin especificar el rango de fechas, el sistema devolvió información de turnos con un 200 OK. Si el rango de fechas es un parámetro obligatorio, debería haber un error indicando que faltan parámetros, por lo contrario no seria un inconveniente.
Prueba con JWT Incorrecto: La búsqueda con un JWT de rol incorrecto (no autorizado) devolvió el mensaje correcto de "no tiene permiso". Esto indica que la autorización está funcionando correctamente.
Prueba con JWT Expirado: El sistema permitió la búsqueda con un JWT expirado, cuando se esperaba un mensaje de error por el token expirado.
Recomendación: Asegurarse de que se devuelvan mensajes de error adecuados para fechas inválidas y parámetros faltantes. También, revisar la validación del JWT para garantizar que solo se permita el uso del token más reciente.
- Find Available Hours by Doctor ID and Date
Problema con JWT del Paciente: Al usar el JWT del paciente, el sistema arrojó un error y no devolvió información. Esto indica que la funcionalidad no está operando como se esperaba.
Prueba con JWT del Médico: Al usar el JWT del médico, el sistema mostró el rango horario completo del médico, incluyendo horas ocupadas. El sistema debería mostrar solo las horas libres.
Problema con Rango de Fechas: Se permitió un rango de fechas que abarca más de un día, cuando la validación debe realizarse para un solo día. Aunque puede ser útil para la planificación anticipada de citas, es necesario ajustar la validación para asegurar que solo se muestren las horas disponibles del mismo día.
Recomendación: Revisar y ajustar la funcionalidad para asegurar que se muestre solo la disponibilidad real de horas libres, y validar correctamente el rango de fechas para el mismo día.
- Seguridad de JWT
El sistema actualmente permite el uso de tokens JWT antiguos incluso después de que se ha generado un nuevo JWT durante el inicio de sesión. Este comportamiento representa un riesgo de seguridad significativo, ya que los tokens comprometidos pueden seguir siendo válidos hasta su expiración, a pesar de que se ha emitido un nuevo token.
@GuillermoDivan
Se trata de varios endpoints, que se pueden clasificar en según son para doctor (su propio turnero, no puede ver el de otros profesionales de salud, se puede comprobar enviando el jwt del doctor 1 mientras se pone la id del doctor 2) o para paciente (general, lo puede ver tanto doctor como paciente o tutor).
En este segundo grupo, la comprobación para que otros pacientes/tutores que no están relacionados no puedan acceder no está hecha. Queda pendiente para más adelante si hay tiempo suficiente.
El {active} final es necesario para marcar si la sesión está activa o no en db. Será útil para rol admin (buscar sesiones canceladas, por ejemplo).
Se recomienda especial atención con el formato de las fechas, se especifica abajo.
Los objetos pueden ser múltiples (varios turnos) a excepción del 1°. Dicho esto, no deberían ser múltiples 4° ni 5° si se especifica hora -como la url requiere, al menos durante este MVP-, porque el registro no sería posible.
Teniendo lo dicho en cuenta, siempre se retornará 200 (llega una lista, vacía o con resultados). Se recomienda prestar especial atención a los casos donde llegue vacía, a ver si es o no lo que corresponde.
TODOS son action get.
Endpoints y especificaciones:
Find appointment by id (del appointment!). Trae un solo objeto. url : http://localhost:7082/api/v1/appointment/{id}/{active} jwt : sí, cualquiera.
Find appointments by patient id. url : http://localhost:7082/api/v1/appointment/patient/{id}/{active} jwt : sí, cualquiera.
Find appointments by doctor id. url : http://localhost:7082/api/v1/appointment/doctor/{id}/{active} jwt : sí, el propio doctor (y nadie más de los roles actuales).
Find appointments by patient id and date. url : http://localhost:7082/api/v1/appointment/patient/{id}/{date}/{active} ejemplo de date: 2024-07-17T09%3A00 jwt : sí, cualquiera.
Find appointments by doctor id and date. url : http://localhost:7082/api/v1/appointment/doctor/{id}/{date}/{active} ejemplo de date: 2024-07-17T09%3A00 jwt : sí, el propio doctor (y nadie más de los roles actuales).
Find appointments by patient id between dates. url : http://localhost:7082/api/v1/appointment/patient/{id}/{startDate}/{endDate}/{active} ejemplo de date: 2024-07-17T09%3A00 En este caso, irían las dos fechas separadas por / ... atención a que la primera sea anterior a la segunda. jwt : sí, cualquiera.
Find appointments by doctor id between dates. url : http://localhost:7082/api/v1/appointment/doctor/{id}/{startDate}/{endDate}/{active} ejemplo de date: 2024-07-17T09%3A00 En este caso, irían las dos fechas separadas por / ... atención a que la primera sea anterior a la segunda. jwt : sí, el propio doctor (y nadie más de los roles actuales).
8: Find available hours by doctor id and date (range date). url : http://localhost:7082/api/v1/appointment/doctor/{id}/{startDate}/{endDate}/available para que funcione como es esperado, tanto la start date como la end date debe ser del mismo día... y se recomienda que las horas sean 07 y 23hs respectivamente. ejemplo de date: 2024-07-17T07%3A00 jwt : sí, del paciente/tutor. La idea de este endpoint es que front pueda mostrar los horarios disponibles en X día para determinado doctor.