Development #42195
Option pour ne pas proposer à l'usager des évènements dont la liste d'attente a commencé à se remplir
0%
Description
= solution du pauvre pour gérer la concurrence des réservations
Les malheureux qui réservent en même temps sur le même évènement mais qui perdent la course de la concurrence sont mis en liste d'attente,
avec l'idée que le workflow les basculera en normale.
Et pendant ce temps plus personne peut faire de résa sur l'évènement surbooké parce qu'il sera caché.
Fichiers
Historique
Mis à jour par Emmanuel Cazenave il y a environ 4 ans
- Fichier 0001-api-add-no-waiting-list-parameter-42195.patch 0001-api-add-no-waiting-list-parameter-42195.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mis à jour par Thomas Noël il y a environ 4 ans
Vu de loin j'aurai tendance à dire que ça devrait être le comportement par défaut (un événement est "disabled" dès qu'il n'y a plus de place). Et donc plutôt un paramètre "include-waiting-list". J'imagine que changer cette logique risque de casser des trucs mais j'ai tendance à penser que ça pourrait plutôt en réparer.
Je me rappelle aussi, d'une discussion avec toi Emmanuel, que le mode "la liste d'attente a commencé à se remplir" est plus compliqué que cela à calculer... (genre, il faudrait aussi vérifier qu'il n'y a personne en liste d'attente).
Mis à jour par Frédéric Péters il y a environ 4 ans
Oui ce n'est pas ainsi que l'info comme quoi la liste d'attente va être utilisée est calculé.
(et sur la bande je suis curieux que ça soit le style de formatage amené par black)
~~
Sur le changement de comportement proposé par Thomas, je serais prudent, et ne prendrais pas cette option.
Mis à jour par Emmanuel Cazenave il y a environ 4 ans
Je met de coté vos remarques pour une qui me parait plus problématique.
Sur la motivation initiale de concurrence du pauvre, deux personnes choisissent une évènement sur lequel il reste une seule place, le premier valide, le deuxième valide 2 seconde après : erreur 'choix invalide' de wcs qui ne trouve plus l'entrée correspondante dans sa data source ...
Un peu trop pauvre la solution du pauvre.
Mis à jour par Thomas Noël il y a environ 4 ans
Emmanuel Cazenave a écrit :
Sur la motivation initiale de concurrence du pauvre, deux personnes choisissent une évènement sur lequel il reste une seule place, le premier valide, le deuxième valide 2 seconde après : erreur 'choix invalide' de wcs qui ne trouve plus l'entrée correspondante dans sa data source ...
Bien vu. Gestion de lock, mon amour... (je ne vois rien d'autre possible)
Mis à jour par Frédéric Péters il y a environ 4 ans
Ce comportement est vérifié ? Et s'il l'est, il a lieu aussi si ?id= est précisé comme possible ?
Mis à jour par Emmanuel Cazenave il y a environ 4 ans
Frédéric Péters a écrit :
Ce comportement est vérifié ?
Oui.
Et s'il l'est, il a lieu aussi si ?id= est précisé comme possible ?
Je ne comprends pas.
Mis à jour par Frédéric Péters il y a environ 4 ans
C'était dans l'idée qu'on arrive peut-être à ce code :
def get_structured_value(self, option_id): value = None if self.type == 'json' and self.id_parameter: value = self.get_value_by_id(self.id_parameter, option_id) else: structured_items = get_structured_items(self.data_source, mode='lazy') for item in structured_items: if str(item['id']) == str(option_id): value = item break
i.e. si on est sur une source de données configurée avec la possibilité de récupérer précisément un élément, on le récupère, plutôt que récupérer le tout (qui dans notre discussion ne comprendrait plus l'élément désiré). (mais passons, rejetons ce ticket, prenons la vue plus large nécessaire).
Mis à jour par Emmanuel Cazenave il y a environ 4 ans
- Statut changé de Solution proposée à Rejeté
(for the record)
Coté chrono /api/agenda/XXX/datetimes/ ne supporte pas l'interrogation par identifiant.
Mais donc oui de toute façon j'arrête là, trop de bout de ficelles.