From 224bb93bebc5909040f46c62c9785b5e0b72ccac Mon Sep 17 00:00:00 2001 From: Davide Grilli Date: Thu, 3 Sep 2026 10:17:13 +0200 Subject: [PATCH] =?UTF-8?q?Chiude=20DD-015:=20la=20rosa=20non=20=C3=A8=20p?= =?UTF-8?q?i=C3=B9=20hardcoded?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Aggiorna DESIGN_DECISIONS.md (DD-015 da "In valutazione" ad "Accettata", con le conseguenze reali: fallback nascita e crapp-data.ts come solo seed/fallback), DATABASE.md, ARCHITECTURE.md e PROJECT_STATE.md di conseguenza. --- PROJECT_STATE.md | 7 ++++++- docs/ARCHITECTURE.md | 5 +++-- docs/DATABASE.md | 2 +- docs/DESIGN_DECISIONS.md | 36 +++++++++++++++++++++++++----------- 4 files changed, 35 insertions(+), 15 deletions(-) diff --git a/PROJECT_STATE.md b/PROJECT_STATE.md index 262c305..a249790 100644 --- a/PROJECT_STATE.md +++ b/PROJECT_STATE.md @@ -1,6 +1,6 @@ # Project State -Ultimo aggiornamento: 02/09/2026 +Ultimo aggiornamento: 03/09/2026 ## Stato generale @@ -41,6 +41,11 @@ sincronizzano tra dispositivi tramite Supabase. - `public.giocatori_squadra`: 17 giocatori iniziali presenti; solo 2 hanno l'email registrata (`email`, migration `m5_email_giocatori_squadra`, DD-018) — le altre 15 arriveranno con una migration futura +- `public.giocatori_squadra` è ora la source of truth della rosa letta dall'app (DD-015, + 03/09/2026): «Aggiungi giocatore» e «Disattiva giocatore» della dashboard admin si + riflettono su Squadra, Presenze, Pagelle, Badge e Scout. `src/lib/crapp-data.ts` resta + solo come seed storico, fallback offline e sorgente della data di nascita (colonna non + ancora presente su `giocatori_squadra`) - Migration `m6_avatar_giocatori`: bucket pubblico `avatar-giocatori` per le foto profilo, al posto di `localStorage` (una per giocatore, letto da `src/lib/avatar-store.ts`) - Migration `m7_scout_partite`: nuova tabella `scout_partite` per l'archivio delle partite diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md index f7ff3a6..385e6d9 100644 --- a/docs/ARCHITECTURE.md +++ b/docs/ARCHITECTURE.md @@ -78,8 +78,9 @@ Vincoli di efficienza cloud — niente polling, cache lunga, `setQueryData` inve Badge e statistiche sono calcolati a runtime dai dati, non persistiti (DD-007). La gamification deve restare equa tra ruoli (DD-008). -La rosa è tuttora **hardcoded** in `src/lib/crapp-data.ts` (`rosaCSI`); la migrazione verso -la tabella `giocatori_squadra` è in corso — vedi DD-015 e DD-016. +La rosa vive nella tabella `giocatori_squadra`, letta tramite `useRosa()`/`useGiocatoriSquadra()` +(DD-015, DD-016). `src/lib/crapp-data.ts` (`rosaCSI`) resta solo come seed storico e fallback +quando il database non risponde. ## UI diff --git a/docs/DATABASE.md b/docs/DATABASE.md index 2a8ab16..985db3e 100644 --- a/docs/DATABASE.md +++ b/docs/DATABASE.md @@ -9,7 +9,7 @@ non in questo file. | Tabella | Scopo | Note | | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `giocatori_squadra` | Anagrafica operativa della squadra, con ID testuali (`g1`…`gN`), dati gestiti dagli admin (nome, cognome, numero, ruolo), collegamento all'account (`auth_user_id`) ed email registrata (`email`). | Introdotta dalla migration `m1_giocatori_squadra`, già popolata (17 giocatori) ma **non ancora letta dal codice**: la rosa arriva tuttora da `src/lib/crapp-data.ts`, che resta il fallback anche dopo il passaggio. Destinata a diventare la source of truth. Vedi DD-015 e DD-016. La colonna `email` (migration `m5_email_giocatori_squadra`) è la chiave del collegamento automatico account↔giocatore al primo accesso (DD-018): NULL finché non nota, oggi impostata solo per 2 dei 17 giocatori. Le colonne `numero_tessera`/`data_tessera` (migration `m8_tesseramento_csi`) tracciano chi è già tesserato al CSI; come `numero`/`ruolo` le scrive solo un admin, il trigger di M1/M5 le include tra i campi bloccati per chi reclama il proprio slot. | +| `giocatori_squadra` | Anagrafica operativa della squadra, con ID testuali (`g1`…`gN`), dati gestiti dagli admin (nome, cognome, numero, ruolo), collegamento all'account (`auth_user_id`) ed email registrata (`email`). | Introdotta dalla migration `m1_giocatori_squadra`, source of truth della rosa (DD-015): `useRosa()` e gli altri punti che elencano i giocatori la leggono tramite `useGiocatoriSquadra()` (client) o `leggiGiocatoriSquadra()` (server), filtrando `attivo`. `src/lib/crapp-data.ts` resta solo come seed storico e fallback (`rosaFallback()`) quando il database non risponde, e come sorgente della data di nascita (non ancora una colonna di questa tabella). Vedi DD-015 e DD-016. La colonna `email` (migration `m5_email_giocatori_squadra`) è la chiave del collegamento automatico account↔giocatore al primo accesso (DD-018): NULL finché non nota, oggi impostata solo per 2 dei 17 giocatori. Le colonne `numero_tessera`/`data_tessera` (migration `m8_tesseramento_csi`) tracciano chi è già tesserato al CSI; come `numero`/`ruolo` le scrive solo un admin, il trigger di M1/M5 le include tra i campi bloccati per chi reclama il proprio slot. | | `giocatori` | Anagrafica giocatori con UUID. | Presente ma **non usata** dal codice attuale: la convergenza è rinviata (DD-012, DD-014). | | `profili_giocatore` | Dati personali, metadati del documento d'identità, certificato medico e path dei file, in relazione 1:1 con `giocatori_squadra`. | Creata dalla migration `m2_profili_giocatore` (DD-016). Letta da `src/lib/profili.ts`; le policy mostrano al giocatore solo il proprio profilo e all'admin tutti. I file non stanno qui: la tabella conserva i path nel bucket. | | `user_roles` | Ruoli applicativi (es. amministratore, giocatore). | Fonte dei permessi di amministrazione, letta da `src/lib/ruoli.ts` (DD-011). Il primo admin va inserito a mano; vedi [PROJECT_STATE.md](../PROJECT_STATE.md). | diff --git a/docs/DESIGN_DECISIONS.md b/docs/DESIGN_DECISIONS.md index 7c50183..f94232a 100644 --- a/docs/DESIGN_DECISIONS.md +++ b/docs/DESIGN_DECISIONS.md @@ -31,6 +31,7 @@ Serve a rispondere a domande del tipo: | [DD-011](#dd-011--autenticazione-reale-prima-del-profilo-amministrativo-completo) | Auth reale prima del profilo | | [DD-012](#dd-012--non-migrare-gli-id-giocatore-in-v11) | Non migrare ID in v1.1 | | [DD-013](#dd-013--portabilità-lapp-non-deve-dipendere-da-servizi-esclusivi) | Portabilità dello stack | +| [DD-015](#dd-015--rosa-anagrafica-da-codice-hardcoded-a-database) | Rosa da hardcoded a DB | | [DD-016](#dd-016--schema-dati-profilo-giocatore-v11-f0) | Schema dati Profilo Giocatore v1.1 | | [DD-017](#dd-017--lamministratore-può-compilare-i-dati-al-posto-del-giocatore) | L'admin scrive al posto del giocatore | | [DD-018](#dd-018--collegamento-automatico-giocatoreaccount-per-email) | Collegamento automatico per email | @@ -40,7 +41,6 @@ Serve a rispondere a domande del tipo: | ID | Titolo | | ----------------------------------------------------------------- | ---------------------- | | [DD-014](#dd-014--convergenza-schema-database-eventi-e-presenze) | Convergenza schema DB | -| [DD-015](#dd-015--rosa-anagrafica-da-codice-hardcoded-a-database) | Rosa da hardcoded a DB | --- @@ -455,7 +455,7 @@ Regole vincolanti: **Conseguenze** - Coesistono temporaneamente tre rappresentazioni dell’anagrafica: `crapp-data.ts` (fallback), `giocatori_squadra` (target), `giocatori` UUID (dormiente). -- `src/lib/rosa.ts` dovrà leggere prima dal database e ricadere su `crapp-data.ts` in caso di errore o assenza dati. +- `src/lib/rosa.ts` legge dal database e ricade su `crapp-data.ts` in caso di errore o assenza dati (DD-015). - Il completamento profilo (30/30/30/10) si calcola in app, non si persiste nel database. - Lo storico certificati non viene conservato in v1 (coerente con DD-010). - Le migration M1–M3 (tabelle, RLS, bucket) restano **additive**: solo `CREATE`, nessun `ALTER`/`DROP` su schema esistente. @@ -563,19 +563,33 @@ Post v1.1, con migration e test dedicati. ### DD-015 — Rosa anagrafica: da codice hardcoded a database -**Data:** — -**Stato:** In valutazione +**Data:** 3 settembre 2026 +**Stato:** Accettata **Contesto** -La lista giocatori vive ancora nel codice sorgente. Il database ha già una tabella popolata ma non usata. +La lista giocatori viveva nel codice sorgente (`src/lib/crapp-data.ts`). Il database aveva già +`giocatori_squadra` (migration M1) popolata ma non letta da nessuna schermata tranne +`/benvenuto` e `/admin`: «Aggiungi giocatore» e «Disattiva giocatore» della dashboard non +avevano effetto su Squadra, Presenze, Pagelle, Badge e Scout, mantenendo gli stessi ID finché +non si farà DD-012. -**Decisione proposta** -Spostare l’anagrafica su database, mantenendo gli stessi ID finché non si fa DD-012. +**Decisione** +`useRosa()` (e con lei `useIo`, `useObiettivi`) legge ora `giocatori_squadra` tramite +`useGiocatoriSquadra()`, filtrando solo i giocatori `attivo`. Tutti i punti che prima +importavano la lista statica (`convocatiEvento`, `compleanniEventi`, `completaTurni`, +`csvScoutMatch`, i widget di voto/scout/palloni, le due route API che mandano push) sono stati +agganciati allo stesso hook o, lato server, a `leggiGiocatoriSquadra()` +(`src/lib/giocatori-squadra.server.ts`, stesso pattern di `eventi.server.ts`). -**Perché non ora** -Il profilo v1.1 può agganciarsi agli ID attuali; la migrazione rosa può essere fase 2. +**Conseguenze** -**Riesame previsto** -In parallelo o subito dopo il rollout auth. +- Un giocatore aggiunto o disattivato dalla dashboard admin ora si riflette ovunque, non solo + in `/benvenuto` e `/admin`. +- `giocatori_squadra` non ha ancora una colonna per la data di nascita: per i 17 giocatori + storici resta quella di `crapp-data.ts` (`nascitaPerId`, lookup per id); un giocatore + aggiunto dopo la migrazione non ha nascita nota finché la colonna non esiste. Follow-up da + aprire quando serve davvero. +- `src/lib/crapp-data.ts` resta come seed storico e fallback (`rosaFallback()`), non più come + fonte viva. ---