Produits Entr'ouvert » Chrono

Mon cas d'usage : mon association réserve la salle de mini-foot tous les lundis soirs, je veux pouvoir le faire avec une seule demande en indiquant un créneau et une durée de répétition (ou avoir un an par défaut comme durée de répétition, genre)

Je ne sais pas si mon cas se prête à ce ticket.

Cas d'usage : Cours de langue.

Je veux gérer les inscriptions à l'événement "Cours d'Anglais tous les lundi de 14h30 à 16h à partir du 13 avril jusqu'au 6 juillet".

Je crée aujourd'hui un unique événement avec pour date le 13 avril.

J'ai dans mon WF un statut inscriptions du jour qui permet de voir toutes les personnes en activité aujourd'hui dans la vue de listing tous événements confondus. Ceci ne fonctionne donc que pour la première séance.

Le pointage des présences à chaque séance n'est pas non plus possible.

J'ai envisagé de créer un événement par cours mais cela demande de créer tous ces événements. Ils vont ensuite tous apparaître dans la liste des activités alors que je ne souhaiterais afficher qu'une entrée. La gestion avec une demande d'inscription à un de ces événements qui générerait autant de demandes d'inscription paraît complexe et ce sera inapproprié pour pointer un unique paiement. Avoir une unique demande semble donc plutôt à privilégier mais l'affichage inscription du jour ou le pointage resterait difficile.

Je ne sais pas si la gestion de la récurrence pourrait apporter des solutions à ce cas d'usage.

J'ai envisagé de créer un événement par cours mais cela demande de créer tous ces événements.

Ce ticket est pour éviter ça, qu'il y ait un événement créé, duquel découle automatiquement les autres.

Par contre, tu sembles dans la suite dire que les inscriptions sont "mutualisées", ce ticket concernait dans l'idée des événements indépendants (l'usager ne s'inscrit pas à tous les cinéclubs), mais ce serait une suite possible.

Mais pour contre balancer mon commentaire précédent sur le fait ne pas exposer la notion d'exception, il la demande qui me semble arriver gros comme une maison : j'ai supprimé le lundi 5 octobre parce que le gymnase devait être repeint mais finalement ça n'a pas lieu, comment je fais pour remettre le 5 octobre dans la série ?

Emmanuel Cazenave a écrit :

Mais pour contre balancer mon commentaire précédent sur le fait ne pas exposer la notion d'exception, il la demande qui me semble arriver gros comme une maison : j'ai supprimé le lundi 5 octobre parce que le gymnase devait être repeint mais finalement ça n'a pas lieu, comment je fais pour remettre le 5 octobre dans la série ?

Un bouton « désactiver » plutôt que « supprimer » ?

Publik Famille
Les temps d'accueils (= événements) d'une activité doivent être créés par lots avec une récurrence :
toutes les semaines, une fois tous les 15 jours, les 2ème et 4ème jeudis d'un mois = la période est variable
Cas d'usage : générer en une fois l'ensemble des temps repas de la restauration scolaire (les L-M-J-V) pour l'année scolaire.
Cas d'usage : générer les séances de Yoga du mardi soir une fois tous les 15 jours (S1 et S3 du mois) et du jeudi (S2 et S4).

Cas d'usage : générer les séances de Yoga du mardi soir une fois tous les 15 jours (S1 et S3 du mois) et du jeudi (S2 et S4).

Ok, pour toi tous les 15 jours c'est deux fois par mois; pour moi c'était "une semaine sur deux". (la différence se fait sur les mois qui voient parfois 5× le même jour de semaine, le "une semaine sur deux" demande de définir une date de départ). Est-ce que le "une semaine sur deux" est une récurrence à avoir ?

