Les enseignants ont besoin de moyennes à jour immédiatement après la
publication ou modification des notes, sans attendre un batch nocturne.
Le système recalcule via Domain Events synchrones : statistiques
d'évaluation (min/max/moyenne/médiane), moyennes matières pondérées
(normalisation /20), et moyenne générale par élève. Les résultats sont
stockés dans des tables dénormalisées avec cache Redis (TTL 5 min).
Trois endpoints API exposent les données avec contrôle d'accès par rôle.
Une commande console permet le backfill des données historiques au
déploiement.
Les tests E2E échouaient pour trois raisons principales :
1. Initialisation asynchrone TipTap — L'éditeur rich-text s'initialise
via des imports dynamiques dans onMount(). Les tests interagissaient
avec .rich-text-content avant que l'élément n'existe dans le DOM.
Ajout d'attentes explicites avant chaque interaction avec l'éditeur.
2. Pollution inter-tests — Les fonctions de nettoyage (classes, subjects)
ne supprimaient pas les tables dépendantes (homework, evaluations,
schedule_slots), provoquant des erreurs FK silencieuses dans les
try/catch. De plus, homework_submissions n'a pas de ON DELETE CASCADE
sur homework_id, nécessitant une suppression explicite.
3. État partagé du tenant — Les règles de devoirs (homework_rules) et le
calendrier scolaire (school_calendar_entries avec Vacances de Printemps)
persistaient entre les fichiers de test, bloquant la création de devoirs
dans des tests non liés aux règles.
Le commit 23dd717 a introduit un cache Redis (paginated_queries.cache)
pour les requêtes paginées. Les tests E2E qui modifient les données via
SQL direct (beforeAll, cleanup) contournent la couche applicative et ne
déclenchent pas l'invalidation du cache, provoquant des données obsolètes.
De plus, plusieurs problèmes d'isolation entre tests ont été découverts :
- Les tests classes.spec.ts supprimaient les données d'autres specs via
DELETE FROM school_classes sans nettoyer les FK dépendantes
- Les tests user-blocking utilisaient des emails partagés entre les
projets Playwright (chromium/firefox/webkit) exécutés en parallèle,
causant des race conditions sur l'état du compte utilisateur
- Le handler NotifyTeachersPedagogicalDayHandler s'exécutait de manière
synchrone, bloquant la réponse HTTP pendant l'envoi des emails
- La sélection d'un enseignant remplaçant effaçait l'autre dropdown car
{#if} supprimait l'option sélectionnée du DOM
Corrections appliquées :
- Ajout de cache:pool:clear après chaque modification SQL directe
- Nettoyage des FK dépendantes avant les DELETE (classes, subjects)
- Emails uniques par projet navigateur pour éviter les race conditions
- Routage de JourneePedagogiqueAjoutee vers le transport async
- Remplacement de {#if} par disabled sur les selects de remplacement
- Recherche par nom sur la page classes pour gérer la pagination
- Patterns toPass() pour la fiabilité Firefox sur les color pickers
Les administrateurs peuvent désormais configurer l'identité visuelle
de leur établissement : upload d'un logo (PNG/JPG, redimensionné
automatiquement via Imagick) et choix d'une couleur principale
appliquée aux boutons et à la navigation.
La couleur est validée côté client et serveur pour garantir la
conformité WCAG AA (contraste ≥ 4.5:1 sur fond blanc). Les
personnalisations sont injectées dynamiquement via CSS variables
et visibles immédiatement après sauvegarde.
