From 9c173df7534435db9950267a5dccc377e9fb7b4a Mon Sep 17 00:00:00 2001 From: Davide Grilli Date: Thu, 3 Sep 2026 11:00:27 +0200 Subject: [PATCH] Corregge riferimenti alla migration M3, mai applicata MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit M3 esisteva solo come bozza archiviata in docs/archive/migrations/: il bucket profili-giocatore è creato dalla migration M2 insieme alla tabella. Allinea PROJECT_STATE.md (12 -> 18 migration), DATABASE.md, CHANGELOG.md, TODO.md, DESIGN_DECISIONS.md, test/README.md e il test di integrazione dei profili. Co-Authored-By: Claude Sonnet 5 --- PROJECT_STATE.md | 6 +++--- docs/CHANGELOG.md | 3 +-- docs/DATABASE.md | 2 +- docs/DESIGN_DECISIONS.md | 2 +- docs/TODO.md | 2 +- test/README.md | 6 +++--- test/integration/schema-profili.test.ts | 14 +++++++------- 7 files changed, 17 insertions(+), 18 deletions(-) diff --git a/PROJECT_STATE.md b/PROJECT_STATE.md index a249790..639a5b4 100644 --- a/PROJECT_STATE.md +++ b/PROJECT_STATE.md @@ -6,7 +6,7 @@ Ultimo aggiornamento: 03/09/2026 Fase corrente: -Backend migrato al nuovo Supabase proprietario. M1 completata. M2 e M3 scritte e da applicare. +Backend migrato al nuovo Supabase proprietario. M1 completata. M2 scritta e da applicare. Autenticazione Google, dashboard amministratore e Profilo Giocatore (lato giocatore e lato admin) implementati su `develop`, da attivare in produzione seguendo i passaggi più sotto. Foto profilo (M6) e Scout Live (M7) non dipendono più da `localStorage`: entrambi ora @@ -20,7 +20,7 @@ sincronizzano tra dispositivi tramite Supabase. - Cursor come ambiente di sviluppo - Vercel configurato; Environment Variables aggiornate al nuovo Supabase (Preview e Production) - Supabase proprietario attivo — Project Ref: `kfkcldwncxqaixetsjes` -- 12 migration locali applicate con successo al nuovo database +- 18 migration locali applicate con successo al nuovo database - Sviluppo locale verificato con il nuovo Supabase - Preview Vercel di `develop` verificata con successo (presenza scritta su `risposte_presenze` confermata nel nuovo database) - Produzione (`main`): non ancora verificata in questa fase @@ -97,7 +97,7 @@ Passaggi in ordine, nessuno dei quali è reversibile a metà: `[auth.external.google]` di `supabase/config.toml`, le due variabili `SUPABASE_AUTH_GOOGLE_*` in `.env` e una credenziale con redirect URI `http://127.0.0.1:54321/auth/v1/callback`. -2. **Migration M2 e M3** (`supabase db push`). Sono `CREATE` puri: si possono applicare in +2. **Migration M2** (`supabase db push`). È un `CREATE` puro: si può applicare in produzione senza toccare il comportamento attuale. 3. **Primo admin**, dopo il primo login (l'ID esiste solo da quel momento): `INSERT INTO public.user_roles (user_id, role) SELECT id, 'admin' FROM auth.users WHERE email = '';` diff --git a/docs/CHANGELOG.md b/docs/CHANGELOG.md index 2d90b68..e92195e 100644 --- a/docs/CHANGELOG.md +++ b/docs/CHANGELOG.md @@ -39,8 +39,7 @@ qui: sta in [ROADMAP.md](ROADMAP.md). ([modules/profilo-giocatore.md](modules/profilo-giocatore.md)). - Nuova schermata `/admin`: stato dei profili della squadra, download di documento, certificato e foto tessera, export CSV per il tesseramento CSI. -- Migration `m2_profili_giocatore` (tabella dei profili) e `m3_bucket_profili` (bucket - privato), entrambe additive. +- Migration `m2_profili_giocatore` (tabella dei profili e bucket privato), additiva. - Dalla dashboard l'amministratore modifica i dati squadra (nome, cognome, numero, ruolo), compila i dati personali al posto di un giocatore e scollega un account da un profilo (DD-017). I file restano esclusi: li carica solo il giocatore. Nessuna migration: le diff --git a/docs/DATABASE.md b/docs/DATABASE.md index 985db3e..4f4462c 100644 --- a/docs/DATABASE.md +++ b/docs/DATABASE.md @@ -20,7 +20,7 @@ non in questo file. | Bucket | Scopo | Note | | ------------------- | ---------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `profili-giocatore` | Documento d'identità, certificato medico e foto tessera, in cartelle per giocatore (`/.`). | **Privato** e destinato a restare tale: contiene documenti e dati sanitari, che non devono mai avere URL pubblici (DD-016 regola 4). Il giocatore gestisce solo la propria cartella, l'admin può scaricare tutto tramite signed URL a scadenza breve. Creato dalla migration `m3_bucket_profili`. | +| `profili-giocatore` | Documento d'identità, certificato medico e foto tessera, in cartelle per giocatore (`/.`). | **Privato** e destinato a restare tale: contiene documenti e dati sanitari, che non devono mai avere URL pubblici (DD-016 regola 4). Il giocatore gestisce solo la propria cartella, l'admin può scaricare tutto tramite signed URL a scadenza breve. Creato dalla migration `m2_profili_giocatore`. | | `avatar-giocatori` | Foto profilo mostrate nel cerchio avatar (Squadra, Profilo), un file per giocatore (`/avatar.jpg`). | **Pubblico**: foto informali, non documenti sensibili. Qualsiasi autenticato può caricare/sostituire/eliminare un file (nessun controllo per-proprietario, la maggior parte dei giocatori non ha ancora `auth_user_id` collegato, DD-018). Letto da `src/lib/avatar-store.ts`. Creato dalla migration `m6_avatar_giocatori`. | ## Eventi e presenze diff --git a/docs/DESIGN_DECISIONS.md b/docs/DESIGN_DECISIONS.md index f94232a..dbd3c01 100644 --- a/docs/DESIGN_DECISIONS.md +++ b/docs/DESIGN_DECISIONS.md @@ -458,7 +458,7 @@ Regole vincolanti: - `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. +- Le migration M1–M2 (tabelle, RLS, bucket) restano **additive**: solo `CREATE`, nessun `ALTER`/`DROP` su schema esistente. - Raffina e attua quanto proposto in DD-015 per la rosa anagrafica, senza sostituire formalmente quella voce. **Riesame** diff --git a/docs/TODO.md b/docs/TODO.md index 8d2839f..1ca3528 100644 --- a/docs/TODO.md +++ b/docs/TODO.md @@ -8,7 +8,7 @@ Solo il lavoro in corso o imminente. L'elenco completo delle funzionalità previ - Documentazione tecnica del progetto. - Autenticazione Google e dashboard amministratore: il codice è completo su `develop` e il login è ora l'unica via d'accesso. Restano i passaggi di configurazione, in quest'ordine: - provider Google in Supabase (senza, nessuno entra), migration M2/M3, primo admin in + provider Google in Supabase (senza, nessuno entra), migration M2, primo admin in `user_roles`, collegamento dei 17 account, e infine la migration M4 che chiude gli accessi `anon`. Stato di dettaglio in [PROJECT_STATE.md](../PROJECT_STATE.md). diff --git a/test/README.md b/test/README.md index bf5f089..9f9b87f 100644 --- a/test/README.md +++ b/test/README.md @@ -32,9 +32,9 @@ non può inquinare gli altri. anonimo proprio per dimostrare che la RLS le respinge, e poi rilegge la riga per verificare che non sia cambiata: su un UPDATE a zero righe PostgREST risponde 2xx, quindi lo stato conta più del codice di risposta. -- I test legati alle migration M2/M3 si **saltano da soli** dove quelle migration non - sono ancora applicate, indicandolo nel motivo. Per vederli tutti verdi serve un - database che le contenga: `npx supabase start` ne crea uno in locale. +- I test legati alla migration M2 si **saltano da soli** dove quella migration non è + ancora applicata, indicandolo nel motivo. Per vederli tutti verdi serve un + database che la contenga: `npx supabase start` ne crea uno in locale. - `integration` ed `e2e` avviano da soli il server di sviluppo. Per usarne uno già attivo: `BASE_URL=http://localhost:8080 npm run test:e2e`. - Le variabili d'ambiente vengono lette da `.env`; i nomi senza prefisso diff --git a/test/integration/schema-profili.test.ts b/test/integration/schema-profili.test.ts index 80d0702..76fee1a 100644 --- a/test/integration/schema-profili.test.ts +++ b/test/integration/schema-profili.test.ts @@ -5,8 +5,8 @@ * configurato in `.env`) le tre cose che il codice dà per scontate: le colonne della * tabella, la chiusura verso l'utente anonimo e il bucket privato. * - * Salta con un motivo esplicito quando mancano le credenziali o quando le migration - * M2/M3 non sono ancora applicate a quel database: sono stati dell'ambiente, non difetti. + * Salta con un motivo esplicito quando mancano le credenziali o quando la migration + * M2 non è ancora applicata a quel database: sono stati dell'ambiente, non difetti. */ import assert from "node:assert/strict"; import { COLONNE_PROFILO } from "@/lib/profili-core"; @@ -132,13 +132,13 @@ if (!URL_BASE || !CHIAVE_SERVIZIO || !CHIAVE_PUBBLICA) { }); } - // --- M3: bucket privato ------------------------------------------------------ - const m3 = await bucketProfili(CHIAVE_SERVIZIO); - if (!m3.ok) { - salta("bucket dei documenti", "M3 non applicata (npx supabase db push)"); + // --- M2: bucket privato ------------------------------------------------------- + const bucketRes = await bucketProfili(CHIAVE_SERVIZIO); + if (!bucketRes.ok) { + salta("bucket dei documenti", "M2 non applicata (npx supabase db push)"); } else { await prova("il bucket dei documenti è privato", async () => { - const bucket = (await m3.json()) as { public?: boolean }; + const bucket = (await bucketRes.json()) as { public?: boolean }; assert.equal(bucket.public, false, "documenti e certificati non sono mai pubblici"); });