ADR 0025 – Report rapide : boutons déclarés par l'aspect, appliqués par le serveur
Accepté (2026-10-15, mode autonome)
ADR 0025 – Report rapide : boutons déclarés par l’aspect, appliqués par le serveur
Statut : Accepté (2026-10-15, mode autonome)
Ces décisions ont été prises en mode autonome, à la demande d’Aurélien du 2026-10-15 : retenir les options les plus simples, sûres et réversibles. Le cahier demande des boutons « demain », « semaine prochaine » et « un jour peut-être » sur les tâches, sans module dédié : tout passe par les aspects.
Décision
Format : clé postpone d’un aspect
postpone:
- { label: Demain, icon: today, set: { echeance: "{{today + 1d}}" } }
- { label: Semaine prochaine, icon: date_range, set: { echeance: "{{today + 1w}}" } }
- { label: Un jour peut-être, icon: snooze, set: { statut: plus-tard }, unset: [echeance] }
Chaque bouton (6 au plus) porte un label, une icon facultative et au moins un set ou un unset :
setécrit des valeurs, avec les variables{{today}}et{{now}}et un décalage± N d|w|m(ADR 0016) ;unsetretire des champs.
Le chargeur vérifie, sur le modèle des modèles de nœud :
- les champs sont connus de l’aspect ;
- aucun champ n’est une référence à un nœud ;
- un champ retiré n’est pas requis et n’est pas écrit par le même bouton ;
- les variables sont connues ;
- les valeurs résolues sont conformes au schéma de l’aspect (champs requis exceptés).
Toute faute rend l’aspect invalide.
« Un jour peut-être » est un état (plus-tard, ajouté à l’aspect tache et à son workflow), pas une date lointaine. Une tâche « plus tard » sort ainsi des vues « à faire » sans perdre son état d’origine dans l’historique. Le choix vit dans config/ : un autre aspect pourrait reporter autrement.
Application : POST /api/nodes/{id}/aspects/{aspect}/postpone/{index}?zone=
Le serveur :
- résout les variables dans le fuseau du navigateur (
zone, mêmes contrôles et messages qu’ailleurs, regroupés dansZones.of) ; - fusionne
setdans les données de l’aspect porté ; - retire
unset; - enregistre par
putAspect.
Une seule écriture applique donc tout ce que fait une modification d’aspect : JSON Schema, workflow (ADR 0023), événement aspect.updated avec l’avant/après, texte de recherche. Un bouton inconnu, ou un aspect non porté, renvoie 404. Une transition interdite renvoie 400 (aspects.tache.statut), sans écriture.
Le calcul est fait côté serveur, et non dans le navigateur avant un PUT :
- une seule écriture atomique ;
- les variables sont résolues par le même code que pour les modèles ;
- les futures vues (kanban, liste, revue hebdomadaire) appelleront le même endpoint.
Fiche
Les boutons s’affichent à droite de l’intertitre de l’aspect, seulement s’il est déjà enregistré. Un clic écrit immédiatement, puis recharge le nœud. Il est refusé quand la page a des modifications non enregistrées (« Enregistrez d’abord vos modifications »), comme le changement de type : le rechargement les écraserait.
Alternatives écartées
- Clé
actionsdu jalon 3 : son format (handlers, conditions) n’est pas arrêté. Le report n’est qu’une écriture de champs, et une clé dédiée évite de figeractionstrop tôt. - « Un jour peut-être » = échéance retirée seule : la tâche resterait « à faire » sans date, mélangée à celles qu’on a oublié de dater.
Conséquences
- L’aspect
tachegagne l’étatplus-tard, avec ses transitions (depuis et versa-faireeten-cours, versfaitetabandonne). Depuisfaitouabandonne, « Un jour peut-être » est refusé : il faut d’abord rouvrir la tâche. - Les vues du jalon 2 réutiliseront ces boutons (menu d’une ligne, carte de kanban).
- La fusion de
setest faite au premier niveau : un objet imbriqué est remplacé en entier. - Le report réécrit l’aspect entier : une donnée ancienne non conforme sur un autre champ le fait échouer en 400 sur ce champ, comme une modification ordinaire (valider à l’écriture).
- Dans la fiche, un bouton dont
setécrit le champ du workflow est désactivé quand la transition depuis l’état enregistré est interdite (« Un jour peut-être » sur une tâche faite). Le serveur refuse de toute façon. - Limite assumée : « Demain » ou « Semaine prochaine » sur une tâche
plus-tard(ou faite) la date, sans changer son état. Elle reste hors des vues « à faire » tant qu’on ne la repasse pas à la main ena-faire. Une condition déclarative (when) sur les boutons relèvera des règles du jalon 3.
Amendement (2026-10-16, ADR 0041)
La clé postpone devient quickActions (actions rapides de tout aspect, avec une condition when). L’ancien nom reste lu, et l’endpoint …/postpone/{index} reste en service, marqué obsolète, à côté de …/actions/{index}.