Il badge Pagellone si sblocca ora solo con almeno 5 pagelle ricevute
(VOTI_MINIMI_PAGELLA): un voto solo poteva sbloccarlo o farlo sparire senza
significatività statistica. Aggiunto Giocatore.votiPagella per farlo funzionare.
La migration m13 (DD-027) estende le policy RLS di M11 su pagelle_voti, mvp_voti e
badge_social_voti: votante e votato devono essere convocati all'evento (prima solo
un filtro applicativo), e per le pagelle anche pagelle_chiuse=false. Le policy
admin restano permissive di proposito. Applicata anche al progetto cloud.
Copertura test completa: unit sulla soglia minima, integration sulle nuove policy
RLS (permessi.test.ts) e un end-to-end reale (pagella-badge.test.ts) sul modello
di mvp-badge.test.ts.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
La votazione non dipendeva dal tempo ma dal risultato: compariva solo con un
referto CSI o uno scout salvato, e chiunque avesse un profilo poteva votare.
Ora `votoMvpAperto()` la apre due ore dopo `data`+`ora` dell'evento, il pannello
sta in una sezione sua e votano — e sono votabili — solo i presenti (o in
ritardo) di quell'evento.
I voti passano dall'id scout/CSI a quello dell'evento CrAPP: home e classifica
leggono il vincitore tramite la mappa data → evento che avevano già. Le regole
sono applicative, non RLS: chi scrive su PostgREST le aggira, come già annotato
tra i limiti noti del modulo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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>
Presenze, Serie di presenze, Scout Live, Pagelle, MVP, Badge, Palloni,
Obiettivi di squadra, Infortuni, Notifiche: chiudono il debito di
documentazione tracciato in TODO.md (DD-002). Le sei route API
pubbliche vengono descritte dentro il modulo a cui appartengono.
davideandClaude Sonnet 5