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 ont ensuite été effectués : image gmao-college:0.1.0-dev.5, /health/, /documents/, /documents/fds et /planning/rooms répondent 200 avec TEST_UI_PHASE1_ADMIN.

Suite complète après implémentation : 125 passed, 1 failed, 1 error. L'échec et l'erreur de teardown restent le test historique test_gmao_config_caps_lookback_at_one_year, hors périmètre explicitement interdit (configuration GMAO). Aucun nouvel échec lié à cette phase.

Version : 0.1.0-dev.4 → 0.1.0-dev.5 (commit de version séparé 676becd), source de vérité VERSION et valeurs Docker/Compose alignées.

Phase 1.5 — raccord Pronote et revalidation

Baseline : commit e006f4f, version 0.1.0-dev.5, migration g1a2b3c4d5e6, Docker sain et Pronote non configuré. Le pipeline Pronote est maintenant raccordé à normalize_pronote_lessons() puis sync_pronote_schedules() ; la disponibilité et les pages métier ne lisent que la vue interne RoomSchedule résolue.

Cas couverts : relais manuel → Pronote sans doublon, horaire modifié, manuel protégé et conflit, rapprochement ambigu, suppression limitée à la semaine, panne/retour Pronote et fraîcheur. Le bouton d'import Pronote persiste enfin les créneaux normalisés ; une panne conserve les derniers créneaux.

Tests Phase 1.5 : 7 passed ; suites Phase 1 ciblées : 26 passed. Sur la copie locale de la VM, /health/, /documents/, /documents/fds, /planning/rooms, /planning/rooms/new, /pronote/planning et /pronote/planning/2 répondent 200. Le scénario réel TEST_UI_PLANNING_PROTECTED a été créé et conservé.

Suite complète après Phase 1.5 : 129 passed, 1 failed, 1 error. Le seul échec reste le test historique de lookback de configuration GMAO et son teardown, hors périmètre interdit.

Phase 1.6 — navigation métier

Reprise le 23/08/2026 sur http://127.0.0.1:5080/, commit f78cddf, version 0.1.0-dev.5. Docker et /health/ sont sains sur la copie locale de la VM. La matrice exhaustive des 70 entrées de navigation est dans MENU_MIGRATION_MATRIX.md. Le nouveau menu métier est en place et l'ancien menu est conservé comme référentiel transitoire réservé aux administrateurs. Les états vides Documents/FDS, le planning des salles, le dashboard et la présentation RBAC ont reçu des améliorations ciblées. La version .6 sera committée séparément. Aucun test visuel réel n'est déclaré sans navigateur instrumenté.

Les tests ciblés Phase 1.6 + Phase 1/1.5 donnent 21 passed. Après isolation de la fixture de fermeture horaire, la suite complète donne 132 passed, 1 failed, 1 error ; seuls l'échec et le teardown historiques du lookback/contexte GMAO restent hors périmètre.

Correction de navigation : Ancien menu est maintenant une rubrique principale parallèle à Administration, avec les groupes historiques Principal, Interventions, Équipements, Documents et Configuration. Les 70 entrées de la matrice sont conservées et la rubrique reste réservée aux administrateurs.

Correction inventaire navigation historique — 2026-08-23

• Ancien total de référence : 70 ; quatre omissions signalées puis deux omissions supplémentaires retrouvées par comparaison Git pré-Phase 1.6.
• Nouveau total exhaustif : 76/76 (doublons mobile exclus).
• Entrées restaurées dans Ancien menu > Configuration : Messages ENT, Interprétations ENT, Personnels ENT, PRONOTE (sync salles), Ajouter un compte Outlook et Dossiers Outlook surveillés.
• Cause : inventaire initial limité au composant refactoré au lieu du bloc desktop historique complet et de ses conditions d'affichage.
• Nouveau menu métier, RBAC et intégrations inchangés ; version conservée 0.1.0-dev.6.