Device Management
User Stories – Version 0.1 (Draft)
1. Attore: Famiglia (Utente non autenticato)
1.1 Inserimento richiesta device
Come famiglia
Voglio compilare una form per richiedere un device
Così da avviare il processo di valutazione e produzione.
Acceptance Criteria
La form è accessibile pubblicamente.
I campi obbligatori sono validati lato client e lato server.
I dati sensibili non sono pubblicamente accessibili.
Alla sottomissione viene inviata una email di verifica.
1.2 Verifica email
Come famiglia
Voglio ricevere un link di verifica email
Così da confermare la validità della richiesta.
Acceptance Criteria
Il sistema genera un token univoco.
Il link scade dopo un tempo configurabile.
Dopo la verifica lo stato passa a "validated".
1.3 Consultazione stato richiesta
Nota: Le famiglie NON hanno accesso autenticato al sistema.
Possono esclusivamente consultare la sezione pubblica del sito, dove sono visibili solo informazioni generali e non sensibili.
2. Attore: Volontario (Utente autenticato)
2.1 Registrazione e gestione profilo
Come volontario
Voglio registrarmi e aggiornare il mio profilo
Così da rendere disponibili le mie competenze.
Acceptance Criteria
Accesso tramite autenticazione.
Possibilità di aggiornare i propri dati base.
Possibilità di attivare moduli opzionali (maker, pubblico).
2.2 Visualizzazione richieste assegnate
Come volontario
Voglio vedere le richieste assegnate a me
Così da poterle gestire.
Acceptance Criteria
Visualizzazione solo delle richieste assegnate.
Accesso ai dati sensibili solo se assegnatario.
Timeline eventi visibile.
2.3 Aggiornamento stato richiesta
Come volontario assegnato
Voglio aggiornare lo stato della richiesta
Così da far avanzare il workflow.
Acceptance Criteria
Le transizioni seguono un workflow sequenziale.
Ogni cambio stato genera un evento.
Le transizioni non valide sono bloccate.
2.4 Inserimento note/eventi
Come volontario
Voglio aggiungere note o eventi
Così da tracciare attività e comunicazioni.
Acceptance Criteria
Le note sono storicizzate.
Ogni evento è associato a un autore e timestamp.
2.5 Richiesta spedizione
Come volontario
Voglio richiedere la spedizione del device
Così da avviare il processo logistico.
Acceptance Criteria
La richiesta di spedizione è collegata alla deviceRequest.
È tracciato lo stato della spedizione.
3. Attore: Amministratore (Admin Richieste)
3.1 Validazione richiesta
Come amministratore
Voglio validare le richieste
Così da controllare qualità e completezza.
Acceptance Criteria
Possibilità di modificare stato da "inviata" a "famiglia contattata".
Possibilità di rifiutare la richiesta.
In caso di rifiuto, la famiglia viene contattata direttamente.
Le informazioni pubbliche vengono aggiornate sul sito.
3.2 Assegnazione volontario
Come amministratore
Voglio assegnare un volontario a una richiesta
Così da avviare la produzione.
Acceptance Criteria
Selezione tra volontari attivi.
Stato passa a "attesa volontario" o fase successiva coerente.
3.3 Modifica stato avanzato / Riapertura
Come amministratore
Voglio poter portare una richiesta in qualsiasi stato
Così da gestire eccezioni o riaperture.
Acceptance Criteria
L’amministratore può forzare transizioni tra stati.
Ogni modifica genera un evento tracciato.
Le riaperture sono tracciate nella timeline.
3.4 Dashboard globale
Come amministratore
Voglio visualizzare statistiche aggregate
Così da monitorare andamento richieste.
Acceptance Criteria
Numero richieste per stato.
Distribuzione geografica.
Non sono previsti SLA o vincoli temporali obbligatori.
4. Attore: Utente Pubblico
Attore: Utente Pubblico
4.1 Consultazione richieste pubbliche
Come visitatore del sito
Voglio vedere richieste in forma anonima
Così da comprendere l'attività della community.
Acceptance Criteria
Sono visibili solo dati pubblici (città, tipo device, stato).
Nessun dato personale è esposto.
5. Workflow (Sequenziale – Versione Dettagliata)
Stati della richiesta device
inviata
famiglia contattata
definizione richiesta
valutazione fattibilità
followup famiglia ko (CHIUSURA)
followup famiglia troppo piccolo (CHIUSURA)
attesa volontario
scelta device e dimensionamento
personalizzazione
attesa materiali
fabbricazione
pronta per spedizione
spedita
followup famiglia
completata
annullata
Descrizione sintetica degli stati
inviata: la richiesta è stata inserita dalla famiglia e validata via email.
famiglia contattata: primo contatto effettuato per raccolta informazioni.
definizione richiesta: fase collaborativa per chiarire esigenze, misure, obiettivi.
valutazione fattibilità: verifica tecnica della possibilità di realizzazione.
followup famiglia ko: chiusura per esito tecnico negativo.
followup famiglia troppo piccolo: chiusura temporanea per età non idonea.
attesa volontario: richiesta pronta per assegnazione.
scelta device e dimensionamento: selezione modello e adattamento misure.
personalizzazione: eventuali modifiche estetiche o funzionali.
attesa materiali: in attesa componenti necessari.
fabbricazione: stampa e assemblaggio.
pronta per spedizione: dispositivo completato.
spedita: spedizione effettuata.
followup famiglia: contatto post-consegna per verifica utilizzo e soddisfazione.
completata: richiesta chiusa positivamente dopo followup.
annullata: richiesta chiusa anticipatamente per motivi organizzativi, rinuncia famiglia o altre cause non tecniche.
Stati di Chiusura
followup famiglia ko
followup famiglia troppo piccolo
annullata
completata
La chiusura effettiva della richiesta è sempre eseguita da un amministratore.
Nota: lo stato "followup famiglia" può portare successivamente a "completata" oppure, su decisione dell’amministratore, a qualsiasi altro stato (riapertura del processo).
Transizioni Sequenziali (prima proposta)
inviata
→ famiglia contattata
→ definizione richiesta
→ valutazione fattibilità
Da "valutazione fattibilità" possono avvenire tre transizioni:
→ followup famiglia ko (chiusura)
→ followup famiglia troppo piccolo (chiusura)
→ attesa volontario
Transizioni gestite dal volontario (sequenziali obbligatorie)
Dallo stato "scelta device e dimensionamento" il volontario assegnato può avanzare solo in modo sequenziale:
scelta device e dimensionamento
→ personalizzazione
→ attesa materiali
→ fabbricazione
→ pronta per spedizione
→ spedita
Non sono consentiti salti di stato per il volontario.
L’amministratore può invece forzare qualsiasi transizione di stato in qualsiasi momento (riapertura inclusa).
attesa volontario
attesa volontario
→ scelta device e dimensionamento
→ personalizzazione
→ attesa materiali
→ fabbricazione
→ pronta per spedizione
→ spedita
→ followup famiglia
→ completata
Punti da Validare
Lo stato "followup famiglia" è uno stato finale o può riaprire il processo?
È prevista la riapertura da stati di chiusura?
È necessario distinguere "chiusa definitiva" da "chiusa temporanea"?
Serve uno stato "annullata" su richiesta famiglia?
6. Regole Organizzative Confermate
Non sono previsti SLA temporali.
Le famiglie non hanno accesso autenticato.
Le famiglie possono consultare solo la sezione pubblica.
Il rifiuto richiesta è comunicato direttamente dall’amministratore.
Le informazioni pubbliche vengono aggiornate dal sito.
I ruoli previsti sono:
Admin richieste
Volontari
7. Stati Pubblici (Macro Aggregazioni)
Gli stati pubblici visibili nella sezione pubblica del sito sono una macro‑aggregazione degli stati interni.
1) Da gestire
Comprende tutti gli stati iniziali fino a "attesa volontario", escluse le chiusure:
inviata
famiglia contattata
definizione richiesta
valutazione fattibilità
attesa volontario
2) Fabbricazione in corso
Comprende:
scelta device e dimensionamento
personalizzazione
attesa materiali
fabbricazione
pronta per spedizione
spedita
followup famiglia
3) Completati
completata
4) Annullate / Non completabili
followup famiglia ko
followup famiglia troppo piccolo
annullata
8. Regole di Transizione e Audit
Ogni transizione di stato deve generare automaticamente un evento.
L’evento deve contenere:
stato di partenza
stato di arrivo
data/ora
autore (admin o volontario)
note (opzionali)
eventuali file allegati
Gli eventi sono immutabili (non modificabili dopo la creazione).
Gli eventi costituiscono la timeline ufficiale della richiesta.
8. Aree da Definire Meglio
Visibilità pubblica di ciascuno stato
Politica di gestione allegati (dimensioni, retention, privacy)
Notifiche automatiche interne (email ai volontari)
Nota: Documento aggiornato secondo decisioni organizzative correnti.
10. Schema Firestore Definitivo (Struttura Logica)
Collections principali
users/{uid}
Campi:
email
displayName
role (admin | volunteer)
active
createdAt
Subcollection opzionale:
profiles/{profileId}
deviceRequests/{requestId}
Campi:
deviceType
province
status (stato interno)
publicStatus (macro stato pubblico)
assignedVolunteer (uid o null)
createdAt
updatedAt
createdBy
Subcollections:
private/data
dati sensibili della richiesta
events/{eventId}
type
fromStatus
toStatus
timestamp
createdBy
note (opzionale)
attachments (opzionale array metadati file)
publicDeviceRequests/{requestId}
Campi:
deviceType
province
publicStatus
createdAt
shippingRequests/{shippingId}
Campi:
deviceRequestId
requestedBy
destinationProvince
status
createdAt
updatedAt
Subcollection opzionale:
events/{eventId}
11. Nota Importante: Gestione Schema in Firestore
Firestore è un database NoSQL schemaless.
Questo significa che:
Non esiste uno "schema" da caricare o applicare.
La struttura viene creata automaticamente quando si inseriscono i documenti.
Le regole di sicurezza controllano accessi, non la struttura dei campi.
Come garantire coerenza strutturale
Per mantenere uno schema coerente si consiglia:
Validazione lato backend (Cloud Functions) per:
creazione richiesta
transizione stati
generazione eventi
Definizione interfacce TypeScript nel frontend/backend.
Uso di controlli applicativi per:
obbligatorietà campi
formato dati
coerenza stato → publicStatus
Indici
Firestore richiederà automaticamente la creazione di indici se:
Si fanno query con più filtri combinati
Si ordinano risultati su campi filtrati
Gli indici si configurano dal pannello Firebase quando richiesto.
Conclusione: lo schema è documentato qui per chiarezza architetturale, ma la sua applicazione è garantita dall'applicazione e dalle Cloud Functions, non da una configurazione esplicita del database.
9. Modello Dati – Informazioni Richiesta Device
Di seguito classificazione delle informazioni attualmente tracciate.
9.1 Dati Privati (sensibili – visibili solo ad Admin e Volontario assegnato)
Indirizzo email
Nome richiedente
Cognome richiedente
Telefono
Provincia
Relazione con il destinatario
Anni (destinatario)
Sesso (destinatario)
Fa terapia occupazionale
Tipo di amputazione
Descrizione
Preferenze / Note
Consenso trattamento dati personali
Questi dati devono essere salvati in:
deviceRequests/{requestId}/private/data
Non devono mai essere esposti nella collection pubblica.
9.2 Dati Operativi (interni, non pubblici)
Volontario assegnato
Activity (attività tracciate per la richiesta)
Questi dati possono essere salvati in:
deviceRequests/{requestId}
oppure in subcollection dedicate:
deviceRequests/{requestId}/events
9.3 Dati Pubblici (macro stato e informazioni generali)
Dalla richiesta devono essere derivati e pubblicati solo:
Città / Provincia (in forma generica)
Tipo di device
Stato pubblico (macro aggregazione)
Questi dati dovrebbero essere salvati in una collection separata:
publicDeviceRequests/{requestId}
Questa collection è una proiezione sicura dei dati interni e non contiene informazioni personali.
9.4 Informazioni Cronologiche
Le informazioni cronologiche devono essere gestite tramite:
deviceRequests/{requestId}/events/{eventId}
Ogni evento contiene:
stato di partenza
stato di arrivo
data/ora
autore