gmao/docs/ui-audit/PROGRESS.md

# Avancement de l'audit

Dernière mise à jour : 22 août 2026 — reprise après interruption.

## État global

État : **en cours**. Revalidation VM P1 effectuée ; l'audit fonctionnel doit
continuer sur les scénarios encore testables.

## Phases

| Phase | État | Notes |
|---|---|---|
| Santé, connexion, version | Terminé | Version 0.1.0-dev.2, commit unknown |
| Menu et smoke test | Partiel | Pages principales testées séquentiellement |
| RBAC | Partiel avancé | multi-rôles, retrait/deny et accès directs testés ; menu non filtré |
| Établissement | Partiel | Sites, bâtiments et zones créés ; confusion site/bâtiment |
| Salles | Partiel avancé | Sélection bâtiment/zone corrigée et création/rejet croisé revalidés |
| Équipements | Bloqué partiel | Groupes créés, mais détail `/equipments/<id>` en 500 (UI-031) |
| Interventions | Partiel | Création/validation et dashboard revalidés ; liste encore en 500 (UI-017) |
| Planning | Partiel | time/availability/tâches testés ; disponibilité semble dupliquée |
| Prévention | Partiel | Validation invalide et création d'un agent TEST_UI vérifiées |
| Stock / produits | Partiel avancé | Produit/référence/conditionnement, emplacements, lots, réception, sortie FEFO, transfert et inventaire testés ; état du stock 500, transvasement/prévision 500 |
| Personnel | Partiel | Agent TEST_UI créé et retrouvé dans la page prévention |
| Documents | Partiel | `/documents/` 404 ; `/cleaning/documents` 200 ; upload réel non effectué faute de cible publique stable |
| Responsive/accessibilité | Partiel | entreprises 390x844 et 768x1024 sans débordement |

## Dernière action réussie

- Connexion `chatgpt`.
- Vérification HTTP des pages principales.
- Création de données `TEST_UI_*` listées dans `CREATED_TEST_DATA.md`.
- Smoke responsive `/companies/` en 390x844 et 768x1024 sans débordement.
- Formulaire produit ouvert et rempli ; la soumission est restée bloquée plus
  de 30 secondes, sans nouvelle tentative pour ne pas charger la VM.
- Formulaire prévention ouvert et rempli ; la soumission est restée bloquée,
  sans répétition.

## Blocages

- `/cleaning/transvasement` → 500.
- `/cleaning/forecast-config` → 500.
- `/equipments/rooms/new` → aucun bâtiment dans le sélecteur.
- L'instance a déjà subi des indisponibilités temporaires lors d'un crawl trop
  rapide ; reprendre avec une seule session et des délais longs.
- La soumission de `/cleaning/products/new` a de nouveau dépassé le délai lors
  d'un test isolé ; données de produit à vérifier avant toute répétition.
- La soumission d'un agent prévention a également dépassé le délai ; analyser
  les logs/ressources avant de qualifier le comportement applicatif.
- Intervention ID 1 créée sans salle : détail/édition 200, liste principale
  500 ; cas ajouté aux bugs UI-017/UI-018.
- Reproduction du tableau de bord après cette création : `/` répond 500 ; le
  journal confirme `dashboard/index.html:495` (`interv.equipment.name` sur une
  relation nulle), ajouté en UI-019.
- Smoke complémentaire : scheduled, meters, consumables, admin-tasks, rules,
  formations personnelles, prévention, lifecycle, à jeter, anciens, services
  et types de salles répondent 200 ; `/documents/` répond 404.
- Création RBAC : rôles 9/10 et utilisateurs 3/4 ; union multi-rôles, deny
  individuel et 403 directs vérifiés.
- Filtres lots/équipements/interventions testés ; pagination incohérente sur
  interventions/entreprises et absence de recherche visible sur entreprises.
- Validations vides : entreprises et interventions renvoient 500 ; rôles et
  produits restent sur le formulaire avec validation.
- Smoke complémentaire : stock/emplacements/transferts/mouvements/inventaire,
  création équipement avancée et assistant inventaire, pièces, contrats,
  formations, services, types de salles, lot, tâches et formulaires de
  disponibilité/fermeture répondent 200.
- Navigation : `/logs/` reste visible dans le HTML mais répond 403 pour
  `chatgpt`, ajouté en UI-020.
- Les liens supplémentaires du menu (exports, logements, compteurs,
  planificateur, profil, alertes et messagerie) ont répondu 200 ; aucun bouton
  de synchronisation/intégration n'a été déclenché.
- `/planning/` répond 200 en environ 5,5 s et produit une page d'environ
  347 Ko sur cette VM ; à surveiller comme performance perçue, sans test de
  charge.
