65 lines
3.1 KiB
Markdown
65 lines
3.1 KiB
Markdown
# Audit du catalogue préventif historique
|
|
|
|
Date : 2026-08-23
|
|
Source de référence : `/opt/gmao/dump_sql_base_remplie.sql` (lecture seule)
|
|
|
|
## Tables analysées
|
|
|
|
| Table | Lignes dans le dump | Utilité |
|
|
|---|---:|---|
|
|
| `equipment_categories` | 36 | catégories patrimoniales |
|
|
| `lots` | 92 | lots, catégorie par `category_id`, présence |
|
|
| `lot_tasks` | 330 | référentiel historique des actions par `lot_id` |
|
|
| `preventive_tasks` | 0 | ancienne table, structure présente mais aucune donnée |
|
|
| `scheduled_tasks` | 516 | échéances historiques, pas le catalogue initial |
|
|
|
|
Le modèle actuel utilise `LotTask`, et non `preventive_tasks`, pour les règles
|
|
préventives. Le dump contient 36 catégories et 92 lots, déjà représentés dans
|
|
`setup_catalog.py`; il manquait les 330 lignes de `lot_tasks`.
|
|
|
|
## Durée et périodicité
|
|
|
|
- 330 tâches ont été extraites sans modification des valeurs historiques ;
|
|
- 5 tâches ont une `duree_minutes` renseignée ; 325 ont une durée inconnue ;
|
|
- 327 ont une périodicité textuelle ; 3 ont une périodicité vide ;
|
|
- les valeurs `jours_entre_interventions`, type, contrat, gestionnaire,
|
|
déclenchement et politiques ont été conservées lorsqu'elles existent.
|
|
|
|
La valeur de 60 minutes de `LotTask.effective_duration()` n'est pas présente
|
|
dans le dump : c'est un fallback du code actuel, pas une donnée historique.
|
|
Elle reste temporairement compatible avec les anciennes données, mais une tâche
|
|
sans durée doit être signalée avant une validation métier définitive.
|
|
|
|
## Catalogue embarqué
|
|
|
|
`app_new/core/preventive_catalog.py` contient une extraction compressée et
|
|
figée des 330 tâches. Le dump n'est jamais ouvert par l'application. Le module
|
|
expose `LOT_TASKS`, utilisé par le setup wizard et les tests.
|
|
|
|
Le wizard crée les catégories, les lots sélectionnés et leurs tâches. La clé
|
|
fonctionnelle de tâche est `(lot, tache)` ; une ligne déjà existante n'est pas
|
|
écrasée, afin de préserver une personnalisation locale. Les éléments manquants
|
|
sont ajoutés. La seconde exécution est donc idempotente.
|
|
|
|
## Relation équipement
|
|
|
|
`Equipment.lot_id -> Lot.id`, avec héritage par `parent.effective_lot_id`.
|
|
Les tâches sont donc visibles via le lot effectif et peuvent générer des
|
|
`ScheduledTask` pour les équipements actifs. Un équipement rebuté ou supprimé
|
|
ne doit pas produire de nouvelle échéance.
|
|
|
|
## Première échéance
|
|
|
|
Le mécanisme actuel `generate_due_tasks()` calcule la première échéance à
|
|
partir de la date de génération et de `jours_entre_interventions`/périodicité.
|
|
Le dump ne fournit pas une date de première échéance catalogue. Une règle
|
|
métier explicite (date d'association, prochaine échéance saisie ou campagne)
|
|
reste à valider avant une automatisation plus ambitieuse.
|
|
|
|
## Écarts et limites
|
|
|
|
- le catalogue est maintenant complet pour les tables historiques validées ;
|
|
- les tâches sans durée restent à renseigner pour une planification fiable ;
|
|
- la validation bout en bout par interface (installation, association d'un
|
|
équipement, génération, Ma journée) reste à exécuter avec un compte UI ;
|
|
- `preventive_tasks` est documentée mais vide et n'est pas importée.
|