davideandClaude Sonnet 5.5
8f25143aa5
- Spezza il registro delle decisioni in docs/decisions/DD-XXX.md, con indice - Ripulisce DATABASE.md dalla storia delle migration e aggiunge la sezione Lettura - Riduce PROJECT_STATE.md a una pagina; la procedura di allestimento passa in OPERATIONS.md - Aggiunge OPERATIONS.md, GLOSSARIO.md, trappole note e checklist in ARCHITECTURE.md - Sintetizza la copertura test di badge.md e documenta docs/archive - Allinea AGENTS.md, README.md e la regola Cursor (tolto l'obbligo di develop, in contrasto con DD-019) Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
52 lines
2.9 KiB
Markdown
52 lines
2.9 KiB
Markdown
# DD-034 — L'allenatore è uno slot della squadra con tipo diverso, non un giocatore
|
|
|
|
**Data:** 24 settembre 2026
|
|
**Stato:** Accettata (implementata con le migration M20 e M21)
|
|
|
|
**Contesto**
|
|
Serve un account per l'allenatore: deve gestire gli eventi (oggi solo admin, `m11`) ma non è
|
|
un giocatore. Non ha statistiche, badge né stagione, non vota e non viene votato. L'admin
|
|
vuole registrarlo come i giocatori, inserendo la sua email Gmail. Specifica completa in
|
|
[modules/allenatore.md](../modules/allenatore.md).
|
|
|
|
**Decisione**
|
|
L'allenatore è una riga di `giocatori_squadra` con una nuova colonna `tipo = 'allenatore'`
|
|
(default `'giocatore'`). Così riusa senza cambiarli il collegamento per email (DD-018),
|
|
`profili_giocatore` per i dati personali, il bucket avatar e il compleanno sincronizzato
|
|
(DD-031). Il permesso di gestire gli eventi arriva da un nuovo valore `allenatore` di
|
|
`app_role` in `user_roles` (DD-011), scritto da una funzione `SECURITY DEFINER` quando si
|
|
collega uno slot di tipo allenatore: è quindi l'admin a concederlo, registrando lo slot.
|
|
"Rosa" diventa `attivo e tipo = 'giocatore'` ovunque.
|
|
|
|
**Alternative scartate**
|
|
|
|
- Una tabella `staff` separata → isola l'allenatore da voti e rosa senza toccare i filtri, ma
|
|
duplica collegamento per email, profilo, avatar e form admin. Resta l'alternativa se i
|
|
filtri sulla rosa si rivelano troppi o fragili.
|
|
- Registrare l'allenatore come admin → gli darebbe dati personali e documenti di tutta la
|
|
squadra (DD-017), molto più del necessario.
|
|
- Distinguere l'allenatore dal campo `ruolo` (ruolo in campo) → mescola due concetti e il
|
|
campo è testo libero.
|
|
|
|
**Conseguenze**
|
|
|
|
- Ogni lettura della rosa (client, server, SQL di voto e promemoria) va filtrata per `tipo`:
|
|
un punto dimenticato rende l'allenatore votabile o lo conta tra i convocati. L'elenco sta
|
|
nella specifica e va coperto dai test di `permessi.test.ts`.
|
|
- Il trigger sugli slot cambia: `tipo` lo scrive solo l'admin; nome e cognome li scrive anche
|
|
l'allenatore sul proprio slot.
|
|
- `numero` diventa nullabile a database, ma solo per gli allenatori (vincolo di M21); nell'app
|
|
resta un numero, 0 per l'allenatore, per non toccare i tipi di tutta la rosa.
|
|
- Due fonti distinte, ciascuna per il suo scopo: i permessi (eventi, sollecito) da
|
|
`user_roles`, la visibilità (badge, cacche, stagione) dal tipo del proprio slot, che è
|
|
immediato e non aspetta la query dei ruoli.
|
|
- L'allenatore non vede le tab Stagione e Badge del Profilo, né Obiettivi e Badge di Squadra.
|
|
- In Squadra compare nella tab Rosa con «Allenatore» al posto del ruolo, ricavato da `tipo`;
|
|
riceve i promemoria degli eventi (dal 29/09/2026 non più: DD-039) e può sollecitare le presenze,
|
|
non il turno palloni.
|
|
- Non vede badge né classifiche o sondaggi sulle cacche, in nessuna schermata.
|
|
|
|
**Riesame**
|
|
Se arriva un secondo tipo di staff (dirigente, segreteria) o se i filtri sulla rosa diventano
|
|
fonte di bug, passare alla tabella `staff` separata.
|