• Un évènement définit comme récurrent est l'évènement « parent » d'évènements « fils ». Les évènements fils héritent du paramétrage du parent (label, places, durée...).
• L'évènement parent est visible dans le paramétrage, les évènements fils sont exposés à la réservation et dans la vue mensuelle.
• Au moment de la création d'un évènement récurrent, aucun évènement fils n'est créé. Il y a une méthode qui permet d'obtenir à la volée la liste des évènements fils entre deux bornes temporelles, pour les exposer dans /datetimes/ et la vue mensuelle.
• Un évènements fils est créé en base la première fois qu'on tente de le réserver ou d'y accéder dans le manager (pour genre l'annuler, j'imagine).

Ça m'a l'air de bien fonctionner et ça ne modifie pas de code existant (juste des ajouts).

À noter que ce que je décris là s'applique aux évènements « cinéclub tous les lundis ». La structure pour un évènement famille à inscription récurrente sera la même mais avec une logique différente, en cela qu'il faudra montrer l'évènement parent dans /datetimes/ et y rattacher les réservations, les évènements fils serviront juste au pointage etc.

Pour info, version presque bien sur la branche avec une bonne partie des tests. Il reste à en écrire quelques uns pour tout couvrir, et à ajouter l'import/export.

Niveau spec RRULE je me contente d'utiliser dateutil.

Niveau interface, je propose un bête select avec des options courantes. Il y aurait ensuite à développer une vue « avancée » de paramétrage de la récurrence, j'imagine qu'il faudra pas mal de JS pour avoir quelque chose d'utilisable.

• Paramétrage de la durée de répétition (date de début et de fin)
• Permettre les exceptions (avoir les jours fériés automatiques ce serait pas mal)
• Permettre une inscription récurrente pour la famille
• Regarder si il y a quelque chose à faire au niveau de l'import des ICS

(premier round léger, suite plus tard).

0002¶

Dans chrono/agendas/models.py ça aurait pu être plus minimaliste en si le nom des nouveaux paramètres min_start et max_start ne reprenait pas des noms de variables interne à la fonction, là du coup ça fait un patch avec des lignes liées à ce renommage et ça obscurcit un peu l'essentiel je trouve.

L'utilisation de prefetched_queryset=True conjointement avec annotate_queryset=True provoquerait une erreur, je lèverai une erreur explicite dans ce cas avant que ça crash salement (genre un assert).

0004¶

Pas compris ce qui suit, quid d'un évènement récurrent dont la première occurrence a lieu dans un mois avec date de publication dans 15 jours ?

def in_bookable_period(self):
    if self.recurrence_rule is not None:
        return True

Dans 0002, pourquoi tu changes le .exists() en bool(qs) ? C'est dommage de faire un select de plusieurs lignes quand un LIMIT 1 peut suffire, non ?

Lauréline Guerin a écrit :

bool(qs)

Parce que précisément ce n'est plus un queryset à partir du patch d'après. Ça serait possible de construire un has_open_events qui ne travaille qu'avec un queryset même une fois que les évènements récurrents entrent dans la danse, mais c'est un peu de boulot et ça peut être fait dans un ticket annexe si nécessaire je pense.

Question, si on crée un événement avec une récurrence, et qu'une réservation se fait sur une date future de la récurrence. Si la récurrence est éditée (c'est éditable ?), et modifiée, en faisant en sorte que l'event fils réservé ne rentre plus dans la récurrence (genre on passe de tous les lundi à tous les mardis), ça a quel impact ?

Lauréline Guerin a écrit :

