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

1.9 KiB

Raw Blame History

Modulo — Votazione MVP

Stato: implementato (v1.0) File principali: src/lib/mvp-voti.ts, src/components/crapp/VotazioneMvp.tsx

Obiettivo

Eleggere il MVP di una partita tramite voto tra compagni, un voto a testa, con vincitore calcolato a runtime.

Dati

Tabella mvp_voti, vincolo UNIQUE (match_id, votante_id) — un solo voto per giocatore per partita, sovrascrivibile.

Implementazione

Il pannello compare in partita.$id.tsx solo se esiste un risultato (Scout Live salvato) per la partita, altrimenti mostra "la partita non è ancora stata disputata".
useVotaMvp() fa upsert onConflict: match_id, votante_id: il voto è modificabile senza limiti, senza storico.
Nessuno vota sé stesso: VotazioneMvp.tsx toglie il votante dall'elenco e il vincolo mvp_no_autovoto (migration m12_niente_autovoto) rifiuta la riga anche a chi scrive direttamente su PostgREST, come già faceva pagelle_no_autovoto per le pagelle.
conteggioPartita()/vincitoriMvp() richiedono un margine netto: in caso di parità, nessun vincitore viene assegnato per quella partita finché non arrivano altri voti.
mvpVintiPerGiocatore() conta una vittoria per ogni partita "vinta" con margine netto; il risultato alimenta il campo mvp del Giocatore in useRosa(), mostrato come StatTile nel profilo e in home.

Limiti noti

Nessuna scadenza o chiusura della votazione: resta aperta indefinitamente.
Il voto è legato a chi lo scrive: da m11_scritture_per_ruolo la policy impone che votante_id sia lo slot collegato all'account (DD-023). Su chi viene votato l'unico vincolo è che non sia il votante stesso (mvp_no_autovoto): che sia un convocato di quella partita resta un filtro solo applicativo.
In caso di parità, nessun MVP viene assegnato per quella partita.

Evoluzioni possibili

Introdurre una scadenza (es. la votazione si chiude N giorni dopo la partita).

1.9 KiB Raw Blame History