Bug #63913
Un PATCH sur un booking avec en paramètre user_name ne met pas à jour le user_name mais l'ajoute user_name en extra_data.
0%
Description
Un PATCH sur un booking avec en paramètre user_name ne met pas à jour le user_name mais l'ajoute en extra_data. Il semblerait plus approprié de mettre à jour le user_name.
Exemple :
PATCH sur https://agendas-departement06.test.entrouvert.org/api/booking/6123/ avec user_name :
Je lis le booking dans une demande wcs : https://demarches-departement06.test.entrouvert.org/backoffice/management/inscription-aux-activites/3278/inspect
Je vois form_workflow_data_lecture_reservation_response_extra_data_user_name : TEST TEST test 05/11/1951 DUO : John Doe
Je suppose donc que le user_name n'est pas modifié puisque "DUO : John Doe" n'apparaît pas sur https://agendas-departement06.test.entrouvert.org/manage/agendas/73/events/10830/
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Lauréline Guérin il y a environ 2 ans
et en utilisant les champs user_first_name et user_last_name ?
(User_last_name seulement si tu ne peux pas splitter user_name)
Mis à jour par Mikaël Ates (de retour le 29 avril) il y a environ 2 ans
Je n'ai pas essayé mais dans mon déploiement je ne fais usage que de user_name.
Mis à jour par Lauréline Guérin il y a environ 2 ans
C'est vrai qu'on mentionne toujours user_name dans la doc fillslot.
A un moment on a introduit user_first_name et user_last_name (pour le tri des résa, c'est plus pratique), et pour des raisons de compatibilité avec les anciens appels on enregistre user_name dans user_last_name.
Le endpoint PATCH booking est plus récent, et on n'y gère pas l'ancien champ user_name (par choix ou par oubli, je ne sais plus). Quoiqu'il en soit ni user_name, user_first_name ou user_last_name ne sont mentionnés dans la doc pour ce endpoint.
En attendant qu'on décide quoi faire, tu peux envoyer user_last_name sur un patch booking, c'est équivalent à poster user_name sur un fillslot
Mis à jour par Mikaël Ates (de retour le 29 avril) il y a presque 2 ans
- Assigné à mis à Lauréline Guérin
Je viens de tester de faire un PATCH sur user_last_name et il va d'ajouter également en extradata (qu'il ait été défini préalablement ou non lors de la réservation). Après un patch user_last_name la lecture du booking fera donc apparaître response_extra_data_user_last_name dans le retour WS.
Idem sur le champs label.
Est-ce qu'un PATCH ne permettrait pas actuellement de modifier uniquement 'in_waiting_list', 'user_was_present', 'user_absence_reason', 'extra_data' ?
Mis à jour par Lauréline Guérin il y a presque 2 ans
- Assigné à changé de Lauréline Guérin à Mikaël Ates (de retour le 29 avril)
Oui, en effet, tu as raison, le patch booking ne gère ni user_name, ni user_first_name, ni user_last_name. Je pensais que c'était le cas pour les deux derniers, sans avoir vérifié le code, désolée.
Du coup si on ajoute le support de user_first_name et user_last_name pour PATCH, ça suffit pour ton cas d'usage ? Ou tu as besoin aussi de user_email et user_phone_number ?
Mis à jour par Mikaël Ates (de retour le 29 avril) il y a presque 2 ans
- Assigné à changé de Mikaël Ates (de retour le 29 avril) à Lauréline Guérin
Très bien pour user_first_name et user_last_name mais si ça ne coûte pas beaucoup plus cher il faudrait aussi mettre à jour les autres champs, il y a user_email et user_phone_number mais on pourrait aussi inclure form_url, backoffice_url, cancel_callback_url et color.
Uniquement donc ne pas gérer user_display_label et user_name qui semblent en cours de dépréciation (?).
Mis à jour par Mikaël Ates (de retour le 29 avril) il y a presque 2 ans
- Lié à Bug #63915: Configuration du texte d'affichage des réservations d'événements et des rendez-vous dans les agendas ajouté
Mis à jour par Lauréline Guérin il y a presque 2 ans
Très bien pour user_first_name et user_last_name mais si ça ne coûte pas beaucoup plus cher il faudrait aussi mettre à jour les autres champs, il y a user_email et user_phone_number mais on pourrait aussi inclure form_url, backoffice_url, cancel_callback_url et color.
Pour ce ticket je ne vais gérer que les champs user (user_first_name, user_last_name, user_email, user_phone_number)
Uniquement donc ne pas gérer user_display_label et user_name qui semblent en cours de dépréciation (?).
user_display_label semble n'être utilisé que pour les reminders et les ics
user_name en effet est déprécié, lorsqu'on le reçoit on l'envoie dans user_last_name
Mis à jour par Lauréline Guérin il y a presque 2 ans
- Fichier 0001-api-patch-booking-user-fields-63913.patch 0001-api-patch-booking-user-fields-63913.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 2 ans
- Statut changé de Solution proposée à Solution validée
Mis à jour par Lauréline Guérin il y a presque 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 3db7658f6e35cc18c813f051b860005ead397dd5
Author: Lauréline Guérin <zebuline@entrouvert.com>
Date: Thu May 5 14:12:48 2022 +0200
api: patch booking & user fields (#63913)
Mis à jour par Transition automatique il y a presque 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
api: patch booking & user fields (#63913)