Si la récurrence est éditée (c'est éditable ?)

Nop, pas quand une réservation est posée, c'est 0005. Et fonctionnellement je pense que c'est gérable ainsi : l'agent qui se retrouve dans ce cas ira annuler manuellement les évènements qui ont des réservations, ce qui notifiera proprement les usagers, et ensuite la modif est permise. Si le besoin c'est de garder ces évènements ça sera plus compliqué mais gérable, à coup d'exceptions bien choisies j'imagine.
Le truc améliorable dans l'histoire c'est qu'une modif qui simplement ajouterait des récurrences devrait être permise (mais pas capital non plus, souvent ça sera gérable en créant un deuxième évènement).

Je réfléchis tout haut façon pavé dans la marre : j'ai l'impression que le choix de ne pas persister en DB les évènements futurs issus de la récurrence tant qu'aucune réservation n'est posée dessus amène son lot de problèmes.

- "Il faut avoir en tête que les évènements récurrents (self.recurrence_rule is not None) ne sont visibles que dans la page de paramétrage" : j'ai peur qu'on perde un peu les gens (à commencer par nous mêmes). J'imagine que ce choix d'interface est lié à l'absence de persistance.

- des questions pour marquer des évènements comme finalement non ouverts : ce qui amène #50561 avec aussi son lot de question. Là aussi j'ai l'impression qu'on en arrive à imaginer gérer les choses avec des exceptions parce qu'on a pas de persistance, tandis que si on en avait on retomberait sur les cas classique "si un évènement existe je peux le supprimer etc"

- si demain on veut pouvoir répondre à des demandes du types : "le ciné club du 11 janvier, exceptionnellement il commence à 15h00 au lieu de 18 heures", là aussi sans persistance ça s'annonce compliqué

Bref j'ai l'impression qu'il y a plus d'avenir à demander une date limite lors de la création de la récurrence et à créer les évènements. Et qu'ensuite petit à petit on pourra ajouter des fonctionnalités dans l'interface sur modification de toute la série/modification d'une occurrence particulière.

+1, j'ai aussi l'impression qu'imposer une date de fin (max 1 an ?) à un événement récurrent et tout créer permettra plus de souplesse, notamment sur l'édition d'un des événements: on pourra proposer de modifier seulement celui-ci, tous (mais pas les passés ?), ou les à venir, un peu comme dans google calendar.
Et plus besoin de gérer les exceptions.

Emmanuel Cazenave a écrit :

Je réfléchis tout haut façon pavé dans la marre : j'ai l'impression que le choix de ne pas persister en DB les évènements futurs issus de la récurrence tant qu'aucune réservation n'est posée dessus amène son lot de problèmes.

C'est certes plus compliqué, mais à mon avis aucune appli d'agenda n'impose une date de fin de récurrence. Et j'imagine que c'est pas le genre de limitation facile à lever une fois qu'elle existe, d'où l'idée de ne pas se l'autoriser.

- "Il faut avoir en tête que les évènements récurrents (self.recurrence_rule is not None) ne sont visibles que dans la page de paramétrage" : j'ai peur qu'on perde un peu les gens (à commencer par nous mêmes). J'imagine que ce choix d'interface est lié à l'absence de persistance.

Du tout, la persistance ne change rien à ce niveau là.
Un évènement tous les jours pendant un an -> on ne va certainement pas afficher 365 évènements sur cette page de paramétrage, le bon choix est bien entendu d'afficher seulement un évènement avec le libellé « une fois tous les jours pendant 1 an », ce qui est fait ici.

- des questions pour marquer des évènements comme finalement non ouverts : ce qui amène #50561 avec aussi son lot de question. Là aussi j'ai l'impression qu'on en arrive à imaginer gérer les choses avec des exceptions parce qu'on a pas de persistance, tandis que si on en avait on retomberait sur les cas classique "si un évènement existe je peux le supprimer etc"

Lecture trop rapide ici aussi, j'ai répondu à ta question #50561#note-9.

- si demain on veut pouvoir répondre à des demandes du types : "le ciné club du 11 janvier, exceptionnellement il commence à 15h00 au lieu de 18 heures", là aussi sans persistance ça s'annonce compliqué

Eh non, pareil ça fonctionne déjà de manière transparente, même mécanisme que pour l'annulation.

Lauréline Guerin a écrit :

+1, j'ai aussi l'impression qu'imposer une date de fin (max 1 an ?) à un événement récurrent et tout créer permettra plus de souplesse, notamment sur l'édition d'un des événements: on pourra proposer de modifier seulement celui-ci, tous (mais pas les passés ?)

Marche déjà, comme dit plus haut, à expliciter par un travail de documentation (et tout à fait à peaufiner dans la suite).

Et plus besoin de gérer les exceptions.

On ne s'en sortira pas sans gérer les exceptions, ça ne va pas d'imaginer qu'on va faire plusieurs centaines de clics sur un agenda pour virer les vacances scolaires, ce à chaque fois qu'on ajoute un évènement récurrent.

Conclusion, je veux bien détricoter mais pour l'instant je ne vois pas d'argument valable en ce sens. Il me semble aussi qu'une bonne partie de ces discussions aurait pu être évitées en essayant la fonctionnalité pour de vrai avant de lire le code, peut-être qu'il faut que j'attache mes formulaires et workflow de test pour rendre ça plus accessible ?

Valentin Deniaud a écrit :

Emmanuel Cazenave a écrit :

- si demain on veut pouvoir répondre à des demandes du types : "le ciné club du 11 janvier, exceptionnellement il commence à 15h00 au lieu de 18 heures", là aussi sans persistance ça s'annonce compliqué

Eh non, pareil ça fonctionne déjà de manière transparente, même mécanisme que pour l'annulation.

Je viens d'essayer et non ça ne marche pas, en fait actuellement le bouton « Options » est masqué sur les récurrences, la seule action supportée est l'annulation. Mon plan c'était d'avoir ensuite un ticket pour démasquer ce bouton et en même temps vérifier que les modifications à cet endroit marchent as expected, genre celle de l'heure (et je ne vois rien de bloquant à ce que ça fonctionne).

c'est normal que les urls d'api changent après qu'on ait accédé à une occurence ? j'imagine que c'est dû au stockage en DB ?

exemple, l'api datetimes me renvoie:

        {
            "api": {
                "bookings_url": "https://chrono.dev.publik.love/api/agenda/41663-events-recurrents/bookings/41663-events-recurrents-event:2021-03-29-1000/",
                "fillslot_url": "https://chrono.dev.publik.love/api/agenda/41663-events-recurrents/fillslot/41663-events-recurrents-event:2021-03-29-1000/",
                "status_url": "https://chrono.dev.publik.love/api/agenda/41663-events-recurrents/status/41663-events-recurrents-event:2021-03-29-1000/" 
            },
            "datetime": "2021-03-29 10:00:00",
            "description": "",
            "disabled": false,
            "id": "41663-events-recurrents-event:2021-03-29-1000",
            "places": {
                "available": 10,
                "full": false,
                "has_waiting_list": false,
                "reserved": 0,
                "total": 10
            },
            "pricing": null,
            "slug": "41663-events-recurrents-event:2021-03-29-1000",
            "text": "event 1 lundi (29 mars 2021 10:00)",
            "url": null
        },

je fais un call:

% http GET https://chrono.dev.publik.love/api/agenda/41663-events-recurrents/status/41663-events-recurrents-event:2021-03-29-1000/              [0]
HTTP/1.1 200 OK
Allow: GET, HEAD, OPTIONS
Connection: keep-alive
Content-Length: 763
Content-Type: application/json
Date: Fri, 05 Feb 2021 10:08:16 GMT
Server: nginx/1.18.0
X-Frame-Options: SAMEORIGIN

{
    "api": {
        "bookings_url": "https://chrono.dev.publik.love/api/agenda/41663-events-recurrents/bookings/41663-events-recurrents-event-2021-03-29-1000/",
        "fillslot_url": "https://chrono.dev.publik.love/api/agenda/41663-events-recurrents/fillslot/41663-events-recurrents-event-2021-03-29-1000/",
        "status_url": "https://chrono.dev.publik.love/api/agenda/41663-events-recurrents/status/41663-events-recurrents-event-2021-03-29-1000/" 
    },
    "datetime": "2021-03-29 10:00:00",
    "description": "",
    "disabled": false,
    "err": 0,
    "id": "41663-events-recurrents-event-2021-03-29-1000",
    "places": {
        "available": 10,
        "full": false,
        "has_waiting_list": false,
        "reserved": 0,
        "total": 10
    },
    "pricing": null,
    "slug": "41663-events-recurrents-event-2021-03-29-1000",
    "text": "event 1 lundi (29 mars 2021 10:00)",
    "url": null
}

un call à https://chrono.dev.publik.love/api/agenda/41663-events-recurrents/status/41663-events-recurrents-event-2021-03-29-1000/ donne le même résultat

Lauréline Guerin a écrit :

- quand on crée un event on peut définir une date de publication; quel effet a-t-elle sur un event récurrent ? quel effet veut-on que cette date de publication ait ?

Je ne sais pas, je trouve que ça fait un peu doublon avec la date de début de récurrence mais il y a sûrement des cas d'usages que je n'ai pas en tête.

une occurrence avant la date de publication remonte dans l'api datetimes, sans qu'elle soit notée disabled, mais elle n'est pas réservable (échec au post sur fillslot, "event not bookable"

OK j'essaye de corriger ça, il doit manquer un bout de filter quelque part pour ne pas qu'elle remonte dans datetimes.

- j'ai supprimé une occurrence d'un event récurrent défini tous les lundi (ici, celui du 1er mars); il apparaît toujours dans la liste des events du mois de mars, et ouvert à la résa. j'ai aussi réussi à le réserver.

Effectivement, à régler au niveau de l'interface, il ne faut pas autoriser la suppression de ces évènements, tout doit passer par l'annulation.

c'est normal que les urls d'api changent après qu'on ait accédé à une occurence ? j'imagine que c'est dû au stockage en DB ?

Ouep et c'est bien couvert par les tests, mais rétrospectivement je ne suis pas super convaincu de cette manière de faire : c'était par mimétisme avec le retour de /datetimes/ pour les rendez-vous, et comme « : » n'est pas un caractère valide pour un slug (même si en vrai ça passe), je le remplace par « - » à la sauvegarde. Peut-être plutôt utiliser genre « -- » comme séparateur, caractère valide pour un slug et slug.rsplit('--') donnerait les deux composantes de manière sûre.

Valentin Deniaud a écrit :

Lauréline Guerin a écrit :

c'est normal que les urls d'api changent après qu'on ait accédé à une occurence ? j'imagine que c'est dû au stockage en DB ?

Ouep et c'est bien couvert par les tests, mais rétrospectivement je ne suis pas super convaincu de cette manière de faire : c'était par mimétisme avec le retour de /datetimes/ pour les rendez-vous, et comme « : » n'est pas un caractère valide pour un slug (même si en vrai ça passe), je le remplace par « - » à la sauvegarde. Peut-être plutôt utiliser genre « -- » comme séparateur, caractère valide pour un slug et slug.rsplit('--') donnerait les deux composantes de manière sûre.

Bon à relire le code non, c'est quand même bien utile de pouvoir différencier les évènements à créer (caractère ':' dans le slug) des autres.

Autres remarques appliquées, il faudra affiner plus tard ce qu'on veut faire de la date de publication, affichage et tout.

Valentin Deniaud a écrit :

Ouep et c'est bien couvert par les tests, mais rétrospectivement je ne suis pas super convaincu de cette manière de faire [...]

(en fait en tapant ça je me suis juste emmêlé les pinceaux avec une idée qui m'est venue en parallèle : ce qui est pas top c'est d'au final faire slug.replace(':', '-') au moment de save, parce qu'on se retrouve avec un slug du type my-event-2021-01-26-1305
et que si un jour on veut séparer texte et datetime c'est pas rigolo, et donc ce serait mieux d'avoir slug.replace(':', '--') qui permet de séparer avec un rsplit bien senti. Il y aurait plein de tests à modifier mais je vais sûrement le faire, sans incidence sur le reste de toute façon.)

Valentin Deniaud a écrit :

je vais sûrement le faire

Fait et c'est tout bon, relecture can go on.