Produits Entr'ouvert » Chrono

Note dans #17681 : « À côté de ce côté interface on doit aussi réfléchir aux mécanismes pour éviter que ça ne soit abusé et sans doute d'autres points. »

Je ne comprends pas bien le besoin du lock_code, pourquoi ne pas simplement ajouter un paramètre booléen lock si celui-ci présent on pose lock_expiration. On renvoie le event.id ou un truc du genre. Sur un nouvel appel avec cet event_id on vire toutes les histoires de lock, c'est la confirmation de la réservation.

Ça évitera d'avoir à générer un lock_code coté w.c.s. (maintenant c'est peut-être volontaire de pouvoir envoyer un truc un peu intelligible comme l'identifiant du formulaire je ne sais pas trop).

Pour moi le code serait plus clair avec deux web-services plutôt que de tout surcharger sur un un seul (un de pré-réservation l'autre de réservation).

Benjamin Dauvergne a écrit :

Je ne comprends pas bien le besoin du lock_code, pourquoi ne pas simplement ajouter un paramètre booléen lock si celui-ci présent on pose lock_expiration. On renvoie le event.id ou un truc du genre. Sur un nouvel appel avec cet event_id on vire toutes les histoires de lock, c'est la confirmation de la réservation.

Ouaip, c'est ce qui semble naturel... Mais la contrainte vient de w.c.s. : il peut rien stocker lors du formulaire. Il va juste lancer une condition de sortie, c'est tout (il ne peut rien faire du résultat). À ce stade le lock_code choisi par l'appelant est la seule solution que j'ai trouvée.

Un petit avantage, c'est que si le lock a finalement expiré entre temps mais que la confirmation réussi quand même (parce qu'il reste quand même une place), et bien tout se passe tranquillement. (parce qu'on ne cherche pas à valider une résa existante, mais bien à faire une résa, en considérant le lock comme libre).

Et du disposes de quoi pour construire ton lock code ? Un numéro de session ? Un id de draft ?

Benjamin Dauvergne a écrit :

Et du disposes de quoi pour construire ton lock code ? Un numéro de session ? Un id de draft ?

Oui, je pensais à form_number.

Ça m'a l'air ok.

On a maintenant session_hash_id #39784 qui peut faire l'affaire en première approximation ; ce ticket peut reprendre vie.

3 tests dont le comportement change vers minuit : https://jenkins.entrouvert.org/job/chrono-wip/job/wip%252F17685--preblocage-d-une-reservation/2/

Qu'est-ce que fait le SQL de la migration ? EXCLUDE USING GIST(desk_id WITH =, tstzrange(start_datetime, end_datetime) WITH &&) franchement qui a inventé une syntaxe pareille. (l'explication peut s'accompagner d'un renommage de sql_forwards en quelque chose de plus parlant)

Mais avant de relire le code je voulais tester et justement, en essayant d'appliquer la migration,

  Applying agendas.0088_lease...Traceback (most recent call last):
  File "/home/vdeniaud/envs/publik-env-py3/lib/python3.7/site-packages/django/db/backends/utils.py", line 82, in _execute
    return self.cursor.execute(sql)
psycopg2.errors.UndefinedObject: data type integer has no default operator class for access method "gist" 
HINT:  You must specify an operator class for the index or define a default operator class for the data type.

je voulais tester

De bout en bout ? i.e. avec une démarche wcs ?

(ici appel du pied à Benjamin pour qu'il la partage)

Benjamin Dauvergne a écrit :

Si c'est la première fois que la syntaxe SQL te parait bizarre c'est que tu es t

Je n'ose imaginer de quel nom tu voulais me traiter !

Est-ce que la migration 0053 n'échouerait pas chez toi ? (ton user n'est pas administrateur de postgresql).

Pas testé, pas envie de shooter ma db ni de créer un autre tenant juste pour voir. Par contre j'ai googlé et il me manquait un CREATE EXTENSION btree_gist; et c'est désormais bon.

Valentin Deniaud a écrit :

Benjamin Dauvergne a écrit :

Si c'est la première fois que la syntaxe SQL te parait bizarre c'est que tu es t

Je n'ose imaginer de quel nom tu voulais me traiter !

Je voulais écrire très tolérant :)

Est-ce que la migration 0053 n'échouerait pas chez toi ? (ton user n'est pas administrateur de postgresql).

Pas testé, pas envie de shooter ma db ni de créer un autre tenant juste pour voir. Par contre j'ai googlé et il me manquait un CREATE EXTENSION btree_gist; et c'est désormais bon.

Le CREATE EXTENSION btree_gist est justement dans la migration 0053.

