Development #20280
api : conserver libellé / url / nom d'usager
0%
Description
Aujourd'hui on stocke tout un dictionnaire "data" dans booking.extra_data; je propose qu'en plus on reconnaisse/définisse quelques clés standards, qui seront stockées dans leurs propres attributs.
Me semble qu'avec un libellé (libre mais typiquement ça pourrait être [form_number]), une url ([form_url_backoffice]) et un nom d'usager ([form_user_display_name]), on couvre le nécessaire.
Fichiers
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a plus de 6 ans
- Fichier 0001-general-add-label-user-url-metadata-on-bookings-2028.patch 0001-general-add-label-user-url-metadata-on-bookings-2028.patch ajouté
- Statut changé de Nouveau à En cours
- Patch proposed changé de Non à Oui
Mis à jour par Thomas Noël il y a plus de 6 ans
Pour user, est-ce qu'on considérerait que ça peut être un lien vers un vrai user Django (provisionné par mellon, dans l'idée à terme d'avoir une vue de l'agenda de cette personne) ? Et même si on n'ajoute pas cette foreignkey maintenant, plutôt nommer le champ ajouté ici « user_display_name ».
Dans la même idée, nommer plus explicitement l'URL comme étant celle du backoffice, genre url_backoffice ?
Tout ça dans l'idée de se souvenir juste en lisant l'API de ce qui est attendu dans ces champs.
Mis à jour par Frédéric Péters il y a plus de 6 ans
- Fichier 0001-general-add-label-user_name-backoffice_url-metadata-.patch 0001-general-add-label-user_name-backoffice_url-metadata-.patch ajouté
Pour user, est-ce qu'on considérerait que ça peut être un lien vers un vrai user Django (provisionné par mellon, dans l'idée à terme d'avoir une vue de l'agenda de cette personne) ? Et même si on n'ajoute pas cette foreignkey maintenant, plutôt nommer le champ ajouté ici « user_display_name ».
Yep j'avais hésité, mon principal argument étant que le modèle et l'API correspondent et d'avoir un truc simple à taper du côté de la configuration de l'appel webservice; mais changer en user_name (display_name c'est un peu trop quand même) et backoffice_url, ok.
Et peut-être plus tard accepter un user_uuid servant à trouver un compte provisionné.
Mis à jour par Frédéric Péters il y a plus de 6 ans
- Fichier 0001-general-add-label-user_name-backoffice_url-metadata-.patch 0001-general-add-label-user_name-backoffice_url-metadata-.patch ajouté
En mettant aussi à jour les tests c'est mieux.
Mis à jour par Frédéric Péters il y a plus de 6 ans
- Statut changé de En cours à Résolu (à déployer)
commit a51fb45aa4686172b07e848e761dac87d980b704
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Sun Nov 26 10:56:11 2017 +0100
general: add label/user_name/backoffice_url metadata on bookings (#20280)
Mis à jour par Frédéric Péters il y a plus de 5 ans
- Statut changé de Résolu (à déployer) à Solution déployée
general: add label/user_name/backoffice_url metadata on bookings (#20280)