Produits Entr'ouvert » Chrono

Partis pris peut-être peu éclairé d'ignorer le problème si la réservation qu'on cherche à annuler n'existe pas ou est déjà annulée.

Retourner une erreur dans ces situations.

Je me dis que ça pourrait être monté plus haut, histoire de ne pas avoir à calculer les créneaux dispos si la réservation ne peut de toute façon pas se faire.

Aussi, vérifier count, et là, au choix, soit obliger que ça soit nécessairement 1, soit prêter attention au primary_booking, et assurer que le count corresponde à celui qui avait servi à la réservation.

Flash : manque aussi d'encapsuler tout ça dans une transaction.

La totale.

Je me dis soudainement qu'on a besoin d'être plus subtil sur le calcul du nombre de places restantes : un événement pourrait être vu comme plein et la réservation refusée parce qu'on ne prends pas en compte les places libérées par l'annulation dans ce calcul.

Emmanuel Cazenave a écrit :

Je me dis soudainement qu'on a besoin d'être plus subtil sur le calcul du nombre de places restantes : un événement pourrait être vu comme plein et la réservation refusée parce qu'on ne prends pas en compte les places libérées par l'annulation dans ce calcul.

Ça n'a aucun sens.

Dans la réponse, s'il y a eu un cancel, je serais pour le dire, genre « response['cancelled'] = payload.get('cancel_booking_id') » dans l'idée que wcs stockera ça dans son retour, et on ainsi savoir que la réservation en a aussi annulé une autre (et le dire à l'usager, avec juste un "if response_data_cancelled" dans le mail, ce genre de truc). Je suis d'accord qu'on le sait déjà car on a fait l'appel webservice pour, mais il peut avoir un workflow avec différentes branches, etc...

Aussi, en fait, au lieu de juste faire « if 'cancel_booking_id' in payload » on devrait plutôt faire un « if payload.get('cancel_booking_id'): » dans l'idée qu'un appel webservice avec un cancel_booking_id vide, c'est acceptable, ça veut juste dire "y'a rien à annuler". Ca simplifiera l'appel via les workflows -- bon, j'imagine que le « cancel_booking_id = serializers.IntegerField() » va nous faire chier.

Emmanuel Cazenave a écrit :

Aussi, en fait, au lieu de juste faire « if 'cancel_booking_id' in payload » on devrait plutôt faire un « if payload.get('cancel_booking_id'): » ...

Ça ouvre quand même en grand la porte à des annulations qui ne se font pas parce que paramétrage de l'action d'appel webservice foirée et pas de remontée d'erreur.

Effectivement, laissons tomber pour l'instant. On verra si c'est vraiment utile pour remplacer par quelque chose comme -1 ou 0... (oui, je sais, c'est moche)

Tu rajoutes un test qui faile avec params={'cancel_booking_id': ''} ? (pour le jour où ça changera) (oui, j'aime être pénible)

Si je comprends correctement, tu peux committer Manu ? Je testerai après déploiement sur la recette.

Un peu tardivement je vois la question sur les événements mais je comprends pas l'utilité de déplacer dans un événement, pour moi c'est un truc limité au RdV.

Mais c'est peut-être qu'on peut déplacer d'un événement à un autre ce que je n'avais pas compris.