eptm_dashboard/data/docs/10-faq.md

4.1 KiB

FAQ / Dépannage

Synchronisation Escada

"Import timeout — vérifiez les logs (> 15min)"

Le subprocess Selenium n'a pas répondu dans le temps imparti. Causes possibles :

  • Escadaweb répond très lentement (en pic de charge)
  • Captcha / re-login imposé par Escada
  • Container Docker en surcharge

Que faire :

  1. Aller dans /logs et chercher le dernier [sync] actif
  2. Si Selenium est bloqué sur un écran de login : lancer un Actualiser des classes (re-login)
  3. Si gros volume de classes : lancer la sync en plusieurs lots de 5-6 classes

"Aucune classe récupérée"

Le scraping Selenium a échoué — souvent token de session expiré.

Que faire : recliquer sur "Actualiser" (ça force un re-login propre).

"Le push échoue toujours sur le même apprenti"

Possibles causes :

  • L'apprenti existe en local mais pas (ou plus) sur Escada → le pending est obsolète, à supprimer
  • Le nom diffère entre local et Escada (ex: prénom composé partiel)
  • La page Escada de cet apprenti est verrouillée par un autre éditeur (lock pessimiste Escada)

Que faire :

  1. Vérifier les logs pour le message d'erreur exact
  2. Si l'apprenti n'existe plus : supprimer le pending manuellement en DB
  3. Sinon : retenter plus tard

"L'option 'Forcer la réimportation complète' est en rouge — c'est dangereux ?"

Pas dangereux mais destructif :

  • Tous les pendings concernés sont écrasés (les modifs locales pas encore poussées sont perdues)
  • Tous les statuts d'absences sont remis à ce qu'Escada dit

À utiliser uniquement quand on veut sciemment reprendre l'état complet d'Escada.

Tâches planifiées (cron)

"J'ai créé une tâche, elle ne se déclenche pas"

Vérifier dans l'ordre :

  1. La tâche est-elle activée ? (toggle vert)

  2. L'horaire est-il dans le bon fuseau horaire ? (l'app fonctionne en Europe/Zurich)

  3. La crontab du host appelle-t-elle bien cron_tick.py ?

    crontab -l | grep cron_tick
    # Doit avoir : * * * * * docker exec eptm-dashboard-app-1 python scripts/cron_tick.py
    
  4. Regarder le log : docker exec eptm-dashboard-app-1 cat /logs/cron/

"La tâche ne notifie pas sur Telegram"

  • notify_on doit être always, success ou failure (pas never)
  • Le bot_token et chat_id doivent être valides → tester via le bouton "Tester Telegram"

Authentification

"J'ai perdu mon téléphone avec mon code 2FA"

Un admin peut réinitialiser le 2FA via la page /users : "Réinitialiser 2FA". Au prochain login, l'utilisateur reverra le QR code.

"Mon utilisateur est bloqué après plusieurs tentatives"

Pas de blocage automatique pour le moment. Si on veut en ajouter un : voir state.py:handle_login.

Données

"Les BN affichent des trous (cellules vides)"

C'est normal : un apprenti peut avoir commencé sa formation au S2 ou S3 → les premiers semestres restent vides. L'extraction depuis le PDF Escada respecte ces trous.

"Les notes Matu n'apparaissent pas"

Pré-requis : l'apprenti est dans une classe MP/MI correspondante. Le matching se fait via la classe MP1, MP2, etc. La sync Matu cherche le PDF correspondant si la case "BN" est cochée.

Performance

"L'app rame quand je change de classe avec beaucoup d'apprentis"

Le _reload reconstruit les tableaux HTML BN/Notes pour chaque apprenti — peut prendre quelques secondes pour 25+ apprentis. Un skeleton s'affiche pendant le chargement pour donner du feedback visuel.

Si vraiment lent : envisager une mise en cache des HTML rendus dans la DB (à voir avec un dev).

Conteneur Docker

"Le conteneur consomme 100% CPU à l'idle"

Bug historique lié au hot-reload qui détectait les fichiers WAL/SHM de SQLite comme des modifications source. Corrigé via REFLEX_HOT_RELOAD_EXCLUDE_PATHS=/app/data dans le docker-compose.

Si ça revient : vérifier que cette variable est bien présente dans docker-compose.dev.yml.

"Comment redémarrer proprement"

cd /opt/eptm-dashboard
docker compose -f docker-compose.dev.yml restart app

"Comment voir les logs du serveur Reflex"

docker logs -f eptm-dashboard-app-1