Files

T

davideandClaude Opus 5 f687322c3f Vieta l'autovoto, allinea la doc al codice e toglie tre riletture.

Rilettura completa della documentazione confrontata con il codice. Dove la doc
diceva il falso l'ho corretta; dove aveva ragione lei ho corretto il codice.

Autovoto (la doc aveva ragione)

- migration m12_niente_autovoto: vincoli mvp_no_autovoto e badge_social_no_autovoto,
  gli stessi che pagelle_voti ha dalla v1.0. Le righe che li violano vengono
  cancellate prima dell'ALTER, altrimenti fallisce; in locale non ce n'erano.
  M11 garantisce solo che il voto sia firmato con il proprio votante_id, non che il
  votato sia un altro: eleggersi MVP restava a un POST di distanza.
- VotazioneMvp non mostra più il votante nell'elenco, come già faceva VotoSocial.

Test che guardavano la colonna sbagliata

- scritture.test.ts verificava che aggiornato_il si muovesse, chiamandolo "quello che
  alimenta la serie di conferme". È l'opposto: la serie usa risposto_il, che il trigger
  di M9 deve tenere fermo. Ora il test prova a riscriverlo e controlla che il database
  abbia tenuto la prima risposta; prima passava anche senza trigger.
- destinatariSollecito() esce dalla route sollecita-presenze e diventa una funzione pura
  in presenze.ts, con i suoi test — stesso trattamento di avvisiPalloniEvento.

Tre riletture in meno

- giocatori-squadra, scout-store e avatar-store usavano invalidateQueries dove il dato
  scritto era già noto: ora setQueryData, come il resto dell'app. Resta scout-live, dove
  il lock può averlo vinto un altro dispositivo.

Documentazione riallineata

- presenze.md, badge.md, mvp.md: i limiti su RLS aperta e route non autenticata erano
  superati da M11 e DD-024;
- serie-presenze.md: il filtro è e.data < oggi, non <=, e l'evento di oggi non conta
  (conterebbe come assenza per tutti); aggiunta la tabella risposto_il/aggiornato_il;
- ARCHITECTURE.md ed EFFICIENZA_CLOUD.md: una sola eccezione a setQueryData;
- DATABASE.md: i vincoli delle tre tabelle di voto;
- PROJECT_STATE.md: fermo a M9, ora arriva a M12.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-06 19:30:49 +02:00

3.9 KiB

Raw Blame History

Modulo — Presenze

Stato: implementato (v1.0) File principali: src/lib/presenze.ts, src/lib/presenze-mese.ts, src/components/crapp/RosaPresenze.tsx, src/routes/api/public/sollecita-presenze.ts

Obiettivo

Permettere a ogni giocatore di confermare o rifiutare la propria partecipazione a un evento (allenamento o partita) e mostrare a tutta la squadra chi ha risposto e come, sostituendo i solleciti a voce o su chat esterne.

Dati

Tabella risposte_presenze (PK composita evento_id, giocatore_id), letta e scritta da src/lib/presenze.ts. È il modello "in uso" citato in docs/DATABASE.md; le tabelle eventi/presenze previste da DD-014 non sono referenziate da nessun punto del codice attuale.

Stati possibili (Stato in src/lib/crapp-data.ts): presente, assente, forse, ritardo, infortunato. Solo presente e ritardo contano come presenza effettiva nelle statistiche. L'assenza di una riga per (evento, giocatore) equivale a "non ha ancora risposto".

Implementazione

Giocatore tocca uno stato in RosaPresenze
      ↓
useSalvaPresenza()        → src/lib/presenze.ts   (upsert o delete su risposte_presenze,
      ↓                                             onConflict evento_id+giocatore_id)
risposte_presenze (Supabase)
      ↓  letta da
useRispostePresenze()     → src/lib/presenze.ts   (1 query per sessione, staleTime 5 min,
      ↓                                             legge tutta la tabella)
RosaPresenze               → src/components/crapp/RosaPresenze.tsx
      ↑ montato da           (riepilogo, bottoni di risposta, gruppi per stato)
allenamento.$id.tsx / partita.$id.tsx

--- statistiche ---
contaPresenzeGiocatore() / totaliEventiGiocatore()  → src/lib/presenze.ts
usePresenzeUltimoMese()                             → src/lib/presenze-mese.ts
                                                       (percentuale ultimi 30gg, da cache già in memoria)

--- sollecito (solo admin) ---
Bottone "Sollecita" (RosaPresenze.tsx) → POST /api/public/sollecita-presenze
      ↓
src/routes/api/public/sollecita-presenze.ts
      ├─ legge l'evento (eventi_app) e le risposte già date
      ├─ destinatariSollecito()  → src/lib/presenze.ts
      │  (attivi senza risposta o con "forse"; funzione pura, testata in unit)
      ├─ per ciascuno invia una push col testo cifrato nel payload
      │  (src/lib/webpush.server.ts)
      └─ elimina le iscrizioni push scadute (404/410)

Un evento conta ai fini delle statistiche di presenza solo se è di tipo partita o allenamento e il giocatore è tra i convocati (o non ci sono convocati specificati, cioè vale per tutta la rosa) — eventiContanoPresenze() in presenze.ts.

Regole rispettate

Aggiornamento ottimistico della cache locale dopo ogni salvataggio: nessuna rilettura dal server, la UI risponde subito.
Il sollecito è manuale: nessun cron nel repository lo richiama automaticamente, parte solo dal bottone admin, e la route verifica il ruolo lato server con richiediAdmin (DD-024).
Ognuno risponde solo per sé, e non è più una regola della sola interfaccia: dalla migration m11_scritture_per_ruolo la policy di risposte_presenze lega la riga allo slot giocatori_squadra collegato all'account, con gli amministratori come sola deroga (DD-023). Verificato da test/integration/permessi.test.ts.

Limiti noti

Nessuna finestra temporale per rispondere: si può cambiare risposta anche a evento passato.
La risposta di un evento passato resta modificabile: risposte_presenze non ha una finestra di chiusura, né in UI né in RLS.
useRispostePresenze() legge sempre l'intera tabella, non filtrata per evento: adeguato per una singola squadra, da rivedere se il volume cresce molto.

Evoluzioni possibili

Filtrare la lettura delle presenze per evento invece di caricare tutta la tabella.

3.9 KiB Raw Blame History