docs(phase21b): documenter le workflow preventif
This commit is contained in:
parent
c2cdacb0fa
commit
a23e01b4ab
6 changed files with 66 additions and 15 deletions
|
|
@ -563,3 +563,11 @@ oubliées, dont les quatre fonctions ENT/Pronote signalées. Elles sont
|
|||
maintenant représentées dans `Ancien menu > Configuration` et dans la matrice
|
||||
(`MENU_MIGRATION_MATRIX.md`). Aucun endpoint, contrôle RBAC ou comportement
|
||||
d'intégration n'a été modifié. Nouveau total : 76/76.
|
||||
|
||||
### Phase 2.1b
|
||||
|
||||
- Les 147 durées annoncées ne correspondent actuellement qu'à 132 lignes
|
||||
numériques dans le document de proposition ; l'écart est documenté et ne
|
||||
doit pas être comblé par une valeur arbitraire.
|
||||
- La sélection en masse filtrée des équipements et le raccord automatique des
|
||||
durées espaces verts aux tâches de lot restent à faire.
|
||||
|
|
|
|||
|
|
@ -172,3 +172,8 @@ données existantes de la copie VM.
|
|||
|
||||
Le mot de passe du compte de test est local uniquement et n'est pas stocké
|
||||
dans ce dépôt.
|
||||
|
||||
## Phase 2.1b
|
||||
|
||||
Aucune donnée `TEST_UI_PHASE21B_*` n'a été créée dans cette passe : les
|
||||
scénarios entreprise doivent être rejoués depuis l'interface avant validation.
|
||||
|
|
|
|||
|
|
@ -8,9 +8,18 @@ possède également l’entreprise, le contrat, l’équipement, la salle,
|
|||
l’affectation et les dates prévues/réelles. `ContractVisit` représente une
|
||||
visite de contrat avec une date et un statut.
|
||||
|
||||
Cette base permet d’associer une tâche à une entreprise, mais ne distingue pas
|
||||
encore proprement : date d’échéance, rendez-vous avec heure, passage libre,
|
||||
arrivée réelle, non-venue et temps d’accompagnement du technicien.
|
||||
Cette base permet d'associer une tâche à une entreprise, mais ne distingue pas
|
||||
encore proprement : date d'échéance, rendez-vous avec heure, passage libre,
|
||||
arrivée réelle, non-venue et temps d'accompagnement du technicien.
|
||||
|
||||
## Implémentation Phase 2.1b
|
||||
|
||||
La migration `i4d5e6f7a8b9` et la page **Passages & contrôles** couvrent les
|
||||
modes « Sur rendez-vous », « Date connue, heure inconnue » et « Passage libre »,
|
||||
ainsi que la date réelle, l'arrivée, la non-venue et l'accompagnement
|
||||
ponctuel/complet. Un rendez-vous avec heures devient une contrainte fixe de
|
||||
`DayPlanner`; les autres modes sont des informations non bloquantes jusqu'à
|
||||
l'arrivée de l'entreprise.
|
||||
|
||||
## Parcours métier proposé
|
||||
|
||||
|
|
|
|||
|
|
@ -47,34 +47,46 @@ verts.
|
|||
|
||||
Les champs existants `company_id`, `contract_id`, `periodicite` et
|
||||
`jours_entre_interventions` sont exposés dans la fiche de tâche, ainsi que le
|
||||
type d'exécutant. En revanche, le workflow complet de passage (rendez-vous,
|
||||
fenêtre, non-venue, date réelle, accompagnement et tableau Passages &
|
||||
contrôles) n'est pas encore implémenté dans cette passe. `ContractVisit` ne
|
||||
porte actuellement qu'une date obligatoire et ne peut pas représenter
|
||||
fidèlement les trois modes demandés sans migration métier dédiée.
|
||||
type d'exécutant. La migration `i4d5e6f7a8b9` ajoute les modes `appointment`,
|
||||
`date_only` et `open_window`, les heures/fenêtres, la date réelle, l'arrivée,
|
||||
l'accompagnement et le technicien. La page **Passages & contrôles** permet
|
||||
les actions Réalisée, Non venue et Entreprise arrivée. Un rendez-vous avec
|
||||
heures est transmis à `DayPlanner` comme contrainte fixe ; les autres modes
|
||||
restent informatifs et ne bloquent pas une plage horaire.
|
||||
|
||||
Le fichier `preventive_duration_proposals.py` embarque les **132** valeurs
|
||||
numériques effectivement présentes dans la proposition documentaire. Elles
|
||||
sont appliquées uniquement aux nouvelles lignes de catalogue dont la durée est
|
||||
vide ; les personnalisations existantes ne sont jamais écrasées. L'écart avec
|
||||
les 147 valeurs minimales annoncées doit être clarifié métier avant d'ajouter
|
||||
des valeurs.
|
||||
|
||||
## Migration
|
||||
|
||||
`h3c4d5e6f7a8_phase21b_preventive_scope.py` ajoute sans perte :
|
||||
`h3c4d5e6f7a8_phase21b_preventive_scope.py` et
|
||||
`i4d5e6f7a8b9_phase21b_contract_visits.py` ajoutent sans perte :
|
||||
|
||||
- les trois colonnes de qualification à `lot_tasks` ;
|
||||
- la table d'association `lot_task_equipments` ;
|
||||
- les quatre durées d'espaces verts à `zones`.
|
||||
- les données de passage entreprise à `contract_visits`.
|
||||
|
||||
La migration est additive et possède un downgrade. Elle n'attribue aucun
|
||||
horaire, lot ou exécutant à `alban`.
|
||||
|
||||
## Tests ajoutés
|
||||
|
||||
`tests/unit/test_preventive_scope.py` couvre le calcul par quantité, le forfait
|
||||
par cible et l'absence explicite de durée. La compilation Python et le
|
||||
`tests/unit/test_preventive_scope.py` et
|
||||
`tests/unit/test_external_maintenance_visit.py` couvrent le calcul par
|
||||
quantité, les modes de passage, le forfait par cible et l'absence explicite de durée. La compilation Python et le
|
||||
chargement des modèles passent. La suite intégration locale est actuellement
|
||||
bloquée par l'erreur historique de teardown (`equipment_lifecycle_events`
|
||||
absente de la base de test), déjà présente avant cette passe.
|
||||
|
||||
## État de validation
|
||||
|
||||
Cette passe est **partiellement validée** : la durée unitaire, le périmètre et
|
||||
les durées de zone ont une base persistante et une UI simple ; le workflow
|
||||
entreprise complet et le scénario intégral sans intervention technique restent
|
||||
à réaliser. Phase 2.2 non commencée.
|
||||
Cette passe est **partiellement validée** : durée unitaire, périmètre, durées
|
||||
de zone et workflow de passage de base sont persistants et exposés dans l'UI.
|
||||
La sélection en masse avancée, le raccord automatique espaces verts → lot et
|
||||
le scénario intégral sans intervention technique restent à renforcer. Phase
|
||||
2.2 non commencée.
|
||||
|
|
|
|||
|
|
@ -506,3 +506,12 @@ aux administrateurs.
|
|||
teardown.
|
||||
- Validation visuelle réelle non exécutée : aucun navigateur instrumenté
|
||||
disponible ; contrôles HTTP et HTML effectués.
|
||||
|
||||
## Phase 2.1b — préventif et passages entreprise
|
||||
|
||||
- Durée unitaire, périmètre dynamique/manuel, exécutant et durées d'espaces
|
||||
verts ajoutés via migration additive.
|
||||
- Passages entreprise : rendez-vous, date sans heure, passage libre, arrivée,
|
||||
non-venue, date réelle et accompagnement ; page `Passages & contrôles`.
|
||||
- Phase partiellement validée : sélection en masse avancée et scénario complet
|
||||
UI restent à compléter.
|
||||
|
|
|
|||
|
|
@ -376,3 +376,11 @@ administrables par technicien et isolés dans `DayPlanner`. En revanche, la
|
|||
chaîne préventive complète n'a pas été configurée depuis l'UI : les données
|
||||
Phase 2.1 historiques venaient de scripts/fixtures. Aucun lot ou équipement
|
||||
marqué Phase 2.1 n'était présent dans la copie VM inspectée.
|
||||
|
||||
## Phase 2.1b
|
||||
|
||||
La durée par élément et les périmètres d'équipements sont persistants et
|
||||
modifiables. Les passages entreprise disposent de trois modes et d'un suivi
|
||||
réalisé/non-venue. La phase reste **PARTIELLEMENT VALIDÉE** : la sélection en
|
||||
masse et le scénario de bout en bout n'ont pas encore été rejoués entièrement
|
||||
depuis l'interface.
|
||||
|
|
|
|||
Loading…
Reference in a new issue