davideandClaude Sonnet 5.5
de78431090
Il Profilo non chiede più la foto tessera e la scheda admin non la mostra. Il completamento diventa dati personali 34%, documento 33%, certificato 33%. La migration m29 elimina la colonna profili_giocatore.foto_path; le 4 foto già caricate sono state cancellate dal bucket profili-giocatore. Migration applicata in produzione. Test: pesi e sezioni di profili-core, rendering di CampiProfilo, colonna rimossa sul database locale. Documentati DD-044, modulo profilo-giocatore, DATABASE, ROADMAP e changelog. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
38 lines
2.7 KiB
Markdown
38 lines
2.7 KiB
Markdown
# DD-017 — L'amministratore può compilare i dati al posto del giocatore
|
|
|
|
**Data:** agosto 2026
|
|
**Stato:** Accettata
|
|
|
|
**Contesto**
|
|
Il modulo Profilo Giocatore era costruito su un confine netto: ognuno scrive solo la propria riga, l'amministratore legge e scarica. Nella pratica quel confine blocca il lavoro che il modulo doveva togliere: se metà squadra non compila i propri dati, l'export per il tesseramento CSI resta incompleto e l'admin torna a chiedere le informazioni in chat — esattamente ciò che CrAPP deve eliminare. Inoltre le docs assegnavano già agli admin la gestione dei dati squadra (nome, cognome, numero, ruolo) e il reset del collegamento all'account (DD-016 regola 2), senza che esistesse una schermata per farlo.
|
|
|
|
**Decisione**
|
|
Dalla dashboard amministratore, un admin può:
|
|
|
|
1. modificare i **dati squadra** di qualsiasi giocatore (nome, cognome, numero, ruolo);
|
|
2. compilare e correggere i **dati personali e del documento** di qualsiasi giocatore;
|
|
3. **scollegare** un account da un profilo, liberando lo slot.
|
|
|
|
Restano fuori, e non cambiano:
|
|
|
|
- i **file** (documento, certificato; la foto tessera è stata tolta da DD-044): l'admin li scarica ma non li carica né li sostituisce. Un documento d'identità lo produce il suo titolare, e la catena di responsabilità deve restare leggibile;
|
|
- il **giocatore**, che continua a non poter toccare i propri dati squadra.
|
|
|
|
**Alternative scartate**
|
|
|
|
- Lasciare tutto al giocatore → l'export CSI resta incompleto e il lavoro amministrativo torna in chat, contro la missione del progetto.
|
|
- Dare all'admin anche l'upload dei file → confonde chi ha fornito un documento, su dati sanitari e d'identità dove serve il contrario.
|
|
- Un ruolo intermedio (segreteria) per i soli dati personali → un ruolo in più per una squadra sola, con gli stessi tre amministratori di adesso.
|
|
|
|
**Conseguenze**
|
|
|
|
- Il modello dei permessi non è più "ognuno i suoi": è "ognuno i suoi, più l'admin su tutti, tranne i file". Le policy RLS di M1 e M2 lo consentivano già, quindi non servono migration.
|
|
- Un admin può correggere un errore di battitura in un numero di documento senza inseguire il giocatore.
|
|
- Un admin vede e scrive dati personali altrui: è un potere reale, dato a tre persone su diciassette. Va assegnato con la stessa cura di prima (una riga in `user_roles`, nessuna auto-promozione).
|
|
- Il completamento del profilo smette di essere un indicatore di _chi ha risposto_ e diventa un indicatore di _quali dati mancano_, chiunque li abbia inseriti.
|
|
|
|
**Riesame**
|
|
|
|
- Se la squadra cresce al punto da rendere sensato un ruolo di sola segreteria.
|
|
- Se serve tracciare _chi_ ha modificato un dato: oggi non c'è audit, e con la scrittura condivisa la domanda prima o poi arriva.
|