Projet

Général

Profil

Development #37352

possibilité de définir une durée dans la déclaration d'un évènement

Ajouté par Victor Claudet il y a plus de 4 ans. Mis à jour il y a presque 4 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
30 octobre 2019
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

C'est peut-être un peu anecdotique mais l'idée serait que cette durée soit reprise dans le format ics lié à l'évènement et que l'intégration par l'usager dans son agenda prenne donc en cours cette durée.


Fichiers

Révisions associées

Révision 854b7abc (diff)
Ajouté par Nicolas Roche il y a presque 4 ans

api: return end_datetime on booking events (#37352)

Révision daab37c0 (diff)
Ajouté par Nicolas Roche il y a presque 4 ans

manager: add duration on events (#37352)

Historique

#2

Mis à jour par Frédéric Péters il y a plus de 4 ans

  • Tracker changé de Support à Development
  • Projet changé de Publik à Chrono
  • Sujet changé de [Chrono] possibilité de définir une durée dans la déclaration d'un évènement à possibilité de définir une durée dans la déclaration d'un évènement
#5

Mis à jour par Nicolas Roche il y a presque 4 ans

  • Assigné à mis à Nicolas Roche
#6

Mis à jour par Nicolas Roche il y a presque 4 ans

J'ai ajouté un champs stat_datetime, parce que end_datetime est déjà utilisé comme propriété.
Par contre je renvoie end_datetime dans le JSON pour être cohérent avec l'API des agendas 'meetings'.
(j'ai divisé en 2 commits pour utiliser des libellés - api/management - existants appropriés)

#7

Mis à jour par Frédéric Péters il y a presque 4 ans

Le ticket demande de pouvoir préciser une durée, pas une date/heure de fin.

Faire le ticket.

#8

Mis à jour par Frédéric Péters il y a presque 4 ans

Et ensuite dans la propriété end_datetime, utiliser self.meeting_type.duration dans le cas rendez-vous et self.duration sinon, et fin.

#9

Mis à jour par Nicolas Roche il y a presque 4 ans

Testé via wcs (pas sur la réservation multiple, j'avoue) :

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Entr'ouvert//NON SGML Publik
BEGIN:VEVENT
UID:wcs.dev.publik.love-test-agenda-events-pour-export-ics-4
DTSTART;VALUE=DATE:20200602T080000
DTEND:20200602T083200                     <----------------------------------
DESCRIPTION:test agenda events pour export ICS | 130-4 | statut_2\nhttps://
 wcs.dev.publik.love/backoffice/management/test-agenda-events-pour-export-i
 cs/4/\nadmin admin
DTSTAMP:20200528T155446Z
SUMMARY:test agenda events pour export ICS - n°130-4
URL:https://wcs.dev.publik.love/backoffice/management/test-agenda-events-po
 ur-export-ics/4/
END:VEVENT
END:VCALENDAR

#10

Mis à jour par Frédéric Péters il y a presque 4 ans

Testé via wcs (pas sur la réservation multiple, j'avoue) :

Pour ne pas chercher à deviner ce qu'un bout de code signifie pour toi, tu peux expliciter, dire "ok c'est bon", "le patch m'a l'air ok mais pourtant la sortie n'est pas celle que j'attendais", etc. ?

#11

Mis à jour par Nicolas Roche il y a presque 4 ans

-> ok c'est tout bon
(mais je n'ai pas testé dans wcs la réponse json sur les réservations multiples)

#12

Mis à jour par Lauréline Guérin il y a presque 4 ans

J'aurais fait un champ nullable sans default; là dans le cas d'un event de meeting, on aura une duration à 30 minutes (default) alors que le meeting_type aura probablement une autre duration.

Est-ce que la duration est optionnelle ou required dans le cas d'un event d'events ? Je pense qu'il serait mieux de gérer ça côté form que côté model.

    @property
    def end_datetime(self):
        if self.agenda.accept_meetings():
            minutes = self.meeting_type.duration
        else:
            minutes = self.duration
        return self.start_datetime + datetime.timedelta(minutes=minutes)

meeting_type est nullable et setté uniquement pour un event de meeting; ça serait peut-être mieux de baser la condition sur self.meeting_type is not None et non sur self.agenda (ça éviterait un potentiel queryset supplémentaire)

Il n'y a pas besoin de modifier la méthode get_ics ?

        if self.event.meeting_type:
            vevent.add('dtend').value = self.event.start_datetime + datetime.timedelta(
                minutes=self.event.meeting_type.duration
            )

#13

Mis à jour par Nicolas Roche il y a presque 4 ans

  • Statut changé de Solution proposée à En cours

Il n'y a pas besoin de modifier la méthode get_ics ?

Non, il s'agit ici de l'export des demandes dans wcs sous forme de fichier ics.
https://doc-publik.entrouvert.com/admin-fonctionnel/prises-de-rendez-vous/#fichier-ics-de-la-liste-des-rendez-vous

Donc question : Est-ce que la saisie de la durée d'un évènement peut-être facultative ?
(j'imagine que oui : si la durée n'est pas fournie par certains événements, alors ils seront ignorés dans l'esport ics des demandes wcs précisant un datetime de fin : #41714)

#14

Mis à jour par Frédéric Péters il y a presque 4 ans

Oui nécessairement optionnelle. (mais je ne vois pas l'enchainement dans la réflexion qui amène de get_ics à cette question).

#15

Mis à jour par Nicolas Roche il y a presque 4 ans

Il n'y a pas besoin de modifier la méthode get_ics ?

Si en fait, j'ai mal regardé les tickets clients.
Merci de l'avoir pointé.

#17

Mis à jour par Nicolas Roche il y a presque 4 ans

Simplification des tests : 1 seul passage au lieu de 9 (pas de prise en compte les fuseaux horaires ici).

#18

Mis à jour par Lauréline Guérin il y a presque 4 ans

  • Statut changé de Solution proposée à Solution validée
#19

Mis à jour par Nicolas Roche il y a presque 4 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit 854b7abcc876f79be7cddab2146bbac9987f2b66
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Sat May 30 14:49:58 2020 +0200

    api: return end_datetime on booking events (#37352)
#20

Mis à jour par Nicolas Roche il y a presque 4 ans

commit daab37c06dca3f4038223a1a66404eb5cba9a577
Author: Nicolas ROCHE <nroche@entrouvert.com>
Date:   Thu May 28 16:37:01 2020 +0200

    manager: add duration on events (#37352)
#21

Mis à jour par Frédéric Péters il y a presque 4 ans

  • Statut changé de Résolu (à déployer) à Solution déployée

Formats disponibles : Atom PDF