From b8293b3971cf1dfb9bc1184fc3c0885812f1d562 Mon Sep 17 00:00:00 2001 From: root Date: Sun, 23 Aug 2026 11:41:34 +0000 Subject: [PATCH] docs(planning): requalify phase 2.1 UI prerequisites --- docs/ui-audit/BUGS.md | 12 +++ docs/ui-audit/CREATED_TEST_DATA.md | 8 ++ docs/ui-audit/IMPLEMENTATION_PHASE21.md | 5 + docs/ui-audit/PHASE21_REQUALIFICATION.md | 126 +++++++++++++++++++++++ docs/ui-audit/PROGRESS.md | 8 ++ docs/ui-audit/UX_PROPOSALS.md | 8 ++ 6 files changed, 167 insertions(+) create mode 100644 docs/ui-audit/PHASE21_REQUALIFICATION.md diff --git a/docs/ui-audit/BUGS.md b/docs/ui-audit/BUGS.md index b21cb67..ea18e86 100644 --- a/docs/ui-audit/BUGS.md +++ b/docs/ui-audit/BUGS.md @@ -1,5 +1,17 @@ # Bugs et anomalies +## Phase 2.1 — validation fonctionnelle (P1) + +- Les scénarios précédents ne constituaient pas une preuve UI : les lots et + équipements `TEST_UI_PHASE21_*` n'étaient pas présents dans la copie VM + contrôlée et avaient été préparés directement en base/fixtures. +- Avant correction, la page des horaires ne permettait pas de choisir un + technicien et `PlanningService` pouvait réutiliser la plage d'un autre + utilisateur. La sélection et le filtrage sont maintenant corrigés ; le + parcours doit être revalidé manuellement. +- La création d'un lot démarre depuis l'assistant équipement ; il n'existe + pas encore de formulaire autonome `/lots/new`. + ## UI-001 — Transvasement inaccessible - Priorité : P1 diff --git a/docs/ui-audit/CREATED_TEST_DATA.md b/docs/ui-audit/CREATED_TEST_DATA.md index ddea1a1..821a3dc 100644 --- a/docs/ui-audit/CREATED_TEST_DATA.md +++ b/docs/ui-audit/CREATED_TEST_DATA.md @@ -1,5 +1,13 @@ # Données TEST_UI_* laissées sur l'instance +## Rectificatif Phase 2.1 + +Les données `TEST_UI_PHASE21_*` historiques ont été créées par scripts, +SQLAlchemy direct et fixtures de tests afin de valider le moteur. Elles ne +doivent pas être comptées comme créées par un utilisateur dans l'interface. +La copie VM contrôlée ne contenait notamment aucun lot ni équipement marqué +Phase 2.1. Elles sont conservées volontairement. + Le nettoyage final est volontairement interdit. Les objets suivants sont laissés pour inspection manuelle. diff --git a/docs/ui-audit/IMPLEMENTATION_PHASE21.md b/docs/ui-audit/IMPLEMENTATION_PHASE21.md index 43abf9f..04fd162 100644 --- a/docs/ui-audit/IMPLEMENTATION_PHASE21.md +++ b/docs/ui-audit/IMPLEMENTATION_PHASE21.md @@ -1,5 +1,10 @@ # Implémentation Phase 2.1 — validation métier de Ma journée +> **Rectificatif de requalification (2026-08-23)** : les jeux +> `TEST_UI_PHASE21_*` ont été préparés par fixtures/SQLAlchemy/script pour +> tester le moteur. Ils ne prouvent pas un parcours administrateur réalisé +> dans l'interface. Voir `PHASE21_REQUALIFICATION.md`. + ## Baseline - Version avant : `0.1.0-dev.7` diff --git a/docs/ui-audit/PHASE21_REQUALIFICATION.md b/docs/ui-audit/PHASE21_REQUALIFICATION.md new file mode 100644 index 0000000..d973f1e --- /dev/null +++ b/docs/ui-audit/PHASE21_REQUALIFICATION.md @@ -0,0 +1,126 @@ +# Requalification Phase 2.1 — prérequis métier et interface + +Date : 2026-08-23 +Version auditée : 0.1.0-dev.8 + +## Conclusion + +La validation précédente est requalifiée **PARTIELLEMENT VALIDÉE**. Les +services de planification sont testés, mais le scénario préventif annoncé +n'était pas reproductible par un administrateur depuis l'interface : les +données `TEST_UI_PHASE21_*` persistées dans la copie VM ont été préparées par +SQLAlchemy/script (et les tests utilisent des fixtures). Aucun lot ni +équipement marqué Phase 2.1 n'était présent dans la base contrôlée. Une +fixture passante ne constitue donc pas une validation du parcours utilisateur. + +## Audit des données Phase 2.1 + +| Donnée | Mode constaté | Parcours UI identifié | Validation métier | +|---|---|---|---| +| `TEST_UI_PHASE21_TECH` et horaires | SQLAlchemy/script puis fixtures | `/planning/time` existait pour l'utilisateur courant | Partielle | +| salles et occupations | script/fixtures | planning des salles | Partielle | +| tâches planifiées, urgence, entreprise | script/fixtures | routes normales disponibles | Partielle | +| lot, tâche de lot, équipements | aucune donnée marqueur dans la copie VM | assistant équipement + détail du lot + `/lots//tasks/new` | Non validée | + +Le précédent rapport doit être lu comme une validation technique du moteur, et +non comme une preuve de configuration UI. La cause est méthodologique : le +scénario a été construit directement en base pour tester l'algorithme avant de +vérifier chaque écran de configuration. + +## Horaires par technicien + +`WorkSchedule.user_id` et `WorkScheduleTemplate.user_id` rattachent déjà les +plages à un utilisateur. Avant cette passe, `/planning/time` ne permettait +cependant de gérer que l'utilisateur connecté et `PlanningService` choisissait +une plage globale lorsqu'aucun utilisateur n'était filtré. Cette contamination +était incompatible avec deux techniciens. + +La correction minimale appliquée : + +- sélection du technicien dans `/planning/time` pour un administrateur ou un + détenteur de `planning.manage` ; +- requêtes horaires, absences et formations filtrées par `user_id` ; +- `DayPlanner` reçoit explicitement l'utilisateur ; +- sans horaire explicite pour cet utilisateur, aucune journée 08:00–17:00 + implicite n'est créée ; l'écran affiche une aide et un lien de configuration ; +- les tâches administratives peuvent être rattachées à un utilisateur (`NULL` + conserve les anciennes tâches globales). + +Le modèle permet plusieurs plages dans une journée via `lunch_start/lunch_end` +et des jours différents via `day_of_week`. Les pauses sont donc représentées +comme une coupure de la plage. La page affiche les horaires appliqués et la +personne concernée. Les fermetures du collège restent globales ; les congés, +formations (`TrainingParticipant`) et indisponibilités +(`TechnicianAvailability`) sont filtrés par technicien. + +Test automatisé ajouté : deux utilisateurs avec 08:00–17:00 et 07:00–15:30 +obtiennent chacun exclusivement leurs horaires. + +## Lots et préventif + +La relation réelle est directe : `Equipment.lot_id -> Lot.id`, avec héritage +possible par équipement parent (`effective_lot_id`). Un lot possède des +`LotTask`; la tâche contient `duree_minutes`, `periodicite` et les paramètres de +génération. Les formulaires équipement permettent de choisir un lot et +l'assistant équipement expose une création rapide de lot. Le détail du lot +permet d'ajouter une tâche. Il n'existe pas de route autonome `/lots/new` : la +création initiale passe par l'assistant, désormais indiqué depuis la liste des +lots. + +La durée et la périodicité sont donc des champs UI de `LotTask`. Attention : +`LotTask.effective_duration()` conserve un fallback historique de 60 minutes +si aucune durée n'est saisie ; ce comportement doit rester visible et être +remplacé ou confirmé avant une validation métier définitive. La génération +préventive complète depuis un lot et deux équipements n'a pas été rejouée via +UI dans cette passe : elle reste **NON VALIDÉE**. + +## Matrice des prérequis de Ma journée + +| Donnée | Rattachement | Création/modification UI | Utilisé par DayPlanner | Statut | +|---|---|---|---|---| +| Technicien | `User` | utilisateurs | oui | disponible | +| Horaires / pauses | `WorkSchedule.user_id` | `/planning/time` | oui | corrigé et testé | +| Congés | `PersonalLeave.user_id` | planning | oui | filtré | +| Formation | `TrainingParticipant.user_id` | planning | oui | filtré | +| Indisponibilité | `TechnicianAvailability.user_id` | planning | oui | filtré | +| Fermeture | `CollegeClosure` | administration | oui, globale | disponible | +| Salle/occupation | Room/RoomSchedule | planning salles | oui | disponible | +| Lot/tâche | `Lot`, `LotTask` | assistant + détail lot | via génération | UI à rejouer | +| Équipement | `Equipment.lot_id`, localisation | équipements | via préventif | UI à rejouer | +| Durée/périodicité | `LotTask` | tâche de lot | oui | disponible, fallback 60 à clarifier | +| Intervention | `Intervention` | interventions | oui | disponible | +| Tâche administrative | `AdminTask.user_id` | `/planning/admin-tasks` | oui | corrigé | +| Entreprise extérieure | rendez-vous planning | planning | oui | disponible | +| Urgence | intervention/candidat | interventions | oui | disponible | + +## Fallbacks détectés + +- fallback historique 08:00–17:00 : supprimé pour un `user_id` explicite ; +- durée administrative 30 minutes : supprimée, une durée absente devient « À + replanifier » ; +- durée de lot 60 minutes : conservée provisoirement, à décider avant la + prochaine validation ; +- technicien implicite : conservé uniquement pour les anciennes tâches + administratives globales, jamais pour les horaires d'un technicien. + +## Navigation et aide + +Le nouveau menu `Mon travail` expose maintenant `Horaires de travail` et `Lots +préventifs`. `Ma journée` propose un lien de configuration lorsque les horaires +manquent et signale quand le planning des salles est incomplet. L'Ancien menu +reste inchangé, administrateur uniquement, 76/76. + +## Scénario UI et limites + +Le scénario complet demandé (TECH_A → horaires, lot, tâche, équipements, +génération, Ma journée) n'a pas encore été exécuté intégralement avec un +navigateur et un compte administrateur de test. Il ne doit pas être présenté +comme validé. Les données historiques `TEST_UI_PHASE21_*` sont conservées ; +aucune donnée n'a été nettoyée. + +## Décision + +La phase est **PARTIELLEMENT VALIDÉE** : l'isolation des horaires et l'absence +de fallback silencieux sont corrigées et testées ; le parcours UI préventif +réel, la création de deux techniciens depuis l'UI et la génération sans +fixture restent à démontrer. diff --git a/docs/ui-audit/PROGRESS.md b/docs/ui-audit/PROGRESS.md index 859938e..6a0c654 100644 --- a/docs/ui-audit/PROGRESS.md +++ b/docs/ui-audit/PROGRESS.md @@ -2,6 +2,14 @@ Dernière mise à jour : 22 août 2026 — reprise après interruption. +## Requalification Phase 2.1 — partielle + +La validation technique de `DayPlanner` est conservée, mais les données +préventives Phase 2.1 avaient été créées par script/fixtures et non par le +parcours UI. Les horaires sont désormais isolés par technicien et configurables +pour un administrateur via `/planning/time`. Le parcours lot/équipement/ +préventif doit encore être rejoué depuis l'interface. + ## État global État : **en cours**. Revalidation VM P1 effectuée ; l'audit fonctionnel doit diff --git a/docs/ui-audit/UX_PROPOSALS.md b/docs/ui-audit/UX_PROPOSALS.md index c66d7c4..39bd3eb 100644 --- a/docs/ui-audit/UX_PROPOSALS.md +++ b/docs/ui-audit/UX_PROPOSALS.md @@ -1,5 +1,13 @@ # Propositions UX — phase finale +## Requalification Phase 2.1 — UX-P1 + +Les horaires, lots, équipements et tâches préventives doivent être créables +depuis un parcours métier explicite. `Ma journée` propose maintenant des liens +vers les horaires et le planning des salles ; la liste des lots indique +l'assistant de création. Le parcours complet doit encore être validé avec un +compte administrateur de test. + ## UX appliquée — Phase 2.1 La timeline de `Ma journée` affiche un résumé compact des tâches, urgences,