- Dernier contrôle santé : `/health/` répond 200, base MySQL connectée,
  environnement `development`, version `0.1.0-dev.2`, commit `unknown` ; un
  accès anonyme à `/` redirige correctement vers la connexion.
- Contrôle des identifiants inexistants : équipements, interventions,
  entreprises, lots, produits, pièces, contrats et formations renvoient tous
  404 proprement (aucun 500 observé).
- Paramètres de liste invalides (`page=abc`, page négative, recherche avec
  caractères spéciaux, filtres inconnus) : les quatre URLs testées répondent
  200 sans erreur serveur.
- Connexion avec identifiants inconnus : le formulaire reste en 200 et affiche
  un message d'erreur, sans redirection ni ouverture de session.
- La validation métier prévention `/prevention/risk` avec unité/danger vides et
  cotations hors plage redirige vers la page avec message d'erreur, sans créer
  de donnée.
- Création personnel : `TEST_UI_AGENT ENTRETIEN` a été créé via
  `/prevention/staff`, puis retrouvé dans la page (HTTP 302 puis 200).
- Création prévention complémentaire : risque DUERP et entrée de registre
  `TEST_UI_*` créés, puis retrouvés dans `/prevention/` après redirection.
- Export DUERP : `/prevention/duerp.csv` répond 200 avec un CSV UTF-8 et un
  nom de fichier de téléchargement correct.
- Les formulaires de fermeture et de nouvelle tâche planning s'appuient sur
  l'injection JavaScript du CSRF ; sans ce script, aucun champ caché n'est
  présent et le serveur renvoie 400 (UI-021).
- La vue journalière `/planning/day/2026-08-25` et les écrans planning
  scheduled/meters/consumables/admin-tasks/rules répondent 200.
- API anonyme : `/api/v1/status`, `/api/v1/equipments` et
  `/api/v1/interventions` renvoient chacun 401 JSON avec un message
  d'authentification, conformément au deny-by-default.
- Les listes pièces, services, contrats et formations ne contenaient pas de
  lien de détail au moment du test ; le détail de l'entreprise ID 1 répond
  200.
- Les POST vides avec CSRF valide sur réception, sortie et transfert restent
  sur le formulaire en 200 ; l'inventaire n'offre aucune ligne d'action tant
  qu'aucun emplacement n'est disponible. Les POST sans CSRF testés plus tôt
  renvoient 400.
- Scénario stock sans salle : produit, référence, conditionnement, deux
  emplacements et deux lots créés ; réception 2×5 L et 3×5 L réussie ; sortie
  d'1 L et transfert de 5 L réussis. Le journal confirme que la sortie a
  choisi `TEST_UI_LOT_EARLY` (DLU la plus proche), donc FEFO fonctionne sur ce
  cas. Inventaire validé avec correction tracée ; `/cleaning/stock` répond
  toutefois 500 après ces opérations (UI-022).
- Fiches papier : profil `TEST_UI_PROFIL_ENTRETIEN` créé puis fiche
  `/cleaning/requests/print/1` vérifiée avec le personnel TEST_UI. Aucun
  produit n'était autorisé sur les fiches car `request_enabled` est désactivé
  par défaut ; ce point limite le test des lignes imprimées.
- Le champ métier `request_enabled` n'est exposé ni à la création ni à
  l'édition d'un produit ; aucun produit n'est donc sélectionnable dans le
  profil (UI-023).
- Sorties stock invalides (`-1` puis `999999`) : le formulaire reste en 200
  avec message métier, sans mouvement supplémentaire ni stock négatif.
- Création d'un produit générique portant un nom déjà existant : le formulaire
  reste en 200 et affiche « existe déjà », sans doublon détecté.
- Édition produit avec `stock_minimum=abc` : HTTP 500 (UI-024), alors que la
  création gère ce cas avec un message d'erreur.
- Création d'une seconde référence commerciale portant le même nom : acceptée
  sans avertissement, deux lignes apparaissent (UI-025).
- Vérification structurelle des formulaires : les labels produits/stock et
  prévention sont visuellement présents mais non reliés par `for`/`id`, ajouté
  en UI-026.
- L'étiquette du mouvement de réception `/cleaning/labels/1` répond 200 et
  reprend le produit de test ; les identifiants sans mouvement retournent 404.
- Action prévention `TEST_UI_ACTION_SECURITE` créée puis testée avec les
  statuts `en_cours`, invalide et `cloturee` ; le statut invalide redirige sans
  modifier l'action et la clôture est persistée.
