Support #44357
[API] Le WS de listing des reservations oblige à ce qu'un slug des événements existe mais tous les événements n'ont pas de slug.
0%
Description
Appel WS {{ agendas_url }}api/agenda/{{ form_var_agenda_raw }}/bookings/{{form_var_evenement_slug}}/
Mais les événements n'ont pas forcément de slug.
Peut-on rendre possible l'accès via le champs id
de l'événement ?
Demandes liées
Historique
Mis à jour par Mikaël Ates il y a presque 4 ans
- Lié à Development #40719: API : disposer d'un appel permettant de savoir si un utilisateur est inscrit à un événement. ajouté
Mis à jour par Emmanuel Cazenave il y a presque 4 ans
C'est juste pour contourner #40719 ou c'est aussi plus facile, dans les cours de tes appels, de taper l'ID plutôt que le slug ?
Mis à jour par Mikaël Ates il y a presque 4 ans
Lors de la création manuelle, le champs n'est pas sur le formulaire, il faut éditer l'événement suite à la création pour y définir un slug, et définir un slug n'est pas trivial. Les agents préféreront ne pas avoir à gérer cela. Ou, ils utiliseront l'import, mais là aussi, définir un slug à chaque ligne reste pénible.
Je dois considérer que j'aurais des événements sans slugs, donc que {{ agendas_url }}api/agenda/{{ form_var_agenda_raw }}/bookings/{{form_var_evenement_id}}/ soit possible.
Mis à jour par Emmanuel Cazenave il y a presque 4 ans
Emmanuel Cazenave a écrit :
C'est juste pour contourner
#40719#44358
Mon commentaire dans l'idée qu'on pourrait faire en sorte qu'il y ait des slugs sur tous les évènements sans rien demander aux agents.
Mis à jour par Mikaël Ates il y a presque 4 ans
Je ne sais pas si #44358 est la bonne piste parce que je ne sais pas si le slug sera toujours un identifiant.
Si 2 événements peuvent se retrouver avec le mêmeslug
:
- C'est fait par erreur de l'agent qui a modifié ou saisie un slug déjà existant et le comportement de cet appel WS ne donnera pas le résultat attendu.
- C'est fait volontairement pour que les appels WS retournent les inscriptions à plusieurs événements.
Dans le doute, permettre ce WS sur l'id
apporte une garantie et serait opérationnel tout de suite dans la continuité de qui est fait sur les autres WS.
Mis à jour par Frédéric Péters il y a presque 4 ans
De manière générale, parce que les identifiants ne sont pas stables d'une plateforme à l'autre, dans les API on préférera vraiment les slugs. (je ne connais pas ton contexte précis).
Mis à jour par Mikaël Ates il y a presque 4 ans
L'événement est choisi dans la liste déroulante d'un formulaire de réservation. La valeur du slug
ou de l'id
n'est jamais manipulée directement. Je fais uniquement un appel utilisant form_var_event_slug
ou form_var_event_id
n'engendrant pas de problème de portabilité.
Mis à jour par Frédéric Péters il y a presque 4 ans
Ok, mais ça m'irait que l'API, ça me va que l'API, exige le slug. (et je préférerais un système avec des URL publiées, plutôt qu'avoir {{ agendas_url }}api/agenda/{{ form_var_agenda_raw }}/bookings/{{form_var_evenement_id}}/ écrit quelque part, mais mettons ça de de côté).
Et du coup, comme Emmanuel je pense, je préférerais que ça soit rendu obligatoire (et généré automatiquement sur base du libellé à la création de l'événement, et éditable ensuite derrière, et unicité par agenda, sans doute).
Mis à jour par Emmanuel Cazenave il y a presque 4 ans
- Lié à Development #44374: Sur l'appel qui renvoie la liste des évènements, renvoyer les URL qui permettent de savoir si un utilisateur est inscrit à un évènement. ajouté
Mis à jour par Emmanuel Cazenave il y a presque 4 ans
- Lié à Development #44375: Garantir la présence d'un slug sur les évènements ajouté
Mis à jour par Lauréline Guérin il y a plus de 3 ans
Les deux tickets liés ont été traités; on peut fermer celui-ci ?