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.

## Phase finale locale — 22 août 2026

L'application locale est disponible sur `http://127.0.0.1:5080/`, avec
MariaDB restaurée depuis la copie VM. Les contrôles locaux UI-017, UI-031 et
UI-012 sont validés et les scénarios équipements (déplacement, quantité,
réparation, remise en service, rebut et équipement fixe) sont exécutés sur
des données `TEST_UI_*`. Les intégrations interdites et l'utilisateur `alban`
n'ont pas été touchés.

La version de référence a été incrémentée de **0.1.0-dev.2** à
**0.1.0-dev.4** (passage intermédiaire `.3`) dans les commits de release
`50d3fd0` et suivants. `VERSION` reste la source de vérité;
les valeurs Docker de secours sont alignées sur cette version. Une
reconstruction locale est à effectuer pour que le conteneur actuellement
exécuté expose cette nouvelle version.

La cartographie UX finale et les propositions (menu, onboarding, états vides,
formulaires, confirmations, TOP 10 et quick wins) sont dans
`docs/ui-audit/UX_PROPOSALS.md`. Aucun changement de refonte UX n'a été
implémenté.

Contrôle post-rebuild effectué : `/health/` répond 200 avec la version
`0.1.0-dev.4`, le commit `b6fbfe6` et une base MariaDB connectée.

## Étude Centre documentaire global — 22 août 2026

Étude d'architecture terminée dans `DOCUMENT_CENTER_PROPOSAL.md`. Le dépôt
possède trois modèles documentaires spécialisés, plusieurs conventions de
stockage et aucune table commune. La recommandation est une agrégation de
lecture par adaptateurs pour la V1, sans migration ni copie de fichier, avec
contrôle conjoint `documents.view` et permission du module source. Aucune
modification applicative, route, migration ou donnée de test n'a été créée.

Couverture estimée : **environ 85 %**. Les principaux workflows patrimoine,
interventions, stock, prévention et RBAC ont été testés localement ; restent
partiels la recherche documentaire globale, certaines variantes de planning,
les tests visuels complets responsive/accessibilité et une installation neuve.

### Suite automatisée finale

- Tests ciblés version/P1/cycle de vie : **20 passed**.
- RBAC + régressions P1 : **22 passed**.
- `pytest` complet après isolation du test RBAC : **122 passed, 1 failed,
  1 error** sur 123 tests. Le seul échec restant est le test historique de
  configuration/lookback GMAO hors périmètre ; son teardown échoue parce que
  cette configuration de test utilise un `user_id` nul. Le test stock qui
  dépendait de l'ordre RBAC est désormais isolé et passe.

## 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`).

## Étude d'architecture — centre documentaire V2 et moteur de planning interne

Date : 22 août 2026

Étude terminée sans modification du code applicatif. Deux spécifications ont
été produites :

- `DOCUMENT_CENTER_PROPOSAL_V2.md` : agrégation en lecture par adaptateurs
  des interventions, équipements et produits, sans table commune ni copie de
  fichier ; RBAC `documents.view` combiné à la permission source ;
- `PLANNING_ENGINE_PROPOSAL.md` : planning interne autonome, saisie manuelle
  des salles, provenance des créneaux, Pronote facultatif, tâches préventives,
  administratives et entreprises, urgences, heuristique déterministe et
  compatibilité multi-techniciens future.

Aucune route, migration, permission, modèle, template, synchronisation ou
fonctionnalité n'a été créée. Développement conditionné à la validation des
questions listées dans les deux documents.

## Phase 1 d'implémentation — fondations documentaires et planning interne

Date de reprise : 22 août 2026 — URL locale `http://127.0.0.1:5080/`.

La migration `g1a2b3c4d5e6` a été appliquée à la copie locale de la base VM.
Elle ajoute les types documentaires intervention/équipement, la provenance et
la résolution des créneaux `RoomSchedule`, ainsi que la permission
`documents.view`. Les données `TEST_UI_*` et `alban` sont conservées.

Fondations livrées et testées localement :

- Centre documentaire en lecture `/documents/` et vue FDS `/documents/fds`,
  agrégation par adaptateurs des interventions, équipements et produits,
  recherche, filtres, pagination, localisation calculée et téléchargement
  contrôlé sans stockage parallèle ;
- types métier intervention/équipement avec valeur historique `autre` ;
- planning interne `/planning/rooms`, saisie manuelle, protection contre la
  synchronisation, provenance et résolution manuel/Pronote/import ;
- service de disponibilité de salle consommant uniquement la vue interne
  résolue, sans appel direct à Pronote ; préparation de l'usage d'une durée
  préventive existante.

Tests ciblés Phase 1 : **3 passed** ; suites P1/formulaires/stock/interventions :
**20 passed**. Le rebuild Docker et la revalidation HTTP sur la copie locale
restent à finaliser avant le bilan de phase.