Projet

Général

Profil

Development #40039

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

Ajouté par Mikaël Ates il y a environ 4 ans. Mis à jour il y a environ 4 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
19 février 2020
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

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

Révision bccba482 (diff)
Ajouté par Lauréline Guérin il y a environ 4 ans

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

Révision 8ea7b2ae (diff)
Ajouté par Lauréline Guérin il y a environ 4 ans

api: endpoint to resize a booking (#40039)

Historique

#1

Mis à jour par Lauréline Guérin il y a environ 4 ans

  • Assigné à mis à Lauréline Guérin
#2

Mis à jour par Lauréline Guérin il y a environ 4 ans

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

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 .

#4

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.

#5

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

#6

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)

#7

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

#8

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.

#11

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

#13

Mis à jour par Frédéric Péters il y a environ 4 ans

  • Statut changé de Solution proposée à Solution validée
#14

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)
#15

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

Formats disponibles : Atom PDF