Produits Entr'ouvert » Chrono

Sur l'appel à datetimes

Ok mais il était choisi comment le créneau dans #63297 ?

Frédéric Péters a écrit :

Ok mais il était choisi comment le créneau dans #63297 ?

(je ne suis pas sûr de comprendre la question)

C'est la situation de la description du ticket.

Un usager y fait une résa via un agenda virtuel, les agendas réels qui y sont inclus ont des délais de réservations différents, un créneau libre sort via datetimes parce que qu'il y a bien un créneau libre sur un agenda réel X et que c'est raccord avec les délais de X. Puis sur la pose de la réservation ça déraille, la résa devrait arriver sur X (ou n'importe quel autre agenda où c'est libre et raccord avec les délais) et elle arrive sur Y alors que ce créneau est pas raccord avec les délais de Y.

Ce qui explique #63297#note-11, en passant par l'agenda virtuel "au plus rapide" les gens arrivent à réserver pour le 26 avril dans "Mairie de quartier de Borny", tandis que s'ils choisissent le lieu (datetimes via agenda normal, délais de réservation honorés) ils ne voient pas de créneau libre.

(je ne suis pas sûr de comprendre la question)

Si le paramétrage était correctement pris en compte dans l'API /datetimes (ce que je pensais avoir compris de ton commentaire), qu'elle ne renvoyait bien que les créneaux "licites", et comme c'est l'API /datetimes qui est utilisée pour afficher des créneaux (à moins qu'autre chose ici c'était ma question), comment est-ce qu'une sélection d'une valeur "illicite" a pu se faire ?

Puis sur la pose de la réservation ça déraille, la résa devrait arriver sur X (ou n'importe quel autre agenda où c'est libre et raccord avec les délais) et elle arrive sur Y alors que ce créneau est pas raccord avec les délais de Y.

Mais avec ça j'ai donc compris qu'il n'y avait pas prise de créneau illicite en soit, c'est "juste" que le créneau licite était ensuite enregistré sur un agenda où il ne l'était pas.

Sur l'appel à fillslot ils sont violés, get_all_slots appelé avec start_datetime = début du créneau à réserver et end_datetime = fin du créneau à réserver

C'était probablement pour optimiser l'appel à get_all_slots, et réduire la fenêtre de recherche de créneaux dans le cas où on sait déjà où ça doit tomber.

Plutôt que faire

        used_min_datetime = base_min_datetime
        if base_agenda.minimal_booking_delay is None:
            used_min_datetime = get_min_datetime(agenda, start_datetime)
        used_max_datetime = base_max_datetime
        if base_agenda.maximal_booking_delay is None:
            used_max_datetime = get_max_datetime(agenda, end_datetime)

Lauréline Guerin a écrit :

pourquoi pas faire du min/max ?

Jusqu'à maintenant l'interface des agendas virtuels est :

- si pas de délais des réservation min/max sur l'agenda viruel, ceux des agendas réels sont utilisé
- sinon les délais de l'agenda virtuel prennent le pas

Si je ne m'abuse ta proposition ferait passer l'interface à :

- utilisation des délais les plus (ou les moins selon la gueule du patch) restrictifs

Emmanuel Cazenave a écrit :

Jusqu'à maintenant l'interface des agendas virtuels est :

Et ce ticket montre que ça marchait moyennement, mais cette interface était NOTRE PROJET.

je pensais à:

used_min_datetime = max(base_min_datetime, get_min_datetime(agenda, start_datetime))
used_max_datetime = min(base_max_datetime, get_max_datetime(agenda, end_datetime))

(tu peux essayer de ne pas mélanger les tests datetimes/fillslots dans un module qui s'appelle datetimes ? :) )

Lauréline Guerin a écrit :

c'est pas vraiment ce que j'avais en tête :)

Si ce que tu avais en tête était un découpage en plusieurs tests différents : les assertions sur le résulats de datetetimes sont juste là pour vérifier que l’environnement est bien mis en situation de reproduire le bug, et ce sont les assertions postérieures à l'appel à fillslot qui reproduisent le bug = ya pas de lieu d'écrire un test part dans test_meetings_datetimes.py.

Automatic expiration