Produits Entr'ouvert » Chrono

Il faut peut-être faire un pas en arrière ici : le besoin c'est d'afficher les réservations d'un usager, c'est à dire le statut présence/absence pour chaque évènement réservé.

Pour cela tu utilises /agendas/datetimes/ en spécifiant les agendas qui t'intéressent et tu filtres les évènements pour lesquels l'usager a une réservation. Ça a des airs de contournement parce que cette API est quand même là pour lister les évènements réservables pour un usager donné. D'ailleurs dans ton mail tu demandes à ce qu'à terme on puisse n'inclure que les évènements réservés...

Est-ce que ça ne conviendrait pas plutôt d'inclure le détail de l'évènement réservé dans /api/bookings/?user_external_id=xxx ?

Pour l'instant ça retourne genre :

{
    'err': 0,
    'data' : [
        {
            'id': 3,
            'in_waiting_list': False,
            'user_was_present': True,
            'user_absence_reason': '',
            'extra_data': None,
        },
    ]
}

Et le patch ici pourrait juste être d'ajouter une clé « event » contenant les mêmes détails sur l'évènement que lors d'un appel à /datetimes/. Il faudrait également faire attention au tri.

Il te manquera le filtrage sur plusieurs agendas (je crois), soit on l'ajoute soit tu as moyen de regrouper ces agendas sous une même catégorie, et alors ça marche déjà.

C'est tout à fait cela.

Comme tu l'indiques j'ai besoin de pouvoir filtrer pour n'afficher que les bookings sur les événements récurrents, ce qui est couvert car ils sont dans des agendas dédiés dans une unique catégorie.

Ce qui serait utile c'est de pouvoir filtrer sur une plage de date. Cela afin par exemple de ne présenter que les booking passés ou futurs.

Les bookings seraient triés/triables par date de l'occurrence.

Comme tu l'indiques le contenu serait enrichi de :

• l'information de pointage :
  • peut-être une clé check,
  • contenant le statut de pointage, la raison s'il y en a une,
• la description de l'occurrence pointé par le booking avec la clé event (contenu plus ou moins riche selon si c'est un événement simple ou une occurrence d'un événement récurrent).

(On peut renommer le ticket plutôt qu'en créer un nouveau si ça te va.)

Mikaël Ates a écrit :

Ce qui serait utile c'est de pouvoir filtrer sur une plage de date. Cela afin par exemple de ne présenter que les booking passés ou futurs.

Déjà couvert aussi, https://doc-publik.entrouvert.com/dev/api-agendas/chrono-bookings/#Obtenir-la-liste-des-r%C3%A9servations-dun-utilisateur.

Les bookings seraient triés/triables par date de l'occurrence.

Yep, à voir où l'API est utilisée actuellement et si changer l'ordre par défaut peut poser problème.

Comme tu l'indiques le contenu serait enrichi de :

• l'information de pointage :
  • peut-être une clé check,
  • contenant le statut de pointage, la raison s'il y en a une,

Oui ça y est déjà, cf la doc, le but c'est de ne pas toucher.

• la description de l'occurrence pointé par le booking avec la clé event (contenu plus ou moins riche selon si c'est un événement simple ou une occurrence d'un événement récurrent).

Ce point c'est le vrai (petit) travail à faire.

(contenu plus ou moins riche selon si c'est un événement simple ou une occurrence d'un événement récurrent)

Il n'y aura pas de différence de contenu, une occurrence d'un évènement récurrent est un évènement simple (seule différence, la date ajoutée entre parenthèses après le nom de l'évènement dans la clé 'text').

(On peut renommer le ticket plutôt qu'en créer un nouveau si ça te va.)

On a déjà bien blablaté, ça pourrait être plus clair pour les relecteurices si il y avait un nouveau ticket.

J'y pense, truc peut-être à ajouter également, pouvoir filtrer les réservations sur liste principale ? (ajout du paramètre in_?waiting_list=false)

(contenu plus ou moins riche selon si c'est un événement simple ou une occurrence d'un événement récurrent)

Il n'y aura pas de différence de contenu, une occurrence d'un évènement récurrent est un évènement simple (seule différence, la date ajoutée entre parenthèses après le nom de l'évènement dans la clé 'text').

Il me semble que pour l'occurrence d'un récurrent on pourrait souhaiter en plus le slug de l'événement récurrent.

(On peut renommer le ticket plutôt qu'en créer un nouveau si ça te va.)

On a déjà bien blablaté, ça pourrait être plus clair pour les relecteurices si il y avait un nouveau ticket.

Je te laisse le faire après ce commentaire.

J'y pense, truc peut-être à ajouter également, pouvoir filtrer les réservations sur liste principale ? (ajout du paramètre in_?waiting_list=false)

Oui ce sera utile et ce pourrait être un autre ticket.

Mikaël Ates a écrit :

Ok. Avec #60021 et #60022, il a été ajouté à datetimes le nom de l'agenda agenda_label et l'URL backoffice de gestion de l'événement api.backoffice_url. Ce bien le cas ici aussi ?

Oui tout à fait.