agendas: do not use minimal_booking_time in min_booking_datetime computation (#76303) #65
No reviewers
Labels
No Label
No Milestone
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: entrouvert/chrono#65
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/76303-minimal-booking-time"
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?
fcd238a4ab
to067fa6e802
067fa6e802
to3de9b9c303
WIP: agendas: do not use minimal_booking_time in min_booking_datetime computation (#76303)to agendas: do not use minimal_booking_time in min_booking_datetime computation (#76303)@ -1366,0 +1544,4 @@
assert resp.json['data'][-2]['datetime'] == '2023-04-04 09:00:00'
assert resp.json['data'][-1]['datetime'] == '2023-04-04 11:00:00'
# move juste after the first 2023-04-05 slot time
2023-04-03 ?
Heu non. Déjà pas d'évènements déclaré le 3 avril dans le test.
Et sur le fond, l'idée est :
Oui mais non, je ne comprends pas. Tu écris "move after 2023-04-05", et juste dessous, "freezer.move_to('2023-04-03T09:01:00+02:00')"
Le commentaire était : "move juste after the first 2023-04-05 slot time".
J'ai changé pour "move a few hours later, juste after the first slot time of a day".
@ -2663,0 +2786,4 @@
resp = app.get(api_url)
assert resp.json['data'][-1]['datetime'] == '2023-04-04 13:30:00'
# move juste after the first 2023-04-05 slot time
2023-04-03 ?
Même réponse que précédemment.
@ -2663,0 +2788,4 @@
# move juste after the first 2023-04-05 slot time
# this slots become available
freezer.move_to('2023-04-03T11:01:00+02:00')
j'ai un doute ici, on ne devrait pas aller jusqu'à 3*24H ? donc jusqu'au 6 avril 2023 à 11H01 ?
Je ne comprends pas ce que tu veux dire.
J'ai vaguement l'impression que ça a un rapport avec le fait que tu supposerais que la borne maximale (jour J + délai de réservation maximal) devrait être incluse.
Si c'est ça, non, elle est bien exclue actuellement (au passage https://dev.entrouvert.org/issues/76360).
@ -370,3 +370,2 @@
[
('2021-07-09T08:00:00+02:00', datetime.datetime(2021, 7, 13, 8)),
('2021-03-18T07:00:00+01:00', datetime.datetime(2021, 3, 22, 7)),
('2021-07-09T08:00:00+02:00', datetime.datetime(2021, 7, 12, 8)),
même remarque que plus haut, ça me paraissait bien avant: 4*24H donc si on est 2021-07-09T08:00:00+02:00 ça nous amène bien à 2021-07-13T08:00:00+02:00
Encore borne maximale exclue.
Sauf que, dans le cas non flottant, test
test_events_datetimes_max_booking_datetime_with_minimal_booking_time
:On se pose le 3 avril à n'importe quelle heure, et on voit tous les créneaux du 5 avril. Ca fait en amplitude horaire entre 2 et 3 jours, 3 jours inclus si on se pose à minuit. Juste qu'on ne dépasse pas du 5, on ne regarde pas le 6 avril, qui est exclu.
Pour moi, si on est dans le cas flottant (avec ici un délai max à 4 jours):
on est au 2021-07-09T08:00:00+02:00, ça donne bien 2021-07-13T08:00:00+02:00, mais on exclut 2021-07-13T08:00:00+02:00: un event posé à 2021-07-13T08:00:00+02:00 n'apparaît pas, un event posé à 2021-07-13T07:59:59+02:00 apparaît
"On se pose le 3 avril......3 jours inclus si on se pose à minuit ...on ne regarde pas le 6 avril, qui est exclu."
Je ne comprends pas ton raisonnement, j'en ai un plus simple il me semble : le 3 avril, de 00h00 à 23h59, je ne verrai jamais aucun créneau du 6 avril, les créneaux les plus distants que je voie sont au 5 avril.
C'était déjà le cas avant l'introduction de l'horaire d'ouverture des réservations, ça reste le cas après.
Avec l'horaire d'ouverture des réservations, les créneaux du 5 avril se mettent soit à apparaître tous d'une coup à une heure donnée le 3 avril (à la place de 00h00), soit progressivement au fur et à mesure de la journée du 3 avril.
"Pour moi, si on est dans le cas flottant (avec ici un délai max à 4 jours):
on est au 2021-07-09T08:00:00+02:00 ... 2021-07-13T07:59:59+02:00 apparaît".
Le 2021-07-09 on doit jamais voir les créneaux du 2021-07-13 parce que délai max à 4 jours, peu importe les autres paramètres.
(j'abandonne)
(en partant de l'hypothèse qu'on a posé 3 jours de délai max).
"soit progressivement au fur et à mesure de la journée du 3 avril."
Et justement c'est ça qui me bloque; on devrait voir apparaître les créneaux du 6 avril progressivement au fur et à mesure de la journée du 3 avril, et pas ceux du 5 avril.
Je n'ai aucun problème avec le comportement non flottant, avec ouverture à minuit ou peu importe l'heure définie.
(et, le ticket décrit un problème de comportement en mode non flottant, mais cette PR impacte le mode flottant, dont le problème que tu essaies de corriger n'a pas été exposé dans la description du ticket)
3de9b9c303
toc7e9c0cd81
Désolé si c'est redite mais j'essaie de comprendre ce qui se passe ici, mais avant ça une note : on vérifie seulement le dernier créneau présenté, pas le premier, pourtant ce ticket vient parce qu'il y avait justement une influence non-désirée sur le premier créneau affiché. De là je me dis que ça serait utile de vérifier le premier créneau affiché.
Mais ce commentaire il s'applique en fait à 0001, qui est le commit "ne pas avoir d'influence sur le premier créneau dispo". Ensuite 0003 vocabulaire, ok.
Reste donc 0002 qui est "change max_booking_datetime implementation" et en fait il ne s'agit pas de juste changer l'implémentation, mais de changer un comportement, et toutes les questions concernent ce point ? Globalement je me sens un peu perdu entre ce qui existait, ce qui a été tenté en #56284, ce ticket.
En partant de l'idée que la migration passe l'existant sur "ouverture à minuit", les comportements seraient :
Est-ce que cette description correspond à avant ce ticket, ou à après ce ticket, ou à rien ?
"Est-ce que cette description correspond à avant ce ticket, ou à après ce ticket, ou à rien ?"
Cette description correspond exactement à après ce ticket.
Le comportement introduit par #56284, je ne saurais le décrire exactement, j'ai commencé par constater que "Horaire de réservation minimale : renseigner une heure peut faire apparaitre des cŕeneaux plus lointains et cacher des rdv proches".
Déjà "faire apparaitre des créneaux plus lointains", c'est contraire à la description que tu viens de poser, et puis de toute façon à un moment j'ai arrêté d'essayer de recenser les problèmes, pour me concentrer sur ce qu'on veut que ça fasse, écrire les tests unitaires qui en rendent compte, changer l'implémentation pour que les tests passent.
"'soit progressivement au fur et à mesure de la journée du 3 avril.'
Et justement c'est ça qui me bloque; on devrait voir apparaître les créneaux du 6 avril progressivement au fur et à mesure de la journée du 3 avril, et pas ceux du 5 avril."
= en mode floattant, le délai de réservation max serait violé. Je ne comprends pas ce que tu ne comprends pas.
@lguerin : en fait maintenant je comprends ce que tu veux dire (tu tiens compte de l'horaire des rdv pour calculer le délai max) mais je ne suis pas du tout d'accord sur le fait qu'on veuille cela.
Pour reprendre la description de Fred, adapté ta sauce (les x + 1 sur la dernière ligne) ça ferait:
Je ne vois vraiment pas l'utilité de ce x+1 à la place de x ...
Heu non, tu vois ça où ?
En fait ça serait plutôt:
Il suffit de remplacer x par délai max de réservation = 1 jour pour avoir:
Avec ce que tu as codé, si délai max de réservation = 1 jour, en mode flottant, alors on ne voit jamais aucun créneau.
(commentaire posté sans voir les derniers vôtres)
"Avec ce que tu as codé, si délai max de réservation = 1 jour, en mode flottant, alors on ne voit jamais aucun créneau."
Et en mode non flottant, pour prendre rdv à 9h00, il faut s'être connecté entre 00h00 et 9h00 le jour même, très pratique : c'est un cas complètement irréaliste !
A part ça quel bénéfice ?
Pour les pages de doc, pour les explications à donner aux clients, pour notre cerveau, qu'il ait J+x dans tous les cas (= J+X-1 si x est le délai max), plutôt qu'introduire une variation sur le cas flottant, c'est quand même beaucoup mieux non ?
Je ne suis pas d'accord; qu'en pensent les CPFs ?
Je trouve plus logique d'expliquer (en supposant pour simplifier qu'il n'y a pas de délai min):
J'ajoute ma pierre à l'édifice: je ne m'étais pas tellement intéressé au comportement avec heure, le cas flottant étant pour moi le plus intéressant. Mais à y réfléchir le code Manu est le bon je pense:
L'appliquer à min_booking_datetime, je m'étais posé la question dans le ticket
https://dev.entrouvert.org/issues/56284#note-14
mais comme personne n'a voulu trop relire vraiment, voilà. Je suis d'accord que ça a plus de sens de ne pas l'appliquer, c'est vraiment la borne basse qui nous intéresse.