35 lines
1.6 KiB
Markdown
35 lines
1.6 KiB
Markdown
 
|
# DD-033 — Gestione eventi: solo calendario, giorno fissato dal tocco
|
||
|
|
|
||
|
|
**Data:** 24 settembre 2026
|
||
|
|
**Stato:** Accettata
|
||
|
|
|
||
|
|
**Contesto**
|
||
|
|
`/eventi` mostrava sotto la griglia mensile anche la lista cronologica di tutti gli eventi
|
||
|
|
("Eventi in calendario"). La lista non aveva azioni proprie (toccare una riga apriva lo
|
||
|
|
stesso drawer del giorno) e allungava la pagina con informazioni già nel calendario. Nel
|
||
|
|
form, poi, il campo «Data» era già precompilato con il giorno toccato ma sembrava da
|
||
|
|
compilare: l'amministratore doveva scegliere solo l'ora.
|
||
|
|
|
||
|
|
**Decisione**
|
||
|
|
La pagina mostra solo il calendario, che si scorre di mese in mese con le frecce o con lo
|
||
|
|
swipe (stessa fisica a molla di `/calendario`, disattivata con `useMotoRidotto()`). Nel form
|
||
|
|
il giorno compare come testo fisso e resta da scegliere l'ora; il campo data compare solo
|
||
|
|
toccando «Cambia», per spostare un evento in un altro giorno.
|
||
|
|
|
||
|
|
**Alternative scartate**
|
||
|
|
|
||
|
|
- Togliere del tutto il campo data → non si potrebbe più spostare un evento esistente, una
|
||
|
|
funzione che oggi c'è (regola anti-regressione).
|
||
|
|
- Tenere la lista ma più corta (solo i prossimi eventi) → i prossimi eventi sono già in home
|
||
|
|
e in `/calendario`; qui sarebbe stata un doppione.
|
||
|
|
|
||
|
|
**Conseguenze**
|
||
|
|
|
||
|
|
- Per trovare un evento lontano bisogna scorrere fino al suo mese; il totale degli eventi
|
||
|
|
resta nel sottotitolo dell'header.
|
||
|
|
- Caricamento ed errore di `useEventi()` compaiono dentro la card del calendario, dove prima
|
||
|
|
stava la lista.
|
||
|
|
|
||
|
|
**Riesame**
|
||
|
|
Se gli eventi crescono tanto da rendere scomodo lo scorrere dei mesi, valutare una ricerca
|
||
|
|
per titolo invece di reintrodurre la lista completa.
|