8.3 KiB
26. ToDoList — nouvel écran d'accueil, urgence à trois couleurs, tri, tests (31 août 2026)
Contexte. Première étape concrète vers l'idée de commandes vocales évoquée en tout début de session (dicter une instruction à ASPIC, comme on peut le faire aujourd'hui pour un CRM du commerce ou pour déclencher un appel avec transcription automatique). Avant de s'attaquer à la dictée elle-même, mise en place d'une vraie ToDoList : nouvel écran, qui devient l'écran d'accueil après identification, à la place de la liste des contacts — celle-ci bascule dans le menu hamburger (#menu-vers-contacts), remplacée en tête de ce menu par un nouvel item vers la ToDoList (#menu-vers-todolist), ajouté symétriquement sur liste_contacts.html.
Table ASP_ToDoList — structure finale, conçue par itérations avec Jean-Marc.
CREATE TABLE `ASP_ToDoList` (
`TDL_Incr` int NOT NULL AUTO_INCREMENT,
`TDL_ToDoDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
`TDL_ToDoUser` varchar(3) NOT NULL,
`TDL_ToDoTxt` text NOT NULL,
`TDL_RealDate` timestamp NULL DEFAULT NULL,
`TDL_RealUser` varchar(3) DEFAULT NULL,
`TDL_RealText` text,
`TDL_Actif` tinyint(1) NOT NULL DEFAULT '1',
`TDL_ToDoDateSouhaitée` date DEFAULT NULL,
PRIMARY KEY (`TDL_Incr`),
KEY `TDL_Actif` (`TDL_Actif`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
TDL_ToDoDateSouhaitée (date d'échéance souhaitée, sans heure — pas de besoin exprimé pour l'instant, réévaluable plus tard) est arrivée en cours de conception : la première idée de Jean-Marc (rouge = à faire / vert = réalisé) s'est affinée en trois indicateurs une fois ce champ ajouté. Pas d'équivalent d'ASP_Realisations pour journaliser les opérations sur une tâche — jugé non nécessaire à ce stade, ASP_ToDoList porte directement son propre état (créée par/le, réalisée par/le).
Logique des trois pastilles d'urgence (calculée côté PHP, dans todolist.php) :
- Vert : tâche réalisée (
TDL_RealDaterenseignée), en retard ou pas — peu importe. - Rouge : pas encore réalisée, et soit pas de date souhaitée renseignée, soit date souhaitée dépassée.
- Orange : pas encore réalisée, date souhaitée renseignée et pas encore dépassée.
⚠️ Correction actée en cours de session : la première proposition de Claude faisait d'une tâche sans date souhaitée un cas orange par défaut. Jean-Marc a tranché à l'inverse : « si pas de date de réal précisée c'est que c'est à faire tout de suite, donc point rouge systématique tant que ce n'est pas fait ! » — une tâche sans échéance est donc la plus urgente, pas la moins.
Tri : rouge d'abord, puis orange, puis vert (TDL_Groupe 0/1/2, calculé et trié en PHP avec usort() plutôt qu'un ORDER BY/CASE SQL complexe — même préférence lisibilité déjà actée sur ce projet). À l'intérieur du groupe rouge, les tâches sans date remontent naturellement en premier (NULL trie avant toute valeur en comparaison ascendante), puis les plus anciennes déjà en retard ; le groupe orange trie par date souhaitée croissante ; le groupe vert trie par date de réalisation décroissante (la plus récente d'abord).
Nuance apportée en cours de développement — TDL_ToDoDate reste éditable. Claude avait d'abord supposé cette date de création purement générée serveur. Jean-Marc a nuancé : « je veux pouvoir noter une tâche qui serait déjà en retard et que j'avais oublié afin qu'elle m'apparaisse dans la liste » — donc TDL_ToDoDate reste un champ modifiable en création comme en édition, pour permettre l'antidatage d'une tâche découverte a posteriori. Traduit côté todolist.php : la colonne n'est incluse dans l'INSERT/l'UPDATE que si le client fournit une valeur non vide (sinon MySQL applique DEFAULT CURRENT_TIMESTAMP normalement).
Nouveaux endpoints.
todolist.php— CRUD complet. GET liste (actives, groupées/triées comme ci-dessus) et GET par id ; POST (création,TDL_ToDoUserpar défaut = utilisateur de session si vide) ; PUT (toutes les colonnes modifiables) ; DELETE = suppression logique (TDL_Actif = 0), sans commentaire obligatoire — déviation assumée par rapport àcontacts.php, faute d'équivalentASP_Realisationsà journaliser pour la ToDoList.utilisateurs.php— nouveau, GET seul, listeASP_Users(Code + Nom) pour peupler les listes déroulantes "Qui"/"Réalisée par" du panneau ToDoList. Pas d'équivalent existant à réutiliser.
Écran liste_todolist.html. Même gabarit que liste_contacts.html (bandeau, sélection, navigation clavier, menu contextuel, panneau détail à trois modes vue/édition/suppression, PgUp/PgDn sur tachesAffichees), volontairement simplifié : pas de panneau de filtre, pas de tri par en-tête cliquable, pas de sous-liste redimensionnable (rien à empiler en dessous des champs). Panneau détail : tâche en texte libre pleine largeur, puis Qui/Créée le/Réal. souhaitée/Réalisée le/Réalisée par/Comment. réal.
Bug détecté et corrigé grâce au test Playwright — hauteur de panneau non égale entre modes. L'approche retenue pour égaliser la hauteur du panneau entre vue/édition/suppression (barres hautes/basses fixées à 40px, plus simple que le mécanisme de mesure dynamique de liste_contacts.html, justifiée par l'absence de sous-liste à redistribuer) laissait un écart réel : les champs multi-lignes en lecture (.valeur-affichage.multiligne) se contractaient à leur hauteur naturelle pour un texte court, alors que les textarea d'édition correspondants gardaient une hauteur fixe (64px pour le texte de la tâche, 48px pour le commentaire de réalisation). Corrigé par deux règles min-height calées sur ces mêmes hauteurs. Après correctif, mesure Playwright : 266px dans les trois modes.
Confirmation, pas de changement : bouton de suppression déjà rouge sur liste_contacts.html. Demande de Jean-Marc de vérifier ce point — déjà en place depuis le 25 août (#panneau-detail.mode-suppression #btn-enregistrer{background:var(--rouge-suppression);}), aucune modification nécessaire.
Tests effectués avant livraison. php -l sur todolist.php/utilisateurs.php. node --check sur le JavaScript extrait des trois écrans modifiés/créés. Équilibre des balises <div> (55/55 sur liste_todolist.html, 106/106 inchangé sur liste_contacts.html). Suite fonctionnelle Playwright avec fixture de 5 tâches (2 rouges, 1 orange, 2 vertes) et API simulées : ordre/couleurs des pastilles, barre de position + navigation PgDn, égalité de hauteur des trois modes, libellés/couleur des boutons, création/édition/suppression, absence d'erreur console — tout passant.
Faux problème rencontré au déploiement, pour mémoire. Après dépôt des fichiers, Jean-Marc restait redirigé vers liste_contacts.html après connexion malgré un identification.html correctement mis à jour sur GitHub. Cause : cache navigateur sur l'ancienne version d'identification.html — confirmé par un test concluant en navigation privée, puis résolu également en navigation classique après rafraîchissement. Pas un bug du code livré ; troisième occurrence de ce type de faux positif sur ce projet (voir section 8), à garder comme premier réflexe de diagnostic avant de suspecter le déploiement lui-même.
Version applicative — V1.004. Couvre à la fois la livraison de la ToDoList et le découpage du journal en fichiers séparés sur GitHub (voir sommaire, section 00 et suivantes) — les deux chantiers ayant été poussés dans le même commit (c4356d4, "V1.004 ToDoList et Journal découpé").
Fichiers livrés le 31 août 2026 : todolist.php, utilisateurs.php, liste_todolist.html (nouveaux), identification.html (redirection post-connexion vers liste_todolist.html), liste_contacts.html (entrée "ToDoList" ajoutée en tête du menu hamburger).
Reste à faire, noté au passage : le point d'ergonomie fine resté volontairement ouvert par Jean-Marc en cours de conception (« je ne saurai décider, je vais voir à l'usage ») n'a pas de réponse tranchée à ce stade — à ajuster une fois la ToDoList réellement utilisée au quotidien. Prochaine étape annoncée par Jean-Marc en ouverture de ce chantier, non commencée : bouton micro pour la dictée vocale d'instructions, une fois la ToDoList validée à l'usage.