Bug #44739
Une inscription avec un plusieurs places est répartie entre liste principale et liste d'attente
0%
Description
Demande d'inscription https://demarches-departement06.test.entrouvert.org/backoffice/management/inscription-aux-activites/908/
La demande à l'origine pour une place est a été mise sur liste d'attente. Elle a été basculée sur liste principale en surréservation. Le nombre de place a été augmenté à 10 places. La demande se retrouve alors répartie entre liste principale et liste d'attente : https://agendas-departement06.test.entrouvert.org/manage/agendas/176/events/5158/.
Fichiers
Révisions associées
Historique
Mis à jour par Mikaël Ates (de retour le 29 avril) il y a presque 4 ans
Si la demande n'est pas en surréservation, si le nombre de places demandé est supérieur à la dispo, le WS retourne une erreur (code 3). Si la réservation est déjà en sur-réservation, deux possibilités : refuser d'augmenter le nombre de places, laisser augmenter le nombre de places (sans limite).
Il me semble que le second choix est cohérent avec le fait que l'on autorise toujours la sur-réservation (je pourrai faire une nouvelle réservation avec n places sur liste d'attente et de la basculer en sur-réservation sur la liste principale).
Mis à jour par Lauréline Guérin il y a presque 4 ans
Je me rends compte que le endpoint resize fonctionne très mal: je compare le nombre de place réservées au total (quelle que soit la réservation primaire) et le nombre de place souhaité pour une réservation primaire donnée
Est-ce que:
1/ il est possible de faire un hotfix dès que j'ai un patch, ou alors envoyer pour la mep de jeudi
2/ on peut désactiver les démarches qui l'utilisent le temps du fix ?
Mis à jour par Lauréline Guérin il y a presque 4 ans
proposition:
échouer si la réservation primaire et les potentielles réservations secondaires ne sont pas du même côté de la liste d'attente lors du call à resize (parce que sinon on ne sait pas comment resizer la réservation)
toujours mettre les nouvelles places réservées du même côté de la liste d'attente que la réservation primaire
toujours laisser passer les diminutions de place
si la demande est surdimensionnée, dans le cas d'une augmentation de places:- toujours échouer si la réservation primaire est en liste d'attente, car il n'y a pas de surréservation en liste d'attente
- échouer si la réservation primaire est en liste principale mais que l'événement n'est pas encore plein
- et donc sinon (la réservation primaire est en liste principale mais l'événement est déjà en surréservation): laisser passer le resize
Mis à jour par Lauréline Guérin il y a presque 4 ans
- Fichier 0001-api-fix-resize-endpoint-44739.patch 0001-api-fix-resize-endpoint-44739.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Frédéric Péters il y a presque 4 ans
- Statut changé de Solution proposée à Solution validée
# total places for the event (in waiting or main list, depending on the primary booking location)
places = booking.in_waiting_list and event.waiting_list_places or event.places
Sur ces constructions je trouve plus clair désormais de faire places = ... if ... else ....
Sur le fond il me semble qu'il y a la situation de vouloir agrandir alors qu'il n'y a pas de liste d'attente et qu'on veut autoriser la surréservation mais je ne sais pas si c'est une situation rencontrée, et de toute façon ça ne devrait pas être le comportement par défaut, donc je pense que c'est ok ainsi et si jamais le besoin particulier est exprimé on verra pour ajouter un flag à cet appel pour explicitement autoriser la surréservation.
Voilà, validé avec le changement de syntaxe "... if ... else ...".
Mis à jour par Lauréline Guérin il y a presque 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 2ba381fa341867aa5fd4c7e9264ab8b3e24e4270
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date: Mon Jul 20 17:39:45 2020 +0200
api: fix resize endpoint (#44739)
Mis à jour par Frédéric Péters il y a presque 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée
api: fix resize endpoint (#44739)