- Le formulaire d'habilitation accepte une date d'expiration antérieure à la
  date d'émission (POST 302 sans erreur), ajouté en UI-027.
- Après cette soumission, aucun tableau d'habilitations n'est rendu sur
  `/prevention/`, ajouté en UI-028.
- Les listes produits, références, mouvements et profils de demande ont été
  inspectées : aucun champ de recherche, filtre ou pagination visible (UI-029).
- Transfert d'une quantité supérieure au stock : le formulaire reste en 200
  avec message métier et aucun transfert supplémentaire.
- Document artificiel `test_document.pdf` téléversé sur l'intervention 1 :
  téléchargement ID 1 répond 200, mais le détail ne l'affiche pas (UI-030).
- Téléversement d'un fichier `.exe` artificiel : redirection avec rejet et
  aucun second document téléchargeable (ID 2 renvoie 404).
- Vérification responsive structurelle : les pages produits, stock,
  prévention, planning et intervention contiennent la meta viewport et des
  classes Bootstrap responsive ; le seul rendu multi-viewport visuel reste
  celui déjà réalisé sur entreprises, faute de navigateur disponible dans
  cette reprise.
- La prévision détaillée `/cleaning/forecast/1` répond 200 et affiche stock,
  consommation, sécurité et commande ; la configuration globale a été
  corrigée dans le dépôt local (UI-002), à revalider sur VM.

## Prochaine étape

Qualifier ultérieurement UI-017 et UI-031 dans une passe de code dédiée, puis
reprendre les déplacements et cycles de vie d'équipements. Les contrôles
stock, formulaires et planning indépendants restent à poursuivre.

## Revalidation VM — 22 août 2026

- **VALIDÉ SUR VM** : UI-001, UI-002, UI-003, UI-015, UI-016, UI-019,
  UI-022, UI-024 et UI-030.
- **TOUJOURS REPRODUCTIBLE** : UI-017 (`/interventions/` en 500 avec relation
  salle absente).
- **CORRIGÉ PARTIELLEMENT — PROBLÈME RÉSIDUEL** : UI-012 (lien global
  Journaux encore visible malgré le 403).

Le dashboard est revenu en 200 et affiche « Aucun équipement ». Six salles,
deux groupes d'équipements, une entreprise, une intervention, un PDF
artificiel et un mouvement de transvasement ont été ajoutés et laissés dans la
base ; aucune donnée antérieure n'a été supprimée.

Contrôle de non-régression séquentiel après revalidation : bâtiments, zones,
salles, équipements, entreprises, prévention, planning, produits, références,
mouvements et emplacements renvoient 200. La VM reste lente mais stable sur
ce lot (environ 0,8 à 3,7 s par page) ; aucun test de charge n'a été lancé.

## Passe de corrections locales P1 — 2026-08-22

État : correctifs implémentés dans le dépôt, revalidation VM requise.

Corrigés dans le code : UI-001, UI-002, UI-003, UI-012, UI-015, UI-016,
UI-017, UI-019, UI-022, UI-024 et UI-030.

Tests locaux ajoutés dans `tests/integration/test_ui_p1_regressions.py` et
exécutés avec les suites équipements, nettoyage et audit intervention.

À revalider sur VM : création salle avec bâtiments existants, trois pages
cleaning sur données `TEST_UI_*`, dashboard/liste avec relations nulles,
upload puis affichage d'un document, et visibilité des menus pour les profils
RBAC existants.

Dernière exécution locale ciblée : **16 passed** (`pytest` sur les quatre
fichiers concernés).

Suite complète locale : **117 passed, 1 failed, 1 error**. Le test échoué est
`test_gmao_config_caps_lookback_at_one_year`, hors périmètre de cette passe
(la configuration de contexte GMAO est explicitement exclue) ; son teardown
échoue également sur une contrainte `gmao_context.user_id` nulle. Aucun échec
des tests ciblés par les correctifs P1.

## Passe corrective ciblée locale — 22 août 2026

UI-017, UI-031 et le résidu UI-012 sont **CORRIGÉS DANS LE CODE — À
REVALIDER SUR VM**. UI-017 accepte désormais les quatre combinaisons de
relations optionnelles ; UI-031 rend les fiches d'équipement groupé et sa
hiérarchie même sans enfant ; UI-012 aligne le bouton Journaux sur
`watchdog_dnd.view`.

Tests ciblés : **10 passed** ; suites demandées : **19 passed**.
Suite complète : **120 passed, 2 failed, 1 error**. Le test historique de
lookback GMAO échoue toujours avec son teardown ; un test stock échoue aussi

## Revalidation VM après déploiement — 22 août 2026

