Corregge riferimenti alla migration M3, mai applicata
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 <noreply@anthropic.com>
This commit is contained in:
Claude Sonnet 5
+3
-3
@@ -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 = '<mail>';`
|
||||
|
||||
+1
-2
@@ -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
|
||||
|
||||
+1
-1
@@ -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 (`<giocatore_id>/<sezione>.<est>`). | **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 (`<giocatore_id>/<sezione>.<est>`). | **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 (`<giocatore_id>/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
|
||||
|
||||
@@ -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**
|
||||
|
||||
+1
-1
@@ -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).
|
||||
|
||||
|
||||
+3
-3
@@ -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
|
||||
|
||||
@@ -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");
|
||||
});
|
||||
|
||||
|
||||
Reference in New Issue
Block a user