Project

General

Profile

Development #40039

Réduire/augmenter le nombre de places d'une inscription

Added by Mikaël Ates about 1 month ago. Updated 10 days ago.

Status:
Solution déployée
Priority:
Normal
Category:
-
Target version:
-
Start date:
19 Feb 2020
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

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.

0002-api-endpoint-to-resize-a-booking-40039.patch View (11.5 KB) Lauréline Guerin, 05 Mar 2020 02:04 PM

0001-api-can-not-cancel-accept-or-suspend-a-secondary-boo.patch View (9.52 KB) Lauréline Guerin, 05 Mar 2020 02:04 PM

0003-api-endpoint-to-resize-a-booking-40039.patch View (11.6 KB) Lauréline Guerin, 09 Mar 2020 12:14 PM

0002-api-can-not-cancel-accept-or-suspend-a-secondary-boo.patch View (9.52 KB) Lauréline Guerin, 09 Mar 2020 12:14 PM

0001-misc-blak.patch View (1.3 KB) Lauréline Guerin, 09 Mar 2020 12:14 PM

0002-api-endpoint-to-resize-a-booking-40039.patch View (12.2 KB) Lauréline Guerin, 17 Mar 2020 03:01 PM

0001-api-can-not-cancel-accept-or-suspend-a-secondary-boo.patch View (9.51 KB) Lauréline Guerin, 17 Mar 2020 03:01 PM

Associated revisions

Revision bccba482 (diff)
Added by Lauréline Guérin 13 days ago

api: can not cancel, accept or suspend a secondary booking (#40039)

Revision 8ea7b2ae (diff)
Added by Lauréline Guérin 13 days ago

api: endpoint to resize a booking (#40039)

History

#1 Updated by Lauréline Guerin 27 days ago

  • Assignee set to Lauréline Guerin

#2 Updated by Lauréline Guerin 27 days ago

Discussion de specs avec Fred:
  • 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é.

#3 Updated by Emmanuel Cazenave 27 days ago

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 .

#4 Updated by Frédéric Péters 27 days ago

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.

#5 Updated by Mikaël Ates 27 days ago

(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

#6 Updated by Lauréline Guerin 27 days ago

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)

#7 Updated by Frédéric Péters 27 days ago

... 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".

#8 Updated by Mikaël Ates 27 days ago

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.

#9 Updated by Lauréline Guerin 25 days ago

#11 Updated by Frédéric Péters 13 days ago

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).

#13 Updated by Frédéric Péters 12 days ago

  • Status changed from Solution proposée to Solution validée

#14 Updated by Lauréline Guerin 11 days ago

  • Status changed from Solution validée to 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)

#15 Updated by Frédéric Péters 10 days ago

  • Status changed from Résolu (à déployer) to Solution déployée

Also available in: Atom PDF