Development #40039
Réduire/augmenter le nombre de places d'une inscription
0%
Description
Un réservation peut être posée sur plusieurs places grâce au paramètre count.
Une fois la réservation souhaitée il pourrait être offerte la possibilité de réduire ou d'augmenter le nombre de places sous réserve de disponibilité.
La méthode manuelle consiste à poser une nouvelle réservation avec le nombre souhaité et à annuler l'ancienne réservation. Cela convient bien souvent. Cependant, il se pourrait que dans une situation fortement concurrentielle, il faille faire attention à ne pas perdre les places sur la liste principale. En effet, si la réservation porte sur 2 places sur liste principale et que le souhait est d'en ajouter 2 parce qu'il en reste 2 sur liste principale, la nouvelle réservation posera 4 places sur liste d'attente. Il faudra alors baculer la nouvelle réservation sur liste principale puis annuler la réservation initiale. Cela produit une surréservation temporaire mais assure que des places sur liste principale ne soient pas données le temps de la manipulation.
En cas de réduction du nombre de place, si le nouveau nombre souhaité est supérieur au nombre de places disponibles sur liste principale, la réservation ira sur liste d'attente et il faudra appliquer le même principe.
Un workflow évolué pourrait être élaboré pour automatiser ce traitement mais la succession d'appels WS pourrait multiplier les cas de figure d'erreurs à gérer dans le WF.
En outre, tout cela n'est possible que s'il y a une liste d'attente et ensuite que la place sur celle-ci le permet.
Il serait donc intéressant de disposer de cette gestion dans chrono avec un appel WS sur une réservation permettant d'augmenter ou de réduire le nombre de places.
Fichiers
Révisions associées
api: endpoint to resize a booking (#40039)
Historique
Mis à jour par Lauréline Guérin il y a environ 4 ans
- le booking primaire est toujours du même côté que ses bookings secondaires
- modifier les endpoint cancel, accept et suspend pour n'accepter d'agir que sur des bookings primaires (les secondaires suivent le primaire)
- un appel fait ailleurs que sur le primaire est refusé
- un appel pour réduire la taille est toujours ok, mais ne passe pas automatiquement de liste d'attente à liste principale
- un appel pour augmenter la taille, s'il dépasse la taille allouée, est refusé.
Mis à jour par Emmanuel Cazenave il y a environ 4 ans
Lauréline Guerin a écrit :
- le booking primaire est toujours du même côté que ses bookings secondaires
Pas sur de comprendre mais en tous cas ça m'a évoqué ça : https://dev.entrouvert.org/issues/38306#note-9 .
Mis à jour par Frédéric Péters il y a environ 4 ans
le booking primaire est toujours du même côté que ses bookings secondaires
Ce que cette phrase signifie c'est qu'on ne peut pas avoir en liste d'attente l'événement primaire et en liste principale un événement secondaire, ni l'inverse. C'est quelque chose déjà assuré quand on fait des modifications sur l'événement primaire, il les applique aussi sur les secondaires, mais il n'y a rien aujourd'hui qui aurait empêché de créer une divergence par une modification sur un événement secondaire.
Mis à jour par Mikaël Ates il y a environ 4 ans
(Je ne sais pas ce que désigne un booking primaire ou secondaire.)
- un appel pour réduire la taille est toujours ok, mais ne passe pas automatiquement de liste d'attente à liste principale
Oui
- un appel pour augmenter la taille, s'il dépasse la taille allouée, est refusé.
Oui
Mis à jour par Lauréline Guérin il y a environ 4 ans
Pas sur de comprendre mais en tous cas ça m'a évoqué ça : https://dev.entrouvert.org/issues/38306#note-9 .
Fred, le lien de manu me semble pertinent et intéressant: si on réserve pour plusieurs events (endpoint fillslots), plusieurs places par event, on aura une seule réservation primaire: 1 réservation primaire pour le premier event et ses n-1 résa secondaires, n résa secondaires pour les autres events.
Du coup, les endpoint cancel, accept et suspend impactent toutes les résa (la primaire et les secondaires) de tous les events
Pour le nouvel endpoint de dimensionnement, est-ce que:
- je checke tous les events pour vérifier que l'opération de redimensionnement est possible (checker les places restantes en liste d'attente ou liste principale)
- ou je ne traite que les réservations de l'event lié à la réservation primaire
- ou autre solution
Note: pour les endpoints accept et suspend on ne fait aucun check du nombre de places, c'est normal ?
(Je ne sais pas ce que désigne un booking primaire ou secondaire.)
Mik, lorsqu'on crée une réservation pour n places via le endpoint fillslot(s), en DB on a: une réservation (instance de Booking) avec le champ primary_booking
None (on l'appelle alors réservation primaire), et n-1 réservations avec le champ primary_booking
égal à la réservation primaire (ce sont les réservations secondaires)
Mis à jour par Frédéric Péters il y a environ 4 ans
... n résa secondaires pour les autres events.
Ah oui j'oublie toujours qu'il y a une possibilité de réservation à de multiples événements à la fois; quand c'est le cas je serais pour refuser avec une erreur "booking covers multiple events".
Mis à jour par Mikaël Ates il y a environ 4 ans
il y a une possibilité de réservation à de multiples événements à la fois; quand c'est le cas je serais pour refuser avec une erreur "booking covers multiple events".
La réservation à de multiples événements me paraît toujours être une solution de dernier recours quand l'enchaînement des demandes n'est pas possible. Je serais aussi pour ne pas considérer possible la modification du nombre de places lors d'une réservation multiple, au moins dans un premier temps.
Mis à jour par Lauréline Guérin il y a environ 4 ans
- Fichier 0002-api-endpoint-to-resize-a-booking-40039.patch 0002-api-endpoint-to-resize-a-booking-40039.patch ajouté
- Fichier 0001-api-can-not-cancel-accept-or-suspend-a-secondary-boo.patch 0001-api-can-not-cancel-accept-or-suspend-a-secondary-boo.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Lauréline Guérin il y a environ 4 ans
- Fichier 0003-api-endpoint-to-resize-a-booking-40039.patch 0003-api-endpoint-to-resize-a-booking-40039.patch ajouté
- Fichier 0002-api-can-not-cancel-accept-or-suspend-a-secondary-boo.patch 0002-api-can-not-cancel-accept-or-suspend-a-secondary-boo.patch ajouté
- Fichier 0001-misc-blak.patch 0001-misc-blak.patch ajouté
un petit coup de black pour mettre tout ça au propre
Mis à jour par Frédéric Péters il y a environ 4 ans
Sur le passage :
+ bulk_bookings.append( + Booking( + primary_booking=booking, + event_id=event.pk, + in_waiting_list=bool(event.waiting_list_places and event.waiting_list), + label=booking.label, + user_name=booking.user_name, + backoffice_url=booking.backoffice_url, + user_display_label=booking.user_display_label, + extra_data=booking.extra_data, + ) + )
je me dis qu'on aurait à gagner une méthode spécifique pour initialiser les attributs à partir d'un booking existant, histoire de ne pas devoir mettre à jour différents endroits quand on ajoutera un nouvel attribut. (je pense à #40719). (mais à regarder il n'y a pour le moment pas d'autres endroits où cette recopie d'attributs se fait, donc c'est peut-être trop anticiper, je te laisse décider).
Mis à jour par Lauréline Guérin il y a environ 4 ans
Mis à jour par Frédéric Péters il y a environ 4 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Lauréline Guérin il y a environ 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 8ea7b2ae3732d48210ea46c0d2efd77266fd0e2a Author: Lauréline Guérin <zebuline@entrouvert.com> Date: Thu Mar 5 14:02:52 2020 +0100 api: endpoint to resize a booking (#40039) commit bccba482b4ad5ec7c51c10f58064513120998398 Author: Lauréline Guérin <zebuline@entrouvert.com> Date: Thu Mar 5 09:43:17 2020 +0100 api: can not cancel, accept or suspend a secondary booking (#40039)
Mis à jour par Frédéric Péters il y a environ 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée
api: can not cancel, accept or suspend a secondary booking (#40039)