Tâches

​

Objets et méthodes

​

Comportements à connaître

• Une création sans taskListIds classe la tâche dans la liste par défaut du compte, résolue avant la transaction d’écriture, donc rapide même sous charge.
• La récurrence et l’avancement suivent JSTask : les tâches récurrentes se développent par la même autorité d’occurrences que les événements d’agenda ; l’achèvement par occurrence est représentable. Une tâche porte une seule règle de récurrence, sous le même profil fermé et stockée normalisée comme celle d’un événement (récurrence) : une deuxième règle, ou une borne hors du profil, est refusée invalidProperties sur Task/set (c’était serverFail) et 403 en CalDAV, y compris un VTODO à deux lignes RRULE.
• Les alertes acceptent des déclencheurs relatifs et absolus ; une alerte absolue n’exige pas d’échéance. Le déclenchement est côté serveur, avec déduplication par occurrence. Une alerte garde acknowledged et relatedTo (les deux étaient perdus à l’écriture), Task/set valide acknowledged à la création, et le planificateur des tâches le respecte comme celui de l’agenda.
• « Plus tard », c’est Task/snoozeAlert {accountId, id, alertId, until}. Le serveur écrit le report de la RFC 8984 §4.5.2 par Task/set : l’alerte qui a sonné est acquittée, une alerte absolue enfant est ajoutée à until (un UTCDateTime futur, au plus 7 jours plus tard). Elle sonne une fois et remplace un report antérieur de la même alerte. Les erreurs et les règles sont celles d’Event/snoozeAlert.
• Un patch null efface. Un patch de mise à jour JMAP qui met une propriété à null la supprime (RFC 8620 §5.3), description et priority comprises.
• Les dépendances et le suivi du temps (dependsOn, champs de temps) sont modélisés sur l’objet tâche.
• Une tâche porte son timeZone (RFC 8984 §4.7.1). Un DUE:…Z écrit par CalDAV s’ancre en Etc/UTC au lieu de flotter, un TZID est normalisé en IANA et l’ancre de DUE prime ; le planificateur d’alertes honore l’ancre de la tâche avant la chaîne principal → organisation, si bien qu’un rappel sonne à l’instant de la tâche, pas à l’horloge murale du principal. Une ligne d’avant la colonne reste flottante, son sens historique ; l’instanciation d’un modèle aussi.
• Le partage est une seule règle. TaskListRights vaut mayReadItems, mayWriteOwn, mayWriteAll (exige mayWriteOwn), mayShare, mayDelete. TaskList/get filtre les listes qu’un lecteur d’un autre compte peut lire et calcule leur myRights par le même calcul que les boîtes et les agendas ; Task/get et Task/query sont bornés aux listes lisibles, Task/set consulte les droits par liste, et un partage ou un retrait notifie le bénéficiaire (partage).
• La corbeille est en deux temps (ADR-035) : isTrashed: true sur une mise à jour met à la corbeille, false restaure, trashedAt est posé par le serveur. Le balayage des corbeilles détruit ce qui est à la corbeille depuis plus longtemps que l’horizon du locataire, sa surcharge tasks.trash_retention_days ou à défaut [tasks] trash_retention_days (30 par défaut, plancher 1 ; une surcharge à 0 ne purge rien), par la sortie du Drive : séquestres respectés, changement Destroyed annoncé (horizons par locataire).
• Une note peut pointer vers une tâche. Une entrée de Note.links de type task garde la page d’où vient une tâche ; le lien est une référence, pas une contrainte (notes).
• L’aller-retour VTODO : les clients CalDAV voient les listes comme des collections ; les VALARM des VTODO (y compris TRIGGER;VALUE=DATE-TIME absolu) s’importent en alertes et se réémettent au GET ; les ETag sont des empreintes de contenu, donc des modifications concurrentes depuis deux protocoles entrent en conflit bruyamment (412) au lieu de s’écraser en silence. Les lignes en double des imports répétés se réparent avec oximail account dedupe-tasks (migration).