docs(phase15): document Pronote revalidation
This commit is contained in:
root
parent
90de40e227
commit
5b40037d33
6 changed files with 149 additions and 0 deletions
|
|
@ -518,3 +518,12 @@ faux échec ultérieur du smoke stock selon l'ordre d'exécution. Le test restau
|
|||
maintenant le lien dans un bloc `finally` (`933f0a5`). La suite ciblée passe
|
||||
22/22 et la suite complète ne conserve plus que l'échec historique GMAO
|
||||
lookback hors périmètre et son erreur de teardown.
|
||||
|
||||
## Phase 1.5 — anomalies revalidées
|
||||
|
||||
- Aucun nouveau bug bloquant observé sur la copie locale.
|
||||
- L'ancien bouton d'import Pronote « non implémenté » est raccordé au
|
||||
planning interne ; les erreurs de récupération sont gérées sans vider les
|
||||
créneaux connus.
|
||||
- Responsive/accessibilité visuels restent à confirmer avec un navigateur
|
||||
instrumenté avant VM distante.
|
||||
|
|
|
|||
|
|
@ -138,3 +138,9 @@ de déplacement ; aucune donnée antérieure ni `alban` n'a été supprimée.
|
|||
conservé pour inspection manuelle.
|
||||
- Les tests automatisés créent des objets préfixés `Phase1` dans leur base de
|
||||
test isolée ; aucune donnée `TEST_UI_*` existante n'a été nettoyée.
|
||||
|
||||
## Données ajoutées — Phase 1.5 locale — 22/08/2026
|
||||
|
||||
- Créneau `TEST_UI_PLANNING_PROTECTED`, salle `TEST_UI_CLASSE_101`, semaine du
|
||||
07/09/2026, vendredi 14:00–16:00, réunion exceptionnelle manuelle avec
|
||||
protection contre les mises à jour Pronote. Donnée conservée pour inspection.
|
||||
|
|
|
|||
102
docs/ui-audit/IMPLEMENTATION_PHASE15.md
Normal file
102
docs/ui-audit/IMPLEMENTATION_PHASE15.md
Normal file
|
|
@ -0,0 +1,102 @@
|
|||
# Phase 1.5 — raccord Pronote et revalidation des fondations
|
||||
|
||||
Date : 22 août 2026
|
||||
Base : copie locale MariaDB issue de la VM
|
||||
Version conservée : `0.1.0-dev.5`
|
||||
Commit de départ : `e006f4f`
|
||||
|
||||
## Baseline
|
||||
|
||||
- Working tree propre au démarrage.
|
||||
- Docker : `gmao-flask:0.1.0-dev.5`, MariaDB et Adminer sains.
|
||||
- `/health/` : HTTP 200, base connectée, Pronote/watchdogs non configurés.
|
||||
- Migration courante : `g1a2b3c4d5e6`.
|
||||
- Données `TEST_UI_*` présentes et conservées ; `alban` inchangé.
|
||||
- Baseline global connue : 125 passed, 1 failed, 1 error ; l'échec et
|
||||
l'erreur concernent le lookback de configuration GMAO hors périmètre.
|
||||
|
||||
## Pipeline Pronote
|
||||
|
||||
### Avant
|
||||
|
||||
Le client `get_lessons_for_room()` récupérait et normalisait des cours, mais
|
||||
la page `/pronote/planning/<room_id>` les affichait directement et le bouton
|
||||
d'import était un simple message « non implémenté ». La disponibilité interne
|
||||
utilisait déjà `RoomSchedule`, mais aucun raccord réel ne persistait ces
|
||||
données.
|
||||
|
||||
### Après
|
||||
|
||||
Le pipeline est désormais :
|
||||
|
||||
`Pronote → get_lessons_for_room(strict=True) → normalize_pronote_lessons() → sync_pronote_schedules() → RoomSchedule → active_room_schedules() → disponibilité/planning`
|
||||
|
||||
Les identifiants de cours absents sont déterministes (empreinte des attributs
|
||||
du créneau), les horodatages sont conservés et l'import est limité à la
|
||||
semaine demandée. Une erreur de récupération n'appelle pas la synchronisation
|
||||
et conserve donc les dernières données connues.
|
||||
|
||||
Pronote ne participe plus au calcul direct de disponibilité. Avec Pronote
|
||||
désactivé ou non configuré, le planning interne et la saisie manuelle restent
|
||||
utilisables.
|
||||
|
||||
## Règles de synchronisation couvertes
|
||||
|
||||
- manuel initial non protégé : supplanté par un Pronote correspondant, sans
|
||||
doublon actif ;
|
||||
- horaire Pronote modifié : ancienne ligne manuelle supplantée, nouvelle ligne
|
||||
Pronote active ;
|
||||
- manuel protégé : jamais écrasé ; conflit conservé et affiché ;
|
||||
- rapprochement ambigu : aucune fusion automatique, conflit à valider ;
|
||||
- créneau absent d'une synchronisation : `disabled`, jamais supprimé ;
|
||||
- suppression limitée à la semaine synchronisée, sans désactiver les semaines
|
||||
voisines ;
|
||||
- panne Pronote : planning et fraîcheur précédents conservés ;
|
||||
- retour Pronote : `last_synced_at` avancé et lignes réconciliées.
|
||||
|
||||
La page de planning interne affiche l'origine en termes métier, la protection
|
||||
et les conflits. Une action permet de protéger/déprotéger un manuel et de
|
||||
désactiver un créneau Pronote sans effacer son historique.
|
||||
|
||||
## Centre documentaire revalidé
|
||||
|
||||
La V1 a été retestée avec documents intervention, équipement et produit/FDS :
|
||||
agrégation, recherche par titre/fichier/contexte, source/type, pagination,
|
||||
fichier manquant, chemin hors racine, source inconnue et restriction de
|
||||
permission source. Aucun fichier n'est copié.
|
||||
|
||||
## Tests
|
||||
|
||||
- tests Phase 1.5 planning/documents : **7 passed** ;
|
||||
- suites Phase 1 ciblées (P1, équipements, nettoyage, interventions) :
|
||||
**26 passed** ;
|
||||
- tests unitaires de version : passants.
|
||||
|
||||
Les contrôles HTTP sur la copie VM locale après rebuild ont donné 200 pour
|
||||
`/health/`, `/documents/`, `/documents/fds`, `/planning/rooms`,
|
||||
`/planning/rooms/new`, `/pronote/planning` et `/pronote/planning/2`.
|
||||
La création réelle du créneau `TEST_UI_PLANNING_PROTECTED` a été vérifiée,
|
||||
avec protection persistée en base.
|
||||
|
||||
## Responsive et accessibilité ciblés
|
||||
|
||||
Les nouvelles pages utilisent les composants responsive existants (`table-
|
||||
responsive`, `table-responsive-stack`), des labels associés aux champs, des
|
||||
boutons textuels et des messages métier. Aucun navigateur instrumenté n'est
|
||||
disponible dans cet environnement ; une vérification visuelle manuelle aux
|
||||
trois tailles demandées reste à effectuer avant déploiement distant.
|
||||
|
||||
## Données ajoutées
|
||||
|
||||
- `TEST_UI_PLANNING_PROTECTED` dans `TEST_UI_CLASSE_101`, semaine du
|
||||
07/09/2026, vendredi 14:00–16:00, réunion protégée.
|
||||
|
||||
Aucune donnée `TEST_UI_*` n'a été supprimée.
|
||||
|
||||
## Limitations et hors périmètre
|
||||
|
||||
- aucune modification des identifiants/secrets Pronote ;
|
||||
- aucune Phase 2 (optimisation de journée, solveur, multi-techniciens) ;
|
||||
- aucune modification alban, watchdog, contexte GMAO, ENT ou Outlook ;
|
||||
- résolution humaine des conflits uniquement ;
|
||||
- le test historique lookback GMAO reste volontairement non corrigé.
|
||||
|
|
@ -120,3 +120,8 @@ activement.
|
|||
| FDS globales | `/documents/fds` | Implémenté, à revalider après rebuild | Produits d'entretien |
|
||||
| Planning interne des salles | `/planning/rooms` | Implémenté, à revalider après rebuild | Saisie manuelle et créneaux résolus |
|
||||
| Nouveau créneau salle | `/planning/rooms/new` | Implémenté | Permission planning.edit |
|
||||
|
||||
### Phase 1.5 — revalidation locale
|
||||
|
||||
| Planning Pronote d'une salle | `/pronote/planning/<id>` | 200 local | Vue interne résolue, provenance et fraîcheur |
|
||||
| Import Pronote d'une semaine | `/pronote/planning/<id>/import` | Raccordé | Synchronisation contrôlée, protection/conflits |
|
||||
|
|
|
|||
|
|
@ -405,3 +405,22 @@ 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é.
|
||||
|
|
|
|||
|
|
@ -300,3 +300,11 @@ variantes de planning et la validation sur installation neuve.
|
|||
également sur la contrainte `gmao_context.user_id NOT NULL`. Aucun nouveau
|
||||
échec fonctionnel n'a été introduit. La correction d'isolation est dans
|
||||
`933f0a5`.
|
||||
|
||||
## Phase 1.5 — raccord Pronote
|
||||
|
||||
Pronote alimente désormais réellement `RoomSchedule` via une normalisation
|
||||
déterministe et un import explicite par semaine. Pronote désactivé ou en panne
|
||||
ne vide pas le planning et ne bloque pas la disponibilité interne. Les conflits
|
||||
protégés, rapprochements ambigus et suppressions distantes sont conservés et
|
||||
visibles ; aucun nouveau système de planning n'a été créé.
|
||||
|
|
|
|||
Loading…
Reference in a new issue