AdamThomasandClaude Sonnet 5
8fcc22115f
Un poste avait bien un `lead_account_id`, lu par l'écran référent
(`/mobile-referent`) et par les droits d'écriture (`ensure_can_write_position`),
mais rien ne permettait de le renseigner : aucun écran ne l'exposait, et
l'API ne validait même pas que la valeur envoyée désignait un compte référent
existant de la bonne édition.
Backend :
- `PATCH /editions/{id}/accounts/{account_id}` (nouveau) : change le `role`
d'un compte, seulement entre LEAD et VOLUNTEER (lien magique dans les deux
cas) — 422 `account.role_change_not_allowed` dès que COORDINATOR est
impliqué (mot de passe en jeu, jamais touché ici). C'est ce qui permet de
faire passer le compte d'un bénévole en référent.
- `POST`/`PATCH /positions` : `lead_account_id` vérifié — doit désigner un
compte `Role.LEAD` de la même édition, sinon 422
`position.lead_must_be_referent_account` (silencieusement accepté
jusqu'ici, y compris un compte d'une autre édition ou du mauvais rôle).
Frontend (`ConfigVolunteers.tsx`) : nouvelle section « Référent des postes »
sur la fiche du bénévole, juste après l'accès de connexion — mêmes badges à
cocher que les vœux de poste/artiste. Cocher un poste crée ou met à niveau
(LEAD) l'accès de connexion du bénévole automatiquement ; décocher retire
seulement le poste, sans jamais rétrograder l'accès. Un bénévole dont le
compte est déjà COORDINATOR ne peut pas être désigné référent (il a déjà
accès à tout). Miroir complet côté mock (`accounts.update`,
`checkLeadAccount`) pour que la démonstration se comporte pareil.
Vérifié : 204 tests backend pertinents (14 nouveaux : 6 sur `PATCH accounts`,
8 sur la validation `lead_account_id`), ruff, alembic check ; typecheck/
lint/build/smoke frontend ; parcours complet testé en direct sur le jeu de
démo (création de compte, promotion LEAD, rejet COORDINATOR, affectation
référent) avant nettoyage des données de test.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017uUsRg7XzopkCPWimwg9ZM
Gestion des bénévoles
Application web de gestion des bénévoles pour un festival associatif. Backend FastAPI + PostgreSQL, frontend React (à venir), déploiement Docker Compose auto-hébergé.
Voir CLAUDE.md pour le vocabulaire du domaine, l'arborescence
et les conventions.
Démarrage rapide
make demo # base + backend + frontend, jeu de démonstration chargé
make blank # idem, mais édition vierge + 1er compte coordination
- Frontend : http://localhost:5173
- API : http://localhost:8000 · Docs : http://localhost:8000/docs
make downarrête tout ·make logssuit les logs du backend
Chaque commande construit les images, applique les migrations, prépare les
données, bascule le frontend sur l'API réelle (.env) et affiche les
identifiants de connexion.
make blank accepte des paramètres :
make blank EMAIL=moi@festival.fr PASSWORD=mon-mot-de-passe-solide \
NAME="Festival 2026" START=2026-07-01 END=2026-07-04
Le jeu de démo : 120 bénévoles fictifs, 15 postes, 4 jours. L'édition vierge : une édition + un compte coordination (mot de passe) + 3 créneaux types.
Tests
docker compose run --rm backend uv run pytest
La base de test (benevoles_test) est créée automatiquement au premier
démarrage du conteneur PostgreSQL.
Structure
| Dossier | Rôle |
|---|---|
backend/ |
API FastAPI, modèle SQLModel, migrations Alembic |
frontend/ |
Interface React + Vite + TS + Tailwind (service frontend) |
deploy/ |
Configuration de déploiement production (compose, Caddy, runbook) |
.gitlab-ci.yml |
Chaîne CI/CD (tests → build → SSH sur le VPS) |