Sintesi del progetto
Mater Sanremo è un'applicazione web e mobile che collega il lavoro quotidiano della scuola alla consultazione delle famiglie. Il progetto comprende presenze, pasti, attività, routine della giornata, comunicazioni, messaggistica e notifiche, con percorsi differenti per personale e genitori.
La parte centrale del lavoro è mantenere il contesto: a quale studente appartiene un'informazione, chi l'ha registrata, in quale giorno e a quali persone deve arrivare. Una piattaforma di questo tipo deve rappresentare la giornata in modo leggibile senza trasformare ogni aggiornamento in una comunicazione indistinta all'intera comunità scolastica.
Il bisogno ricostruito dai flussi
L'esigenza che emerge dal progetto è collegare attività operative e relazione scuola-famiglia. Il personale registra fatti durante la giornata; le famiglie li consultano da un contesto diverso e hanno bisogno di riconoscere quelli pertinenti. Una presenza, un pasto, una nota e una comunicazione generale non hanno lo stesso significato né necessariamente gli stessi destinatari.
Questa è una ricostruzione dai requisiti e dal codice, non una testimonianza attribuita a insegnanti o genitori. Il problema affrontato è rendere ordinato il passaggio tra chi produce l'informazione e chi deve usarla, mantenendo insieme i riferimenti allo studente, alla data e alla responsabilità di registrazione.
Ruoli distinti nel medesimo ambiente
Il backend riconosce ruoli differenti, tra cui amministrazione, insegnanti e genitori. Le funzioni protette ricavano l'utente dalla sessione autenticata, recuperano il profilo e verificano che il ruolo possa eseguire l'operazione richiesta. Non si limitano a ricevere un nome di ruolo scelto dall'interfaccia.
Questa distinzione consente di costruire percorsi diversi senza duplicare il prodotto. La famiglia accede al proprio contesto; il personale registra e comunica; l'amministrazione gestisce gli aspetti trasversali. Il caso descrive controlli presenti nei flussi esaminati: la sicurezza dell'intero sistema richiede comunque una verifica complessiva di applicazione, database e distribuzione.
Collegare il genitore agli studenti pertinenti
Il collegamento tra account genitore e studenti è gestito da una funzione dedicata. La richiesta deve provenire da una sessione con ruolo genitore; il server usa l'identità autenticata per individuare le associazioni e creare i collegamenti. La scrittura evita duplicazioni quando la stessa relazione esiste già.
Il caso senza associazioni è previsto e restituisce un esito distinto, invece di inventare un collegamento. Questo passaggio è fondamentale per l'esperienza successiva: prima di mostrare la giornata occorre stabilire di chi si sta parlando. La consultazione non dovrebbe dipendere dalla scelta libera di uno studente o dal ricordo di una selezione precedente nel browser.
Registrare le presenze con data e responsabilità
La presenza è un dato strutturato. Il modulo distingue presente, assente, in ritardo e assenza giustificata; conserva data, eventuali note e utente che ha registrato l'informazione. Il flusso gestisce sia il primo inserimento sia la modifica di una registrazione esistente.
Il punto operativo è poter leggere uno stato esplicito invece di interpretare un'annotazione generica. La presenza influenza inoltre altri passaggi della giornata. Nel modulo collettivo dei pasti, per esempio, il sistema parte dagli studenti registrati come presenti nella data selezionata. La relazione tra i moduli riduce il rischio che due aree della stessa applicazione rappresentino giornate diverse.
Compilare i pasti partendo dalla giornata reale
Il percorso collettivo dei pasti recupera le presenze del giorno e prepara l'elenco pertinente. Carica anche le registrazioni già presenti, distinguendo studente, tipo di pasto, consumo e note. Il personale può così ritrovare ciò che è stato inserito e lavorare sul gruppo previsto.
Il valore progettuale non sta semplicemente nella possibilità di compilare molti campi insieme. Sta nel conservare il collegamento tra la registrazione individuale e l'operazione collettiva: una compilazione per classe deve continuare a produrre informazioni riferite ai singoli studenti. Il caso documenta questa struttura, senza riportare abitudini, dati alimentari o situazioni personali di bambini reali.
Adattare le routine alla sezione
Le esigenze della giornata non sono identiche per tutte le sezioni. Il progetto comprende moduli per routine come riposo e bagno, ma la dashboard famiglia ne controlla la visualizzazione sulla base delle impostazioni della sezione. Un modulo non abilitato non viene mostrato come parte necessaria di ogni percorso.
Anche queste registrazioni usano il riferimento alla data e permettono di recuperare dati già inseriti. La scelta evita di costruire una schermata universale piena di elementi irrilevanti. L'interfaccia viene modellata intorno alle attività previste nel contesto scolastico, mantenendo un'infrastruttura comune. Qui interessa il funzionamento del sistema, non il contenuto personale delle registrazioni.
Comunicare a sezioni, classi o destinatari specifici
Il compositore delle comunicazioni permette di definire un pubblico per sezioni, classi o studenti. Non ogni messaggio deve raggiungere tutte le famiglie. Il contenuto conserva il proprio perimetro, così una comunicazione organizzativa può essere distinta da un aggiornamento rivolto a un gruppo limitato.
Nel flusso di invio delle notifiche i destinatari vengono risolti dal server. Per gli insegnanti il codice considera le sezioni assegnate e limita le selezioni di conseguenza. Se non risultano destinatari consentiti, l'operazione restituisce un esito vuoto. È un caso normale da gestire: l'assenza di destinatari non deve essere interpretata come una consegna avvenuta.
Una notifica salvata non equivale a un push consegnato
Il sistema distingue l'archiviazione della notifica dagli esiti dell'invio push. Le notifiche manuali del personale vengono conservate anche nell'archivio delle comunicazioni; la risposta tecnica riporta separatamente quanti elementi sono stati memorizzati e gli esiti della consegna push.
Questa separazione è utile quando il dispositivo non è raggiungibile o il servizio di notifica incontra un problema. Il contenuto può esistere nell'applicazione anche se l'avviso sul telefono non è arrivato. L'interfaccia e l'assistenza devono poter riconoscere questa differenza. La presenza di un meccanismo push, da sola, non dimostra che ogni famiglia abbia letto una comunicazione.
Messaggi che mantengono il contesto dello studente
La messaggistica conserva studente, mittente, destinatario e momento di lettura. Gli aggiornamenti in tempo reale vengono filtrati sul contesto della conversazione e sulla coppia di interlocutori. Quando un messaggio arriva al destinatario presente nella conversazione, il flusso gestisce la lettura; controlla inoltre che lo stesso evento non aggiunga due volte il messaggio.
È un esempio di funzionalità apparentemente semplice che richiede più livelli di coerenza. Non basta visualizzare del testo: occorre capire a chi è indirizzato, a quale studente si riferisce e se è già stato caricato. La comunicazione resta così legata al contesto scolastico che l'ha generata.
Portare gli stessi percorsi su web e telefono
Mater usa una base React con PWA e un'integrazione Capacitor per Android e iOS. La configurazione nativa include le risorse web nel pacchetto dell'app, insieme a supporto per push, badge e aggiornamenti web in background. Il progetto distingue quindi il contenuto applicativo dalle capacità offerte dal dispositivo.
La distinzione guida anche la manutenzione. Un aggiornamento di interfaccia compatibile può seguire un percorso diverso da una modifica a permessi o componenti nativi. Le prove richieste comprendono avvio, autenticazione, consultazione delle comunicazioni e comportamento delle notifiche nelle diverse condizioni del telefono. Una build riuscita non sostituisce queste verifiche sul dispositivo.
Il percorso completo e ciò che resta da verificare
Un esempio illustrativo parte dalla presenza registrata dal personale. Le attività successive usano la stessa data; pasti e routine vengono associati agli studenti pertinenti; una comunicazione viene indirizzata al pubblico previsto. Il genitore collegato consulta il proprio contesto e, se serve, apre uno scambio che mantiene il riferimento allo studente.
Il risultato documentabile è questa continuità tra registrazione, destinatari e consultazione. Oltre al codice e alla cronologia tecnica, il 13 settembre 2026 è stata aperta in sola lettura la dashboard amministrativa autentica: la schermata conferma l'accesso unitario a studenti, staff, attività giornaliere, note, foto, menu, comunicazioni, notifiche e messaggi. Nessuna di queste aree è stata aperta durante la cattura, così profili, presenze, pasti, immagini e conversazioni di minori o famiglie sono rimasti fuori dalla verifica. La schermata dimostra l'interfaccia disponibile, non il collaudo completo di ciascun flusso.
Parte delle modifiche native era ancora descritta come lavorazione locale; lo stato corrente degli store non viene dedotto da tale documentazione. Per un progetto che richiede ruoli, flussi e comunicazioni specifiche puoi approfondire lo sviluppo software su misura o richiedere una consulenza.
