fix(caldav): sérialiser les devoirs avec un composant et un statut iCalendar cohérents #11

New Issue

AntoineVe · 2026-09-09T00:07:46+02:00

AntoineVe commented

2026-09-09 00:07:46 +02:00

Constat

homework_to_vevent() crée un composant VEVENT pour chaque devoir, lui donne une plage fixe de 08:00 à 18:00 et ajoute STATUS:NEEDS-ACTION.

Or ce statut est défini pour les tâches VTODO. Pour un VEVENT, RFC 5545 ne permet que TENTATIVE, CONFIRMED ou CANCELLED. Le document produit est donc sémantiquement incohérent et peut être refusé ou corrigé de façon imprévisible par un serveur ou client CalDAV strict. Il rend également un devoir comme un créneau occupé de dix heures.

La correction ne se limite pas à la sérialisation : le synchroniseur et les tests recherchent aujourd'hui les composants gérés via walk("VEVENT").

Référence : RFC 5545, sections 3.6.1, 3.6.2 et 3.8.1.11.

Proposition

Prendre une décision de compatibilité explicite, puis l'appliquer de bout en bout :

soit représenter réellement les devoirs par des VTODO (avec DUE et STATUS:NEEDS-ACTION) et étendre la découverte, la signature, la mise à jour et la suppression aux deux types de composants ;
soit conserver des VEVENT pour maximiser la compatibilité CalDAV, mais utiliser un statut autorisé ou l'omettre, et les rendre transparents si un devoir ne doit pas bloquer l'agenda.

Prévoir une stratégie de migration pour les éléments déjà marqués X-PRONOTE-SYNC-MANAGED:v1, afin de préserver l'idempotence et de ne pas créer de doublon ni supprimer un élément utilisateur.

Critères d'acceptation

Le document iCalendar produit est conforme au type de composant retenu.
Un devoir ne devient pas un bloc « occupé » involontairement.
Le plan CalDAV, la signature et l'inventaire des éléments gérés couvrent le ou les types retenus.
Une migration depuis les anciens VEVENT de devoirs est testée (ajout, mise à jour, suppression et seconde exécution idempotente).
Des tests de sérialisation valident les valeurs autorisées et un test d'intégration utilise le comportement attendu du serveur CalDAV cible.
Le guide CalDAV explique clairement le rendu choisi côté client.

Périmètre

Synchronisation CalDAV et documentation associée ; aucun changement du contenu Pronote des devoirs.

## Constat `homework_to_vevent()` crée un composant `VEVENT` pour chaque devoir, lui donne une plage fixe de 08:00 à 18:00 et ajoute `STATUS:NEEDS-ACTION`. Or ce statut est défini pour les tâches `VTODO`. Pour un `VEVENT`, RFC 5545 ne permet que `TENTATIVE`, `CONFIRMED` ou `CANCELLED`. Le document produit est donc sémantiquement incohérent et peut être refusé ou corrigé de façon imprévisible par un serveur ou client CalDAV strict. Il rend également un devoir comme un créneau occupé de dix heures. La correction ne se limite pas à la sérialisation : le synchroniseur et les tests recherchent aujourd'hui les composants gérés via `walk("VEVENT")`. Référence : [RFC 5545, sections 3.6.1, 3.6.2 et 3.8.1.11](https://www.rfc-editor.org/rfc/rfc5545.html). ## Proposition Prendre une décision de compatibilité explicite, puis l'appliquer de bout en bout : 1. soit représenter réellement les devoirs par des `VTODO` (avec `DUE` et `STATUS:NEEDS-ACTION`) et étendre la découverte, la signature, la mise à jour et la suppression aux deux types de composants ; 2. soit conserver des `VEVENT` pour maximiser la compatibilité CalDAV, mais utiliser un statut autorisé ou l'omettre, et les rendre transparents si un devoir ne doit pas bloquer l'agenda. Prévoir une stratégie de migration pour les éléments déjà marqués `X-PRONOTE-SYNC-MANAGED:v1`, afin de préserver l'idempotence et de ne pas créer de doublon ni supprimer un élément utilisateur. ## Critères d'acceptation - Le document iCalendar produit est conforme au type de composant retenu. - Un devoir ne devient pas un bloc « occupé » involontairement. - Le plan CalDAV, la signature et l'inventaire des éléments gérés couvrent le ou les types retenus. - Une migration depuis les anciens VEVENT de devoirs est testée (ajout, mise à jour, suppression et seconde exécution idempotente). - Des tests de sérialisation valident les valeurs autorisées et un test d'intégration utilise le comportement attendu du serveur CalDAV cible. - Le guide CalDAV explique clairement le rendu choisi côté client. ## Périmètre Synchronisation CalDAV et documentation associée ; aucun changement du contenu Pronote des devoirs.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: AntoineVe/college-infos#11