api: add endpoint to check partial bookings (#84122) #190
lguerin
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/84122-plages-libres-API-pointage"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
c6ada35d25toe9a4c27b95WIP: api: add endpoint to check partial bookings (#84122)to api: add endpoint to check partial bookings (#84122)@ -3099,0 +3152,4 @@user_checks = booking.user_checks.all()# ignore booking with multiple checksif len(user_checks) == 2:j'ai un doute, on devrait quand même peut-être parcourir les bookings et les user checks dans l'ordre et noter l'heure du pointage sur le premier datetime vide (start ou end) ? Pour ne pas perdre l'information ?
Imaginons un cas où un enfant est noté absent excusé le matin, à l'avance, parce que l'absence est prévue, le parent arrive à midi et pointe. Il faudrait sans doute ne pas perdre cette information de pointage, et créer un booking check pour le reste de la réservation avec cette heure en start ?
Et dans ce cas, en sortie, on a bien 2 users checks qui existent, le second étant incomplet.
(le calcul du facturé s'ajustera automatiquement)
C'est le comportement idéal en effet, je n'avais pas réfléchi jusque là parce que je m'imaginais des cas complexes toujours gérés à la main, mais celui que tu pointes ne paraît pas si complexe.
La question technique est donc de savoir quand est-ce qu'on en crée un deuxième pointage, de ton exemple ce serait quand le premier est une absence, ça me paraît donner un comportement cohérent.
En fait ça n'a pas de sens de dire « le premier », la règle c'est donc simplement d'ignorer les pointages qui ne sont pas des présences dans cette API.
api: add endpoint to check partial bookings (#84122)to WIP: api: add endpoint to check partial bookings (#84122)e9a4c27b95to57072a5ef3WIP: api: add endpoint to check partial bookings (#84122)to api: add endpoint to check partial bookings (#84122)