Development #40017
Indiquer dans le retour du WS de passage de liste d'attente à liste principale si l'inscription est en sur-réservation
0%
Description
Lors du POST sur {{reservation_response_api_accept_url}}, en cas de succès, on ne sait pas si la demande est en sur-réservation.
Cela pourrait être utile de disposer de cette information dans le retour du WS.
Fichiers
Révisions associées
Historique
Mis à jour par Mikaël Ates il y a environ 4 ans
- Sujet changé de Indiquer dans le retour du WS de passage de liste d'attente à liste > principale si l'inscription est en sur-réservation à Indiquer dans le retour du WS de passage de liste d'attente à liste principale si l'inscription est en sur-réservation
Mis à jour par Lauréline Guérin il y a environ 4 ans
- Fichier 0001-api-return-overbooked_places-in-accept-endpoint-resp.patch 0001-api-return-overbooked_places-in-accept-endpoint-resp.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Mik: j'ai choisi de ne renvoyer le champ overbooked_places que si c'est pertinent, tu préfères que je l'envoie tout le temps (même si égal à 0) ou pas ?
Mis à jour par Mikaël Ates il y a environ 4 ans
Ne le renvoyer que si c'est pertinent me semble pertinent.
Pour le cas d'usage qui est d'afficher une alerte à l'agent ça marcherait donc avec la condition d'affichage réduite à :
reservation_response_overbooked_places
?
Mis à jour par Thomas Noël il y a environ 4 ans
Lauréline Guerin a écrit :
Mik: j'ai choisi de ne renvoyer le champ
overbooked_placesque si c'est pertinent, tu préfères que je l'envoie tout le temps (même si égal à 0) ou pas ?
Techniquement et généralement, je conseille de renvoyer toujours le même schéma d'informations. En effet en imaginant un cas où un workflow fait plusieurs appels successifs du webservice avec le même identifiant, il faut savoir que w.c.s. ne "nettoie" pas les données précédentes. Donc si tu n'envoies pas une donnée, elle sera quand même là, mais avec la valeur de l'appel précédent. C'est facilement source de confusion (et ça peut planter un workflow si tu mets une condition sur cette variable).
Je sais pas si ça s'applique totalement ici (y aura-t-il plusieurs appels...) mais bon, voilà, globalement c'est mieux de toujours renvoyer le même format de réponse.
Mis à jour par Lauréline Guérin il y a environ 4 ans
- Fichier 0001-api-return-overbooked_places-in-accept-endpoint-resp.patch 0001-api-return-overbooked_places-in-accept-endpoint-resp.patch ajouté
ok, ça se tient :)
Mis à jour par Thomas Noël 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 f675e0e7ef975bd0e122478eb702823de10e014d
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date: Thu Mar 5 16:18:09 2020 +0100
api: return overbooked_places in accept endpoint response (#40017)
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: return overbooked_places in accept endpoint response (#40017)