diff --git a/PROJECT_STATE.md b/PROJECT_STATE.md index d61a322..4464f28 100644 --- a/PROJECT_STATE.md +++ b/PROJECT_STATE.md @@ -1,6 +1,6 @@ # Project State -Ultimo aggiornamento: 06/10/2026 +Ultimo aggiornamento: 26/10/2026 Questo file dice **a che punto siamo ora**. Le funzionalità stanno in [docs/ROADMAP.md](docs/ROADMAP.md), i rilasci in [docs/CHANGELOG.md](docs/CHANGELOG.md), lo @@ -9,27 +9,35 @@ schema in [docs/DATABASE.md](docs/DATABASE.md), le procedure in ## Stato generale -- **Versione:** 1.4.2 (in produzione su `main` la 1.3.0, tag `v1.3.0`) — ogni evento può avere un link - Google Maps del luogo, mostrato come «Apri su Maps» nelle schede (`m34`). La 1.4.1: gli eventi con - convocati si vedono solo ai convocati (admin e allenatori sempre) e «Rosa e presenze» elenca solo - loro. La 1.4.0: avviso «Presenza modificata» ad admin e - allenatori (DD-050, `m32`-`m33`). La 1.3.1: il Calendario mostra solo i prossimi - compleanni del mese; tolta la serie «Conferme 24h» con i badge «Risposta lampo» e «Mai un forfait». La 1.3.0 - portava la notifica di compleanno, gli obiettivi cliccabili, le presenze sui convocati, gli avvisi in Home - ridisegnati e i caratteri più grandi. Dettaglio in [docs/CHANGELOG.md](docs/CHANGELOG.md). +- **Versione:** 1.4.2 in produzione su `main` (tag `v1.4.2`): ogni evento può avere un link Google + Maps del luogo, mostrato come «Apri su Maps» nelle schede (`m34`). Su `feature/gara` c'è del lavoro + non ancora rilasciato (voto MVP, vedi «Lavoro in corso»). La 1.4.1: gli eventi con convocati si + vedono solo ai convocati (admin e allenatori sempre) e «Rosa e presenze» elenca solo loro. La 1.4.0: + avviso «Presenza modificata» ad admin e allenatori (DD-050, `m32`-`m33`). La 1.3.1: il Calendario + mostra solo i prossimi compleanni del mese; tolta la serie «Conferme 24h» con i badge «Risposta + lampo» e «Mai un forfait». La 1.3.0 portava la notifica di compleanno, gli obiettivi cliccabili, le + presenze sui convocati, gli avvisi in Home ridisegnati e i caratteri più grandi. Dettaglio in + [docs/CHANGELOG.md](docs/CHANGELOG.md). - **Backend:** Supabase proprietario (`kfkcldwncxqaixetsjes`). Lovable Cloud e il vecchio Project Ref `hetycilxgkdmccelwerq` non si usano più. -- **Migration:** 45 file in `supabase/migrations/`, fino a `m34_link_maps_evento` (colonna `eventi_app.link_maps`, applicata il 26/10/2026). Tutte applicate in produzione (verificato con `npx supabase migration list` il - 26/10/2026; la `m32` è l'avviso «Presenza modificata» ai soli admin, DD-050). La `m33`, che lo estende agli allenatori, è stata applicata il 09/10/2026. La `m29` toglie - `foto_path`: il codice che non la legge più (1.2.2) va rilasciato. +- **Migration:** 49 file in `supabase/migrations/`, fino a `m38_nome_votato_badge_social`. In produzione + sono applicate 45 su 49, fino alla `m34_link_maps_evento` (verificato con + `npx supabase migration list --linked` il 26/10/2026: le uniche mancanti sono `m35`-`m38`, nessuna + migration remota è assente dal repository). **Da applicare ancora: `m35`-`m38`** + (voto MVP e badge social, DD-051 e DD-052, branch `feature/gara`): `npx supabase db push` è rinviato + per scelta, non è stato eseguito. Vanno applicate subito prima del rilascio del codice: con le sole + migration il voto MVP dell'app in produzione (1.4.2) smette di funzionare, con il solo codice la + vista dei conteggi non esiste. - **Worker delle notifiche** (`mailer/`): in funzione su un Raspberry Pi con Docker dal 29/09/2026 ([docs/WORKER_EMAIL.md](docs/WORKER_EMAIL.md)). Il codice con l'interruttore «Email» in Profilo è su `main` dalla 1.3.0. - **Accesso:** il login Google è l'unica via d'ingresso; i permessi di amministrazione arrivano solo da `user_roles`. Il collegamento degli account è un processo continuo: ogni giocatore si collega al primo accesso (DD-018). -- **Lavoro in corso:** niente di assegnato. Le voci aperte stanno in - [docs/ROADMAP.md](docs/ROADMAP.md), sotto «Prossimo». +- **Lavoro in corso:** branch `feature/gara` per le funzioni di gara (correzioni e nuove + funzioni; in futuro anche lo scouting). Primo lavoro: il voto MVP definitivo, segreto, a tempo e + tra presenti, con i pari merito (DD-051, DD-052). Non ancora in `main`, non rilasciato, versione + invariata. Le altre voci aperte stanno in [docs/ROADMAP.md](docs/ROADMAP.md), sotto «Prossimo». ## Cose da sapere diff --git a/docs/CHANGELOG.md b/docs/CHANGELOG.md index b2ada9e..8bc2876 100644 --- a/docs/CHANGELOG.md +++ b/docs/CHANGELOG.md @@ -13,6 +13,29 @@ versioni `0.y.z` erano pre-release. ## [Non rilasciato] +Quattro migration, da `m35` a `m38`, **non ancora applicate in produzione**. + +### Modificato + +- Il voto MVP è definitivo ([DD-051](decisions/DD-051.md)): si sceglie un nome, si conferma e non si + può più cambiare. Il database lo impone (solo gli admin possono correggere un voto). +- In caso di parità in testa gli MVP sono più d'uno: ognuno dei pari merito conta un titolo, e in + Home e Classifica compaiono i nomi uniti («Anna e Bruno»). Resta il minimo di 2 voti per eleggere + un MVP. +- Il voto MVP è segreto ([DD-052](decisions/DD-052.md)): nessuno vede chi ha votato chi, solo i + conteggi e il proprio voto. +- La votazione MVP si chiude 24 ore dopo l'apertura (cioè 26 ore dopo l'inizio della partita): le + partite più vecchie non si votano più. + +### Sicurezza + +- Il database impone anche le regole che prima valevano solo nell'app: il voto MVP è possibile solo per + una partita, tra presenti (`presente` o `ritardo`) e dopo 2 ore dall'inizio (`m36`, + [DD-051](decisions/DD-051.md)). Gli admin possono ancora correggere un voto. +- Il nome del votato lo scrive il database dalla rosa, per i voti MVP (`m37`) e per i badge social + (`m38`): un client non può più salvare un nome diverso da quello del giocatore votato. In + produzione non risultavano voti MVP, quindi nessun dato da bonificare. + ## [1.4.2] - 2026-10-26 Link Google Maps del luogo degli eventi. Una migration, `m34`, applicata in produzione il diff --git a/docs/DATABASE.md b/docs/DATABASE.md index 78ed8a5..6d50370 100644 --- a/docs/DATABASE.md +++ b/docs/DATABASE.md @@ -12,21 +12,21 @@ allenatore di `m21_ruolo_allenatore` (DD-034). La **lettura** resta aperta a tutti gli autenticati su ogni tabella di questo elenco, con le eccezioni della sezione «Lettura» qui sotto; `anon` non arriva a nessuna di esse da M4 (DD-011). -| Tabella | Chi può scrivere | -| ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `eventi_app` | admin e allenatori (nell'app li gestisce la rotta `/eventi`, riservata a loro) | -| `risposte_presenze`, `cacche_partita` | il giocatore sulla propria riga (`giocatore_id`), mai l'allenatore (M21), più gli admin | -| `pagelle_voti`, `mvp_voti`, `badge_social_voti` | il votante sui propri voti (`votante_id`), se votante e votato sono convocati all'evento (`m13`) e nessuno dei due è un allenatore (`m21`); solo per le pagelle anche `pagelle_chiuse = false`; gli admin senza questi vincoli | -| `turni_palloni`, `scout_sessioni`, `scout_live`, `scout_partite` | qualsiasi autenticato: nell'interfaccia non hanno gate | -| `notifiche_utente` | nessuno scrive da client: le righe nascono da trigger/funzioni `SECURITY DEFINER` o dalla service role (M17); il giocatore può solo segnare come lette le proprie | -| `notifiche_email_coda` | nessuno da client, né in lettura né in scrittura: la riempie il trigger `accoda_notifica_email` e la gestisce solo il worker email con la service role (M22) | -| `preferenze_utente` | l'utente sulla propria riga (`auth_user_id = auth.uid()`), in lettura e scrittura (M22) | -| `promemoria_eventi_generati` | nessuno da client, né in lettura né in scrittura: la scrive solo la funzione `genera_promemoria_eventi()` dei cron (M23) | -| `compleanni_notificati` | Registro degli avvisi di compleanno già generati, per destinatario e giorno. | Chiave `(giocatore_id, giorno)`, `ON DELETE CASCADE` verso il giocatore (DD-029, DD-047, M31). Non è legato a un evento. Eliminare la notifica non fa rigenerare l'avviso. | -| `notifiche_push_coda` | nessuno da client, né in lettura né in scrittura: la riempie il trigger `accoda_push_promemoria` e la gestisce solo il worker con la service role (M24) | -| `profili_giocatore` | il giocatore sul proprio profilo, admin su tutti (DD-016, DD-017) | -| `giocatori_squadra` | admin; il giocatore può solo reclamare uno slot libero (DD-016); l'allenatore anche cambiare nome e cognome del proprio slot (M21) | -| `user_roles` | solo admin; la riga `allenatore` la scrive il trigger `sincronizza_ruolo_allenatore` (M21) | +| Tabella | Chi può scrivere | +| ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `eventi_app` | admin e allenatori (nell'app li gestisce la rotta `/eventi`, riservata a loro) | +| `risposte_presenze`, `cacche_partita` | il giocatore sulla propria riga (`giocatore_id`), mai l'allenatore (M21), più gli admin | +| `pagelle_voti`, `mvp_voti`, `badge_social_voti` | il votante sui propri voti (`votante_id`), se votante e votato sono convocati all'evento (`m13`) e nessuno dei due è un allenatore (`m21`); solo per le pagelle anche `pagelle_chiuse = false`; gli admin senza questi vincoli. Su `mvp_voti` (`m35`-`m37`, DD-051, DD-052) il giocatore può solo inserire il voto, per una partita aperta al voto (da 2 a 26 ore dopo l'inizio) e tra presenti (`voto_mvp_consentito()`), e leggere solo il proprio; modifica, cancellazione e lettura degli altri voti sono degli admin | +| `turni_palloni`, `scout_sessioni`, `scout_live`, `scout_partite` | qualsiasi autenticato: nell'interfaccia non hanno gate | +| `notifiche_utente` | nessuno scrive da client: le righe nascono da trigger/funzioni `SECURITY DEFINER` o dalla service role (M17); il giocatore può solo segnare come lette le proprie | +| `notifiche_email_coda` | nessuno da client, né in lettura né in scrittura: la riempie il trigger `accoda_notifica_email` e la gestisce solo il worker email con la service role (M22) | +| `preferenze_utente` | l'utente sulla propria riga (`auth_user_id = auth.uid()`), in lettura e scrittura (M22) | +| `promemoria_eventi_generati` | nessuno da client, né in lettura né in scrittura: la scrive solo la funzione `genera_promemoria_eventi()` dei cron (M23) | +| `compleanni_notificati` | Registro degli avvisi di compleanno già generati, per destinatario e giorno. | Chiave `(giocatore_id, giorno)`, `ON DELETE CASCADE` verso il giocatore (DD-029, DD-047, M31). Non è legato a un evento. Eliminare la notifica non fa rigenerare l'avviso. | +| `notifiche_push_coda` | nessuno da client, né in lettura né in scrittura: la riempie il trigger `accoda_push_promemoria` e la gestisce solo il worker con la service role (M24) | +| `profili_giocatore` | il giocatore sul proprio profilo, admin su tutti (DD-016, DD-017) | +| `giocatori_squadra` | admin; il giocatore può solo reclamare uno slot libero (DD-016); l'allenatore anche cambiare nome e cognome del proprio slot (M21) | +| `user_roles` | solo admin; la riga `allenatore` la scrive il trigger `sincronizza_ruolo_allenatore` (M21) | L'identità del giocatore è lo slot di `giocatori_squadra` con `auth_user_id = auth.uid()`. La tabella è verificata da `test/integration/permessi.test.ts` contro il database locale. @@ -95,11 +95,11 @@ Colonne di `giocatori_squadra` che meritano una nota: Per tutte: un voto per votante e partita (per categoria nei badge social), auto-voto rifiutato, votante e votato convocati all'evento (RLS, `evento_permette_voto()`, DD-027). -| Tabella | Scopo | Note | -| ------------------- | ---------------------------------- | --------------------------------------------------------------------- | -| `mvp_voti` | Voti MVP assegnati a fine partita. | Vincolo `mvp_no_autovoto`. | -| `pagelle_voti` | Voti anonimi ai giocatori (1-10). | Usati per il voto medio. Si scrive solo con `pagelle_chiuse = false`. | -| `badge_social_voti` | Voti social per i badge. | Vincolo `badge_social_no_autovoto`. | +| Tabella | Scopo | Note | +| ------------------- | ---------------------------------- | --------------------------------------------------------------------------------- | +| `mvp_voti` | Voti MVP assegnati a fine partita. | Vincolo `mvp_no_autovoto`; voto definitivo per i giocatori (`m35`). | +| `pagelle_voti` | Voti anonimi ai giocatori (1-10). | Usati per il voto medio. Si scrive solo con `pagelle_chiuse = false`. | +| `badge_social_voti` | Voti social per i badge. | Vincolo `badge_social_no_autovoto`; `votato_nome` dal trigger sulla rosa (`m38`). | ## Turni e notifiche diff --git a/docs/decisions/DD-051.md b/docs/decisions/DD-051.md new file mode 100644 index 0000000..795a49a --- /dev/null +++ b/docs/decisions/DD-051.md @@ -0,0 +1,45 @@ +# DD-051 — Voto MVP definitivo e MVP a pari merito + +**Data:** 26 ottobre 2026 +**Stato:** Accettata (migration `m35` e `m36`) + +**Contesto** +Il voto MVP si poteva cambiare senza limiti e senza storico (`mvp.md`), e una parità in testa non +assegnava l'MVP a nessuno finché non arrivavano altri voti. Con voti modificabili la classifica di una +partita poteva ribaltarsi dopo che la squadra l'aveva già vista; e una parità, che a fine serata non si +risolve più perché nessuno vota ancora, lasciava la partita senza MVP per sempre. + +**Decisione** + +- **Il voto è definitivo.** Il giocatore lo registra una volta sola per partita. L'interfaccia chiede una + conferma prima di inviarlo e non offre più «Cambia voto»; la mutazione è un `INSERT` e un secondo voto + viene rifiutato dal vincolo `UNIQUE (match_id, votante_id)`. A database (`m35`) il giocatore ha solo la + policy di `INSERT`: `UPDATE` e `DELETE` restano agli admin (policy di M11), che possono correggere un + voto sbagliato. +- **Una parità in testa dà più MVP.** `mvpPartita()` restituisce tutti i più votati; ognuno conta un + titolo in `mvpVintiPerGiocatore()`, e dove si mostra un solo nome per partita (Home, Classifica) + i nomi sono uniti («Anna e Bruno»). Il quorum di DD-028 (`VOTI_MINIMI_MVP = 2`) resta: sotto due voti + totali nessuno è MVP. + +- **Presenza e orario a database (`m36`).** Il voto MVP richiede, oltre a convocati e non-allenatori, che + l'evento sia una partita, che votante e votato siano `presente` o `ritardo` e che siano passate 2 ore + dall'inizio. Sta in una funzione dedicata, `voto_mvp_consentito()`, perché `evento_permette_voto()` è + condivisa con pagelle e badge social, che non hanno queste regole. Gli admin restano esclusi dai + vincoli. + +**Alternative scartate** + +- Lasciare il voto modificabile entro una scadenza → serve una scadenza che non esiste (`mvp.md`, + «Evoluzioni possibili») e un cambio di idea tardivo resta possibile. +- Spareggio con un criterio automatico (media pagella, presenze) → introduce regole nascoste che i + giocatori non vedono; il pari merito è il risultato più semplice da spiegare. + +**Conseguenze** + +- Un voto dato per errore si corregge solo da un admin. +- I voti già dati restano, ma le partite con una parità in testa assegnano ora i titoli: i conteggi MVP + dei giocatori possono salire (badge «MVP» e «Uomo tie-break» compresi). +- Con tre o più pari merito (per esempio tre voti a tre persone diverse) gli MVP sono tre. + +**Riesame** +Se i pari merito risultano troppo frequenti, alzare il quorum (DD-028) o introdurre uno spareggio. diff --git a/docs/decisions/DD-052.md b/docs/decisions/DD-052.md new file mode 100644 index 0000000..c9f251a --- /dev/null +++ b/docs/decisions/DD-052.md @@ -0,0 +1,44 @@ +# DD-052 — Voto MVP segreto, nome dal database e votazione che si chiude + +**Data:** 26 ottobre 2026 +**Stato:** Accettata (migration `m37` e `m38`) + +**Contesto** +Dopo DD-051 il voto è definitivo e controllato a database, ma restavano tre difetti: chiunque poteva +leggere da `mvp_voti` chi aveva votato chi; `votato_nome` lo scriveva il client e poteva non +corrispondere a `votato_id` (il titolo andava all'id, il nome mostrato era un altro); e la votazione, +una volta aperta, non si chiudeva mai. + +**Decisione** + +- **Voto segreto.** La lettura diretta di `mvp_voti` è del solo votante (il proprio voto) e degli admin. + La squadra legge i conteggi dalla vista `mvp_voti_anonimi`, una riga per voto senza `votante_id` e + ordinata per candidato (la sequenza di arrivo non rivela nulla). La vista gira con i permessi del + proprietario: è ciò che le permette di leggere tutte le righe senza esporre chi ha votato. Non è + leggibile senza account. +- **Nome dal database.** Un trigger riempie `votato_nome` da `giocatori_squadra` a partire da + `votato_id`, ignorando quello inviato (anche se omesso, vuoto o diverso; e anche quando un admin corregge + un voto). Se l'id non è in rosa resta il nome ricevuto. Lo stesso trigger vale per i badge social + (`m38`), che avevano lo stesso difetto; le pagelle non hanno un nome del votato. +- **Chiusura.** Il voto si apre 2 ore dopo l'inizio della partita e si chiude 24 ore dopo l'apertura + (cioè 26 ore dopo l'inizio). A database lo impone `voto_mvp_consentito()`; nell'app `votoMvpChiuso()`. + Gli admin restano fuori dal vincolo. +- **Tutte le partite.** Il voto vale per ogni evento di tipo partita, amichevoli comprese (invariato). + +**Alternative scartate** + +- Filtrare i voti solo nell'app → chi scrive su PostgREST li leggerebbe comunque. +- Togliere la lettura anche agli admin → non potrebbero più correggere un voto sbagliato; restano gli + unici a poter leggere la tabella, e l'app non mostra a nessuno chi ha votato chi. +- Chiudere 24 ore dopo l'inizio della partita (22 ore di voto) → si è scelto 24 ore piene dall'apertura. + +**Conseguenze** + +- Le partite già chiuse da più di 26 ore non si votano più: chi non aveva votato perde la possibilità. + I voti già dati restano e contano. +- I conteggi restano visibili durante la votazione: chi vota può vedere chi è in testa. +- Un admin che legge la tabella dal database vede ancora chi ha votato chi. + +**Riesame** +Se si vuole un voto davvero cieco, nascondere i risultati fino alla chiusura (la chiusura a 24 ore lo +rende possibile). diff --git a/docs/decisions/README.md b/docs/decisions/README.md index f78a0f8..c7db000 100644 --- a/docs/decisions/README.md +++ b/docs/decisions/README.md @@ -87,6 +87,8 @@ Una decisione sostituita non si cancella: si cambia il suo **Stato** e si rimand | [DD-039](DD-039.md) | Niente promemoria all'allenatore | | [DD-040](DD-040.md) | Palloni e solleciti automatici | | [DD-050](DD-050.md) | Avviso se una presenza cambia a meno di 6 ore dall'evento | +| [DD-051](DD-051.md) | Voto MVP definitivo e MVP a pari merito | +| [DD-052](DD-052.md) | Voto MVP segreto, nome dal database e chiusura | | [DD-049](DD-049.md) | Caratteri più grandi in tutta l'app | | [DD-048](DD-048.md) | Via la tessera dalla dashboard | | [DD-047](DD-047.md) | Notifica di compleanno | diff --git a/docs/modules/mvp.md b/docs/modules/mvp.md index 60b7284..00e43fd 100644 --- a/docs/modules/mvp.md +++ b/docs/modules/mvp.md @@ -2,6 +2,7 @@ **Stato:** implementato **File principali:** `src/lib/mvp-voti.ts`, `src/components/crapp/VotazioneMvp.tsx` +**Test:** `test/unit/mvp-voti.test.ts`, `test/integration/permessi.test.ts` (regole del voto), `mvp-badge`, `s-tiebreak-badge` --- @@ -15,7 +16,10 @@ calcolato a runtime. ## Dati Tabella `mvp_voti`, vincolo `UNIQUE (match_id, votante_id)` — un solo voto per giocatore per -partita, sovrascrivibile. +partita, **definitivo** (DD-051) e **segreto** (DD-052): la tabella la legge solo chi ha votato (il +proprio voto) e gli admin; la squadra legge i conteggi dalla vista `mvp_voti_anonimi` (`match_id`, +`votato_id`, `votato_nome`, senza `votante_id`). `votato_nome` lo riempie un trigger dalla rosa a +partire da `votato_id`: il nome inviato dal client è ignorato. `match_id` è l'**id dell'evento CrAPP**, non quello del referto CSI né dello Scout: la votazione non dipende più da nessuna delle due fonti (i voti scritti prima con l'id scout/CSI @@ -27,44 +31,59 @@ restano nel database ma non vengono più letti da nessuna schermata). - Il pannello sta in `partita.$id.tsx` in una sezione sua, sempre presente: `votoMvpAperto()` lo apre `ORE_ATTESA_MVP` (2) ore dopo `data`+`ora` dell'evento, prima di allora mostra solo - quando aprirà. Nessun legame con il risultato caricato. + quando aprirà; `votoMvpChiuso()` lo chiude `DURATA_VOTO_MVP_ORE` (24) ore dopo l'apertura + (DD-052). A votazione chiusa il pannello mostra «Votazione chiusa» e i risultati, senza il + pulsante «Vota». Nessun legame con il risultato caricato. - Votano e sono votabili solo i **presenti** di quell'evento (`presente` o `ritardo` in `usePresenzeEvento`): chi non c'era ha il bottone disabilitato e non compare nell'elenco. -- `useVotaMvp()` fa upsert `onConflict: match_id, votante_id`: il voto è modificabile senza - limiti, senza storico. +- `useVotiMvp()` legge i conteggi dalla vista `mvp_voti_anonimi`; `useMieiVotiMvp()` legge dalla + tabella solo i voti dell'utente (gli unici che la policy gli lascia), per «Hai votato X». +- `useVotaMvp()` fa un `INSERT`: il voto è definitivo. Il pannello chiede di scegliere un nome e di + confermarlo, poi mostra «Hai votato X: il voto non si può cambiare». A database (`m35`, DD-051) il + giocatore ha solo la policy di `INSERT`: modificare o cancellare un voto è possibile solo agli admin. - 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. -- `vincitoriMvp()`/`mvpVintiPerGiocatore()` richiedono anche un quorum minimo di voti totali +- `mvpPartita()` restituisce i più votati: **in caso di parità in testa sono tutti MVP a pari merito** + (DD-051). `vincitoriMvp()` ne unisce i nomi («Anna e Bruno») per Home e Classifica. +- `mvpPartita()` (quindi anche `vincitoriMvp()` e `mvpVintiPerGiocatore()`) richiede un quorum minimo di voti totali sulla partita (`VOTI_MINIMI_MVP = 2`, `mvp-voti.ts`, DD-028): un solo voto non basta a incoronare nessuno, nemmeno senza concorrenza. -- `mvpVintiPerGiocatore()` conta una vittoria per ogni partita "vinta" con margine netto; il - risultato alimenta il campo `mvp` del `Giocatore` in `useRosa()`, mostrato come StatTile +- `mvpVintiPerGiocatore()` conta una vittoria per ogni partita in cui il giocatore è tra i più votati + (anche a pari merito); 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: una volta aperta resta aperta indefinitamente. +- Il voto si chiude 24 ore dopo l'apertura (DD-052). Le partite più vecchie sono quindi chiuse: + chi non aveva votato non può più farlo. Gli admin possono ancora scrivere un voto dal database. +- Gli admin leggono la tabella `mvp_voti` (gli serve per correggere un voto), quindi a livello di + database vedono chi ha votato chi; l'app non lo mostra a nessuno. +- I conteggi sono visibili anche durante la votazione. Nascondere i risultati fino alla chiusura è una + possibile evoluzione. - 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 diretto è che non sia il votante stesso (`mvp_no_autovoto`). Da `m13_convocati_e_pagelle_chiuse` la stessa policy verifica anche che **sia il votante sia il votato** siano tra i **convocati** dell'evento (`evento_permette_voto()`, convocati vuoto - = tutta la rosa): prima era un filtro solo applicativo, ora un giocatore non convocato non - può più votare né essere votato scrivendo direttamente su PostgREST. Restano invece solo - applicativi, non controllati da nessuna policy: che votante e votato fossero **presenti** - (non solo convocati: `presente`/`ritardo` in `usePresenzeEvento`, un controllo più stretto - della sola convocazione) a quella partita, e le due ore d'attesa dall'inizio evento - (`votoMvpAperto()`) — un amministratore, o chiunque scriva su PostgREST, passa comunque. -- In caso di parità, o sotto il quorum minimo di voti, nessun MVP viene assegnato per quella - partita. + = tutta la rosa). Da `m36` (DD-051) la policy usa `voto_mvp_consentito()`, che aggiunge a quei + controlli: l'evento è una **partita**, votante e votato hanno risposto `presente` o `ritardo` e + sono passate **2 ore** dall'inizio e **non ancora altre 24** (`Europe/Rome`; un `ora` vuoto + vale mezzanotte). Sono le stesse + regole del pannello, ora imposte anche a chi scrive direttamente su PostgREST; l'attesa di 2 ore + e la chiusura stanno in `ORE_ATTESA_MVP`/`DURATA_VOTO_MVP_ORE` e negli intervalli della funzione + (`m37`); un test unitario li tiene allineati. Gli + admin restano fuori da questi vincoli (possono correggere un voto). La presenza si controlla solo + al momento del voto: se qualcuno cambia risposta dopo, il voto già dato resta. +- Sotto il quorum minimo di voti nessun MVP viene assegnato per quella partita. Una parità in testa, + invece, assegna l'MVP a tutti i pari merito. +- Un voto sbagliato si corregge solo da un admin (dal database): non c'è un'interfaccia per farlo. --- ## Evoluzioni possibili -- Introdurre una scadenza (es. la votazione si chiude N giorni dopo la partita). +- Nascondere i risultati finché la votazione non è chiusa. +- Una schermata per gli admin per correggere un voto (oggi solo dal database).