Implementa DD-050: avviso «Presenza modificata», in prova solo per gli admin
Migration m32: tipo presenza_modificata, funzione e trigger su risposte_presenze che avvisano gli admin attivi se una risposta cambia a 0-6 ore da una partita o un allenamento (push, email e centro notifiche). Gli allenatori non la ricevono finché dura la prova. Applicata in produzione il 09/10/2026. Test di integrazione e unitario; DD-050, notifiche, DATABASE, CHANGELOG, ROADMAP e PROJECT_STATE aggiornati (slot g18 ora giocatore). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
This commit is contained in:
1 parent
f0e6a3a6cc
commit
274fed93c5
11 files changed
+523
-29
No files matched your search
@@ -1,7 +1,7 @@
|
||||
# DD-050 — Avviso a admin e allenatori se una presenza cambia a meno di 6 ore dall'evento
|
||||
|
||||
**Data:** 8 ottobre 2026
|
||||
**Stato:** In valutazione (solo documentata: nessun codice né migration scritti)
|
||||
**Stato:** Implementata in fase di prova, **solo per gli admin** (migration `m32`, applicata in produzione il 9 ottobre 2026)
|
||||
|
||||
**Contesto**
|
||||
Un giocatore può cambiare la risposta a un evento fino all'ultimo minuto. Chi organizza (admin e allenatore)
|
||||
@@ -44,6 +44,15 @@ risposta (`notifiche.md`, «Cosa non genera nessuna notifica»).
|
||||
6. **Nessuna configurazione.** Né una soglia modificabile (6 ore è scritto nella funzione), né un interruttore
|
||||
per ruolo: l'email e la push seguono le preferenze già esistenti di ciascuno (`preferenze_utente`, DD-036).
|
||||
|
||||
**Fase di prova**
|
||||
|
||||
Per ora l'avviso arriva **solo agli admin attivi** (ruolo `admin` e slot attivo), non agli allenatori: serve a
|
||||
vedere in pratica quante notifiche genera prima di aprirlo a chi gestisce gli eventi. Il punto 2 resta la regola
|
||||
a regime. Per allargarlo basta una nuova migration che aggiunge `'allenatore'` alla lista dei ruoli in
|
||||
`avvisa_presenza_modificata()` (oggi `ur.role IN ('admin')`) e il rimando in
|
||||
[allenatore.md](../modules/allenatore.md#notifiche); il resto non cambia. Finché dura la prova l'allenatore non
|
||||
riceve nulla.
|
||||
|
||||
**Alternative scartate**
|
||||
|
||||
- **Una route dell'app invocata dal client dopo il salvataggio** (come `sollecita-presenze`) → il client
|
||||
@@ -55,9 +64,9 @@ risposta (`notifiche.md`, «Cosa non genera nessuna notifica»).
|
||||
|
||||
**Conseguenze**
|
||||
|
||||
- Nuova migration `m32` (CHECK dei tipi, due funzioni, due trigger); `docs/DATABASE.md` e il catalogo in
|
||||
`notifiche.md` si aggiornano con essa. **Va applicata in produzione** con `npx supabase db push`.
|
||||
- L'allenatore, che oggi non riceve nulla sulle presenze, riceve questa notifica: va aggiunta a
|
||||
- Nuova migration `m32` (CHECK dei tipi, tre funzioni, due trigger); `docs/DATABASE.md` e il catalogo in
|
||||
`notifiche.md` si aggiornano con essa. Applicata in produzione il 9 ottobre 2026.
|
||||
- A regime l'allenatore, che oggi non riceve nulla sulle presenze, riceve questa notifica (non in fase di prova): va aggiunta a
|
||||
[allenatore.md](../modules/allenatore.md#notifiche).
|
||||
- Rumore possibile a ridosso dell'evento (punto 5). Se in pratica dà fastidio, il primo ritocco è raggruppare
|
||||
per evento, non togliere l'avviso.
|
||||
|
||||
Reference in new issue
Block a user