127 lines
6.8 KiB
Markdown
127 lines
6.8 KiB
Markdown
# Requalification Phase 2.1 — prérequis métier et interface
|
||
|
||
Date : 2026-08-23
|
||
Version auditée initialement : 0.1.0-dev.8 ; correction catalogue : 0.1.0-dev.10
|
||
|
||
## 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/<id>/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. Le catalogue embarqué contient désormais les 330
|
||
tâches historiques de `lot_tasks` et son import est idempotent.
|