Open motey opened 1 month ago
As discussed in a meeting, we need an endpoint that returns all events on a proband level. We need to know if a proband has allready one or more interviews in a event. Also we need events to rankable.
All mandatory backend changes are implemented in https://github.com/DZD-eV-Diabetes-Research/DZDMedLog/tree/rewrite/feat-events-by-probant (Luckily without the need of a major refactor 😅)
New backend/API features:
interview_number
becomes interviewer_user_id
and is now a foreign key to user table (attribute fill in, will be handled by backend)order_position
which is the default order_by
attr/study/{study_id}/proband/{proband_id}/event
whichproband_id
and the number of interviews for given proband under each event proband_interview_count
.exlude_empty_events
in the query params/study/{study_id}/event/order
.order_position
in sequence of the given list.@JTaeger this is yours now. Lets discuss/test/merge that when you are back in town.
Update: Merged it allready in python/rewrite for the sake of https://github.com/DZD-eV-Diabetes-Research/DZDMedLog/issues/26
Hey @JTaeger and @lamuc i am just looking at the API design and trying to find a better solution that represents our goal ( of having the proband at the root which does have an interview at a specific event) better then the current solution. While thinking i actually dont see a problem with the current design :)
A study has a fixed list of Events which we can manage with the![grafik](https://github.com/DZD-eV-Diabetes-Research/DZDMedLog/assets/1006417/7656946d-9fdb-4687-89a0-f2da993b0dcf)
event
chapter of the API:A patient now can have a interview in any of these events:![grafik](https://github.com/DZD-eV-Diabetes-Research/DZDMedLog/assets/1006417/5bc8b3e3-8dec-496f-a733-112678d8de77)
So what is wrong with the api/data-model? It is just a matter of presentation in the GUI! The user need to select the event while starting a new interview with a proband. Prove me wrong! :)