davideandClaude Sonnet 5
04e80a3531
Emerso da un audit doc↔codice: PROJECT_STATE.md era fermo a M12 (23 migration) mentre supabase/migrations/ ne ha 27, fino a M16; ROADMAP.md non citava MVP, Turno palloni, Infortuni e Profilo Giocatore come voci a sé pur essendo tutte implementate; profilo-giocatore.md era l'unico modulo senza l'intestazione Stato/File principali degli altri. Aggiunge anche le due spec mancanti in docs/modules/: Squadra (anagrafica, useRosa/useAnagraficaRosa, gestione admin, classifica interna) e Calendario ed Eventi (vista mensile vs gestione admin, pulizia a cascata alla cancellazione). Corregge inoltre la nota sul versionamento in CHANGELOG.md: sempre a tre cifre (x.y.z), mai x.y. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.4 KiB
Modulo — Calendario ed Eventi
Stato: implementato
File principali: src/lib/eventi.ts, src/lib/eventi.server.ts, src/routes/calendario.tsx
(vista mensile, tutti), src/routes/eventi.tsx (creazione/modifica, solo admin),
src/components/crapp/EventoCard.tsx (card condivisa)
Test: test/unit/eventi.test.ts
Obiettivo
Un unico calendario condiviso per allenamenti, partite, amichevoli ed eventi extra
(riunioni, cene di squadra...), al posto di messaggi sparsi in chat. Ogni evento in
eventi_app diventa il punto a cui si agganciano presenze, convocazioni, MVP, pagelle,
scout e turno palloni — la maggior parte degli altri moduli dipende da un evento.id.
Due schermate, due pubblici
/calendario— vista mensile per tutta la squadra, sola lettura. Mostra allenamenti, partite, eventi ed eventi virtuali per i compleanni della rosa (compleanniEventi()ineventi.ts, generati a runtime dall'anagrafica diuseAnagraficaRosa(), non righe vere dieventi_app): la spunta della vistagiorniIT/mesiITcolora la cella per tipo di evento, i giorni con più eventi si dividono lo spazio./eventi— "Gestione eventi", riservata agli amministratori (useIsAdmin()): crea, modifica ed elimina un evento, sceglie i convocati (convocatiEvento(), vuoto = tutta la rosa). Da qui si distingue "partita" da "amichevole" tramite il flagcampionato(categoriaEvento()/daCategoria()ineventi.tsconvertono tra la categoria mostrata in interfaccia e la coppia{ tipo, campionato }salvata nel database).
Entrambe leggono la stessa cache (useEventi(), EVENTI_KEY, staleTime 10 minuti: il
calendario cambia raramente). EventoCard.tsx è la card riusata da entrambe le schermate;
linkPerEvento() decide dove porta il click — /partita/$id per una partita (con
/partita-csi/$id come alternativa "solo CSI" quando non c'è un evento collegato, vedi
collegamento-csi.md), /allenamento/$id per un allenamento, nessun link per eventi ed
eventi virtuali (compleanni).
Lettura lato server
src/lib/eventi.server.ts (leggiEventi()) è la stessa conversione riga→modello di
eventi.ts, ma con supabaseAdmin per le route API che girano senza sessione utente (es.
sollecita-presenze.ts, promemoria-palloni.ts — vedi presenze.md e palloni.md) e per
notifiche-smart.ts, che decide i promemoria da mandare in base agli eventi del giorno.
Limiti noti
- Cancellare un evento è distruttivo per tutto ciò che vi era agganciato. Un trigger
(
m14_pulizia_dati_evento_cancellato, DD-029) pulisce a cascata presenze, cacche, voti MVP/pagelle/badge social, turni palloni e scout di quell'evento: non è recuperabile con un annulla, e prima di M14 quelle righe restavano orfane nel database (bonificate una tantum da M15/M16, vediPROJECT_STATE.md). - Nessuna creazione automatica degli eventi partita dal calendario CSI. Le gare
ufficiali arrivano già come dati (
getEventsByTeamId.php, vedicollegamento-csi.md), ma un amministratore deve comunque creare a mano l'evento corrispondente in/eventiperché esistano convocazioni, presenze, MVP e pagelle per quella partita — altrimenti la gara resta visibile solo nello storico CSI, con un dettaglio "solo CSI" più povero (/partita-csi/$idinvece di/partita/$id). Indocs/ROADMAP.mdsotto "Prossimo".