ADR 0068 – Sections dans un projet

Statut : Accepté (2026-10-16, mode autonome ; idée « Sections dans un projet » de la vague 4 du document d’idées, assignée par le fil coordinateur)

Le document d’idées propose de regrouper les tâches d’un projet en sections (« phase »), comme les sections de Todoist ou de Things : « Devis », « Travaux », « Finitions ». Aujourd’hui, la section « Tâches du projet » de la fiche (vue contextuelle taches-du-projet, ADR 0036) les liste toutes à la suite.

Deux contraintes :

• Les sections ne se connaissent pas d’avance. Chaque projet a les siennes. Une énumération fermée (phase: [preparation, realisation, finition]) ne convient qu’à un seul genre de projet.
• Le moteur ne connaît pas les tâches. La solution doit rester une capacité générique des vues, et le domaine doit rester dans config/.

Décision

Les vues regroupent aussi par un champ texte

display.groupBy admettait un champ à valeurs fermées (énumération, type, booléen) ou une date, regroupée par jour (ADR 0038). Il admet désormais un champ texte d’aspect, hors kanban, pour les modes table et liste :

• Groupes. Chaque valeur présente dans les résultats forme un groupe. Les groupes sont triés par ordre alphabétique (français : accents et casse ignorés), et le groupe sans valeur vient en dernier (« Sans valeur »).
• Valeurs. Elles sont prises telles qu’écrites, sans les espaces de début et de fin. « Travaux » et « travaux » font donc deux groupes : le formulaire de la tâche propose les sections existantes (voir plus bas) pour éviter les doublons.
• Pas de modification par glisser-déposer. Contrairement à une énumération, le groupe n’est pas « éditable » (groupEditable: false) : la section se change dans la fiche de la tâche.
• Restrictions. Le kanban et les couloirs (swimlaneBy) gardent des valeurs fermées, car leurs colonnes doivent exister même vides.

ViewResult.groupKind vaut alors TEXT. groups porte les valeurs trouvées, dans l’ordre d’affichage.

Dans la configuration d’exemple

• L’aspect tache gagne un champ texte facultatif section (« Section », 80 caractères au plus).
• La vue contextuelle taches-du-projet le prend comme regroupement : sur la fiche d’un projet, les tâches s’affichent par section, et celles sans section à la fin.
• Les vues contextuelles du panneau de contexte appliquent désormais le regroupement de leur YAML. Avant, il était ignoré dans le panneau.

Saisie de la section

Dans la fiche d’une tâche, le champ « Section » propose, en saisissant, les sections déjà utilisées (liste de suggestions du navigateur, datalist), les plus fréquentes d’abord. Il reste libre : une nouvelle valeur crée une nouvelle section.

• Mécanisme générique. Une propriété de schéma x-suggest: true, admise seulement sur un champ texte libre (sans enum ni format), donne un champ de formulaire à suggestions.
• Endpoint. Les valeurs viennent de GET /api/field-values?aspect=&field=&q= : valeurs distinctes hors corbeille, filtrées sur le début, accents et casse ignorés. Il n’accepte qu’un champ qui déclare x-suggest.
• Portée. Les suggestions couvrent toutes les tâches, pas seulement celles du projet : les mêmes noms de sections reviennent d’un projet à l’autre (« Devis », « Travaux »). Les restreindre au projet reste possible plus tard.

Reporté

• Ordre manuel des sections, au lieu de l’ordre alphabétique.
• Renommer une section pour toutes ses tâches d’un coup (aujourd’hui : action en lot « Modifier un champ » à venir, ou tâche par tâche).
• Glisser une tâche d’une section à l’autre.

Conséquences

• Toute vue peut regrouper par un champ texte : par expéditeur d’un courrier, par émetteur d’un document…
• Les tâches sans projet peuvent aussi avoir une section ; elle n’apparaît que dans les vues qui regroupent par ce champ.