Ça marche bien chez moi aussi, pas vraiment de remarques sur le fond, sur la forme :

Renommage de migration, mettre 0091 et pas juste 91.

+      If it is booked but match the lock code, report the slot as open.
+
     """ 

+        # only lock related to on of the agenda or the resource

La méthode as_interval de Lease n'est pas utilisée.

Dans fillslot tu as mis un allow_blank=True et ensuite tu vérifies que le champ n'est pas vide, il faudrait virer les deux et ça marcherait pareil.

Commit en cours de revert.

De #54780#note-26,

Le code de pré-blocage peut fonctionner, mais plus mal, sans l'index, les gens qui n'ont pas une base à jour auront juste des bugs qu'on aura pas.

Identifiés, ils peuvent être pris en compte dans une nouvelle version de ce patch ? Ou bien il s'agit de bug "quand même parfois sous forte charge il y aura une réservation qui passera" ?

Aussi/surtout, à passer sur les chaines à traduire j'ai vu "lock_code does not work with events" qui correspond à ce commentaire plus haut :

PS: j'ai aussi complètement bloqué la fonctionnalité pour le cas des évènements, je n'avais pas de test sous la main et je me suis dit que ce serait mieux de reprendre ça à froid si ça devient nécessaire un jour.

Les grosses affluences ça a souvent été pour les événements, je pense par exemple aux piscines à Toulouse.

De la description du ticket d'ailleurs : « choisir un événement » (c'est plus loin qu'il commence à être question de rendez-vous et conflits de réservation).

Je me permets de réveiller ticket, suite à #75543.
Je ne sais pas si le préblocage de rendez vous est couvert dans ce ticket.

Olivier Renard a écrit :

Je me permets de réveiller ticket, suite à #75543.
Je ne sais pas si le préblocage de rendez vous est couvert dans ce ticket.

Justement ça ne couvre que les rendez-vous, pour moi ce n'était pas un problème.

Oui, peut être qu'il faut dissocier le préblocage d'un rdv et le préblocage d'une place d'un événement (je ne connais pas la complexité technique à le faire).
Il n'y a pas la même criticité.
Une événement a souvent un nombre de places, a potentiellement une file d'attente, ce qui donne moins de criticité entre le choix de la place dans le formulaire et l'appel webservice de réservation.
Un rdv a plus de criticité (de mon point de vue).

La description du ticket c'est les événements et Fred citait l'exemple des piscines prises d'assaut.

Mais c'est vrai qu'un cas d'usage souvent évoqué pour ce lock c'est les RdV pour avoir une carte de séjour qui sont épuisés dès la mise à disposition des créneaux avec un trafic (dans tous les sens du terme) de dingue.

Et bien sûr c'est mieux d'avoir ça au moins pour les RdV que de ne rien avoir du tout. Après ce serait pas mal que ce qui est fait pour les RdV ne soit pas à détricoter le jour où on se souciera des événements, quand même. Je ne sais pas si cette dimension peut être prise en compte.

Pierre Cros a écrit :

Et bien sûr c'est mieux d'avoir ça au moins pour les RdV que de ne rien avoir du tout. Après ce serait pas mal que ce qui est fait pour les RdV ne soit pas à détricoter le jour où on se souciera des événements, quand même. Je ne sais pas si cette dimension peut être prise en compte.

C'est totalement indépendant, il faudra une solution complètement différente de toute façon, parce que déjà gérer les évènements et les rdv dans la même application n'avait pas de sens même initialement, on aurait pu faire deux applications. Le partage des modèles est totalement artificiel, il n'y a rien de commun dans le code entre les deux, à part qu'un évènement et un rdv ont des date de début et de fin.

Le principal souci pour les événements c'est de déterminer un comportement quand une liste d'attente est configurée. Des gens pourront se retrouver en liste d'attente alors que les réservations précédentes verrouillées se libérent. Il faudrait une gestion automatique de la liste d'attente pour repasser ces personnes sur la liste principale avant de nouvelles réservations; et il faudrait pouvoir notifier w.c.s. de ce changement sans que celui-ci ait à poller l'état de la réservation. Comportement qui aurait son intérêt même pour le cas des annulations. Ou alors ne pas accepter de réservation en liste d'attente tant que la liste principale n'est pas rempli de réservations fermes.

J'ai rebasé mon code et je suis reparti en partie du concept de Thomas, Lease est désormais un modèle fils de Booking ça donne le support sur les rendez-vous et les évènements. Je dois rajouter encore des tests sur les évènements et faire le tour des nouvelles APIs pour voir si ça doit impacter ou pas leur fonctionnement.

Je me permets une relance sur ce besoin.

Voilà c'est re-vert.