Correctifs vérifiés : `8c54f46`, `864f65d`, `f2783a0`, `ce6d8ae`.

| Élément | Statut | Résultat observé |
|---|---|---|
| UI-017 — liste interventions | **VALIDÉ SUR VM** | Liste, détails, planning et dashboard en 200 ; relations absentes affichées par un libellé humain. |
| UI-031 — détail équipements | **TOUJOURS REPRODUCTIBLE** | `/equipments/1` et `/equipments/2` en 500 ; hiérarchies JSON en 200 avec zone, salle et quantités. |
| UI-012 — lien Journaux | **VALIDÉ SUR VM (négatif)** | `chatgpt` n'a pas le lien et `/logs/` reste 403 ; contrôle positif à compléter. |

Les scénarios de déplacement, casse, réparation et mise au rebut restent
bloqués par UI-031. Aucun nouveau compte ni objet n'a été créé pendant cette
revalidation ; les données `TEST_UI_*` existantes ont été conservées. Les
zones interdites et l'utilisateur `alban` n'ont pas été touchés.

### Couverture de cette passe

- Contrôle santé et conservation de la base : terminé.
- UI-017 : terminé et validé sur VM.
- UI-031 : hiérarchie revalidée, détail encore bloqué.
- UI-012 : contrôle négatif terminé ; contrôle positif restant.
- Scénarios équipements dépendants du détail : non exécutables tant que le
  500 persiste.

Prochaine étape : corriger UI-031 dans une passe de code distincte, puis
revalider sur la VM avant de reprendre les mouvements d'équipements.

## Reprise locale sur copie de VM — 22 août 2026

URL locale : `http://127.0.0.1:5080/`.

- Docker : MariaDB, Flask et Adminer démarrés et sains ; migrations Alembic
  appliquées au démarrage.
- Base : copie locale de la VM, données `TEST_UI_*` présentes et conservées.
- Build exécuté avec le commit `d4d80a3`, puis relancé avec le correctif
  `08c5b65`.
- Watchdogs/intégrations : non configurés et non sollicités.

### Correctifs et revalidation locale

- **UI-017 — VALIDÉ LOCALEMENT SUR COPIE VM** : liste, détails, planning et
  dashboard en 200 pour les relations optionnelles ; libellés humains.
- **UI-031 — VALIDÉ LOCALEMENT SUR COPIE VM** : cause reproduite dans les
  logs (`TemplateRuntimeError: No filter named 'nl2br'`), filtre enregistré
  dans la factory, détail et hiérarchie des équipements 1/2 en 200.
- **UI-012 — VALIDÉ LOCALEMENT SUR COPIE VM** : contrôle négatif avec
  `chatgpt` (lien absent/403) et contrôle positif avec
  `TEST_UI_REVALIDATION_RBAC` (lien présent/`/logs/` en 200).

### Scénarios équipements exécutés

Un groupe correctement déclaré `TEST_UI_EQ_CHAISES_GROUP_CORRECT` (ID 3,
quantité 30, salle 2) a été créé pour compléter le scénario importé dont le
champ historique `is_group` était faux. Déplacements quantitatifs de 1 puis
5 unités vers la salle 3 : mouvement journalisé, groupe cible ID 4 avec 6
unités, refus d'une quantité 999 sans quantité négative.

Une unité a été retirée pour réparation (ID 5), l'intervention ID 3 créée,
puis la réparation terminée et l'unité remise en service. Une autre unité
(ID 6) a été proposée puis confirmée au rebut ; elle est `jete`, sans salle,
et conserve ses événements de cycle de vie.

Un luminaire fixe `TEST_UI_EQ_LUMINAIRE_LOCAL` (ID 7) a été créé. La tentative
de déplacement est refusée par la règle de mobilité fixe et l'équipement
reste dans sa salle.

### Contrôle de régression local

Le balayage séquentiel des pages principales (patrimoine, interventions,
planning, prévention, stock, RBAC, détail équipements) n'a relevé aucun 500.
`/documents/` reste un 404 connu (UI-011). Le test ciblé
`test_grouped_equipment_detail_and_hierarchy` passe : **1 passed**.
après modification du rôle admin par les tests RBAC. Ces résultats sont hors
des trois correctifs ciblés.

Commits : `8c54f46`, `864f65d`, `f2783a0`.

### Fiches papier

UI-023 est corrigé localement : `request_enabled` est désormais visible et
modifiable dans `/cleaning/products/<id>/edit`. Le produit
`TEST_UI_DETERGENT_SOL` a été activé et apparaît dans `/cleaning/requests/new`.
Test automatisé associé : **1 passed** (`product_request_enabled_is_editable`).