SostiTU

🧮 Calcolatore preventivo

📋 GDPR e Privacy

📄 Scarica DPA (Word)

⚠️ Nota importante: questo è un modello basato sugli standard GDPR (art. 28 Reg. UE 2016/679), utile come base di partenza. Prima dell'uso con scuole reali fallo verificare da un legale o consulente privacy, soprattutto per il trattamento di dati in ambito scolastico (presenza di minori).

ACCORDO SUL TRATTAMENTO DEI DATI PERSONALI (DPA)

Nomina a Responsabile del trattamento ai sensi dell'art. 28 del Regolamento UE 2016/679 (GDPR)

TRA

L'Istituto Scolastico [NOME ISTITUTO], con sede in [INDIRIZZO], C.F. [CODICE FISCALE], codice meccanografico [CODICE MECCANOGRAFICO], in persona del Dirigente Scolastico pro tempore [NOME DIRIGENTE], di seguito "Titolare del trattamento" o "Scuola";

E

[DATI FORNITORE — nome/ragione sociale, P.IVA/C.F., sede], fornitore del servizio software "SostiTU" per la gestione delle sostituzioni e dei permessi del personale scolastico, di seguito "Responsabile del trattamento" o "Fornitore";

PREMESSO CHE

• la Scuola utilizza il servizio SostiTU per la gestione organizzativa delle sostituzioni del personale docente e delle richieste di permesso;
• tale attività comporta il trattamento di dati personali del personale scolastico per conto della Scuola;
• la Scuola, in qualità di Titolare, nomina il Fornitore quale Responsabile del trattamento ai sensi dell'art. 28 GDPR;

SI CONVIENE QUANTO SEGUE

Art. 1 — Oggetto e durata

Il presente accordo disciplina il trattamento dei dati personali effettuato dal Responsabile per conto del Titolare nell'ambito dell'erogazione del servizio SostiTU. L'accordo ha la stessa durata del contratto di licenza e cessa con la sua risoluzione.

Art. 2 — Tipologie di dati e categorie di interessati

Categorie di interessati: personale docente e ATA della Scuola.

Tipologie di dati trattati: dati anagrafici (nome, cognome), dati di contatto (email, telefono), dati relativi al rapporto di lavoro (plesso, qualifica, tipo di contratto, orario di servizio), dati relativi a presenze, assenze, permessi e sostituzioni.

Il servizio non è destinato al trattamento di categorie particolari di dati (art. 9 GDPR). Eventuali dati relativi alla salute contenuti nelle richieste di permesso (es. certificati) sono trattati esclusivamente su iniziativa e responsabilità del Titolare.

Art. 3 — Finalità del trattamento

I dati sono trattati al solo fine di erogare le funzionalità del servizio: organizzazione delle sostituzioni, gestione delle richieste di permesso, generazione della relativa modulistica e comunicazioni operative al personale. Il Responsabile non utilizza i dati per finalità proprie.

Art. 4 — Obblighi del Responsabile

Il Responsabile si impegna a:

• trattare i dati solo su istruzione documentata del Titolare;
• garantire la riservatezza dei dati e che le persone autorizzate al trattamento siano vincolate alla riservatezza;
• adottare misure tecniche e organizzative adeguate ai sensi dell'art. 32 GDPR (cifratura in transito e a riposo, controllo degli accessi, autenticazione, backup);
• assistere il Titolare nel dare seguito alle richieste di esercizio dei diritti degli interessati;
• assistere il Titolare nel garantire il rispetto degli obblighi di sicurezza, notifica di violazioni e valutazione d'impatto;
• cancellare o restituire i dati al termine del servizio, secondo la scelta del Titolare;
• mettere a disposizione del Titolare le informazioni necessarie a dimostrare il rispetto degli obblighi.

Art. 5 — Sub-responsabili

Il Titolare autorizza il Responsabile ad avvalersi dei seguenti sub-responsabili per l'erogazione del servizio:

• Supabase Inc. — servizi di database e hosting, con infrastruttura ubicata nell'Unione Europea (regione UE — Irlanda). Il Responsabile ha sottoscritto con Supabase un accordo sul trattamento dei dati (DPA).

Il Responsabile informerà il Titolare di eventuali modifiche relative ai sub-responsabili, dando al Titolare la possibilità di opporsi.

Art. 6 — Ubicazione dei dati e trasferimenti

I dati sono ospitati su server ubicati nell'Unione Europea (Irlanda). Non sono previsti trasferimenti di dati al di fuori dello Spazio Economico Europeo. Qualora tali trasferimenti dovessero rendersi necessari, saranno effettuati nel rispetto del Capo V del GDPR.

Art. 7 — Diritti degli interessati

Il Responsabile assiste il Titolare nel rispondere alle richieste degli interessati relative ai diritti di accesso, rettifica, cancellazione, limitazione, portabilità e opposizione, entro 30 giorni dalla richiesta del Titolare.

Art. 8 — Violazioni dei dati (data breach)

Il Responsabile notifica al Titolare senza ingiustificato ritardo, e comunque entro 48 ore, ogni violazione dei dati personali di cui venga a conoscenza, fornendo le informazioni necessarie affinché il Titolare possa adempiere agli obblighi di notifica al Garante.

Art. 9 — Conservazione e cancellazione

I dati sono conservati per la durata del servizio. Al termine, su richiesta del Titolare, il Responsabile provvede alla cancellazione dei dati entro 30 giorni, salvo obblighi di conservazione previsti dalla legge. È attivo un sistema di backup con conservazione delle versioni precedenti.

Art. 10 — Legge applicabile e foro competente

Il presente accordo è regolato dalla legge italiana. Per ogni controversia è competente il Foro di [FORO COMPETENTE].

📖 Manuale Operativo Superadmin

SostiTU — uso interno

Indice 1. Architettura del sistema 2. Onboarding nuova scuola 3. Gestione licenze 4. Gestione utenti e accessi 5. App Permessi 6. Problemi comuni e soluzioni 7. Riferimenti tecnici

1. Architettura del sistema

1.1 Componenti principali

• Frontend — file HTML singoli (index.html, permessi.html, admin.html) deployati su Cloudflare Workers da GitHub (spezialiale/SostiTU). Ogni push su main aggiorna automaticamente il sito.
• Backend — Supabase (EU West, Ireland): database PostgreSQL, autenticazione, RPC, Realtime, Edge Functions. Dall'11 agosto 2026 il browser non parla più direttamente con Supabase: ogni chiamata passa da un proxy same-origin (_worker.js), che gestisce la sessione con cookie httpOnly invece che in localStorage — miglioramento di sicurezza contro il furto di sessione via XSS.
• Email — nessun invio server-side: tutte le email (notifiche sostituti, comunicazioni permessi, invio PDF alla segreteria) si aprono come bozza precompilata su Gmail/client di posta del dispositivo (link mailto: o compose Gmail), è l'utente a premere invio.
• Dominio — sostitu.it su Aruba, nameserver Cloudflare.

1.2 Tabelle Supabase principali

• istituti — anagrafica scuole clienti
• licenze — tipo, scadenza, max plessi, modulo permessi per istituto
• utenti — referenti e admin con ruolo, plesso, istituto_id, primo_accesso
• docenti_permessi — anagrafica docenti App Permessi (username=nome.cognome, password, primo_accesso)
• permessi — richieste permesso con stato, dati_extra JSONB
• permessi_assenze_sostitu — bridge: una riga per ogni giorno di assenza approvata → genera bozze in SostiTU
• sostituzioni — bozze e confermate per plesso
• rec / ore_d — saldi recuperi e ore D per docente
• backup_history — snapshot giornalieri automatici
• rubrica — contatti colleghi per plesso (usata anche per la scelta sostituti nelle Ferie in App Permessi)
• orari, dati_plesso, archivio_anni, gite, assenze_segnalate, docenti_permessi_plessi, fis_log, log_errori_critici, permessi_approvazioni — tabelle di supporto per orari, configurazione plesso, archiviazione anni scolastici, gite, segnalazioni assenze da mobile, log tecnici e storico approvazioni permessi.
• mfa_backup_codes — codici di backup monouso per l'MFA obbligatoria di admin/superadmin (vedi sezione 4.7), salvati solo come hash.

1.3 Edge Functions deployate

• crea-referenti — crea account Supabase Auth per i referenti/admin (usata sia dal wizard "Nuova scuola" sia da eventuali creazioni singole)
• sincronizza-docenti-auth — crea/aggiorna in blocco gli account Supabase Auth dei docenti App Permessi a partire dalla tabella docenti_permessi (vedi sezione 5.2bis)
• notifica-errore — riceve gli errori JavaScript non gestiti dal frontend e li inoltra su un canale Telegram interno, per essere avvisati di problemi in produzione senza dover controllare i log manualmente

Contratto completo (autorizzazione, formato richiesta/risposta, casi limite) di crea-referenti e sincronizza-docenti-auth: vedi CONTRATTI-EDGE-FUNCTIONS.md nella root del repository — da tenere aggiornato ogni volta che si modifica una di queste funzioni su Supabase.

2. Onboarding nuova scuola

2.1 Procedura completa (wizard a 4 passi, tab "🏫 Nuova scuola")

Non c'è upload Excel: è un wizard manuale, un passo alla volta. Crea un solo account admin per la scuola — se ci sono più plessi con referenti diversi, vanno aggiunti singolarmente dopo (tab Docenti/Utenti), non in blocco da qui.

1. Passo 1 — Dati istituto: nome, città, codice meccanografico (campo libero, senza spazi), dirigente scolastico, email DS, anno scolastico.
2. Passo 2 — Licenza: tipo (Prova 30 giorni / Standard / Gratuita), scadenza, max plessi (default 3), codice licenza (deve essere univoco), checkbox "Includi Modulo Permessi". La licenza viene creata già attiva.
3. Passo 3 — Admin della scuola: nome, cognome, email, password provvisoria (scelta da te). Crea un account con ruolo admin.
4. Passo 4 — Riepilogo: premendo 🏫 Crea scuola, il sistema in sequenza crea la riga in istituti, la riga in licenze, chiama l'Edge Function crea-referenti per l'account Auth dell'admin, invia automaticamente l'email di reset password a quell'indirizzo, e infine prova a creare anche l'account Dirigente Scolastico (ruolo ds) usando l'email raccolta al Passo 1 — vedi sezione 4.6. Se questo ultimo passaggio fallisce, scuola e admin sono comunque creati correttamente: l'esito compare separato nel messaggio finale.

Procedura dettagliata, sempre verificata sul codice reale: vedi ONBOARDING-NUOVA-SCUOLA.md nella root del repository.

2.2 Cosa fa l'admin al primo accesso

1. Apre sostitu.it e accede con email + password provvisoria.
2. Viene mostrato il modal Imposta la tua password: sceglie una password personale.
3. Accede all'app e segue la configurazione guidata (onboarding 6 passi): 1) verifica plesso, 2) imposta Gmail, 3) carica orari Excel, 4) carica rubrica docenti, 5) attivazione App Permessi, 6) backup e salvataggio.

3. Gestione licenze

3.1 Tipi di licenza

• Standard — licenza a pagamento annuale, da 390€ (fascia Piccola, ≤60 docenti) a 990€ (Molto Grande), + 120-220€ per il modulo Permessi. Listino aggiornato nel tab "💰 Prezzi".
• Prova 30 giorni — accesso completo per 30 giorni, poi scade.
• Gratuita — per scuole pilota o accordi speciali.

3.2 Modificare una licenza

Nel tab 📄 Licenze ogni riga ha un tasto ✏️ Modifica. Puoi cambiare: tipo licenza, numero massimo plessi, data scadenza, modulo permessi incluso (Sì/No). Le modifiche sono immediate.

3.3 Licenza scaduta

Quando una licenza scade, l'utente vede un modal di upgrade e non può accedere alle funzioni. Per rinnovarla: ✏️ Modifica → cambia la data scadenza → Salva.

3.4 IC Bonfigli (scuola pilota)

Codice licenza: ICBONFIGLI. istituto_id: 8c08811b-f9d9-48c2-b500-d23ae9ae605b. Licenza gratuita a tempo indeterminato. Non modificare la scadenza.

4. Gestione utenti e accessi

4.1 Ruoli utenti SostiTU

• superadmin — accede ad admin.html. Solo speziali.ale@gmail.com.
• admin — vede tutti i plessi dell'istituto, ha tab Admin in Config, accede da index.html.
• referente — vede solo il proprio plesso, accede da index.html.
• ds — Dirigente Scolastico, ruolo introdotto il 18 ago 2026. Login separato su sostitu.it/ds (pagina dedicata ds.html, non index.html): vede SOLO la propria Dashboard DS (KPI, andamento mensile, classifiche, stampa singolo plesso o aggregato tutta la scuola), nessun'altra funzione del gestionale. Vedi sezione 4.6 per crearlo.

4.2 Reset password referente

Il referente usa il link Password dimenticata? nella schermata di login → riceve email Supabase con link reset. Se l'email non arriva: controlla spam, verifica che l'email sia corretta in Supabase → Authentication.

4.3 Forzare primo accesso

Per forzare il cambio password al prossimo login di un referente (es. se la password provvisoria è stata compromessa):

UPDATE utenti SET primo_accesso = true WHERE email = 'email@scuola.it';

4.4 Eliminare un utente

Da Supabase → Authentication: elimina l'utente da auth.users. Poi esegui:

DELETE FROM utenti WHERE email = 'email@scuola.it';

4.5 Modificare l'admin di una scuola esistente

Tab 👥 Utenti → ✏️ Modifica admin scuola: seleziona l'istituto, inserisci la nuova email admin. Il sistema crea il nuovo account (email di accesso inviata subito) e disattiva quello vecchio, che perde l'accesso — la disattivazione avviene solo dopo che il nuovo admin è pronto, per non restare mai senza nessun admin funzionante se qualcosa fallisce a metà.

Caso "email già registrata": se la nuova email appartiene già a un account Supabase Auth esistente (es. un docente o un referente della stessa persona) — Supabase impone email univoca per l'intero progetto, non per ruolo/tabella — il pannello lo rileva da solo e assegna il ruolo admin a quell'account già esistente invece di provare (e fallire) a crearne uno nuovo. In questo caso non arriva nessuna email di reset: la persona accede subito con la password che già usa per l'altro ruolo.

4.6 Creare un account Dirigente Scolastico

Tab 👥 Utenti → 📈 Crea account Dirigente Scolastico: email DS + istituto. Comoda anche solo per testare la Dashboard DS senza creare una scuola nuova. Stessa logica "email già registrata" della sezione 4.5: se l'email appartiene già a un account esistente, gli viene assegnato il ruolo ds invece di crearne uno nuovo, nessuna email di reset in quel caso.

Il DS accede da sostitu.it/ds, non da index.html/admin.html.

4.7 MFA obbligatoria (admin/superadmin)

Dal 18 ago 2026, login con password non basta più per admin e superadmin: al primo accesso (fresco, non al ripristino di una sessione già aperta) viene richiesto anche un codice a 6 cifre da un'app authenticator (TOTP, gestito internamente da Supabase Auth — nessuna colonna nuova su utenti). Consigliata l'app Password già integrata nel telefono (iPhone/Android), che offre l'autofill del codice; va bene comunque qualunque app authenticator.

Al primo enrollment, subito dopo aver confermato il primo codice, vengono generati 10 codici di backup monouso (mostrati una sola volta, con pulsanti Copia/Scarica file) — utilizzabili al posto del codice a 6 cifre se si perde l'accesso all'app authenticator.

Recupero se un admin/superadmin resta bloccato (nessun codice di backup salvato, app authenticator persa): esegui in SQL editor, poi fai rifare l'enrollment da capo:

DELETE FROM auth.mfa_factors
WHERE user_id = (SELECT id FROM auth.users WHERE email = 'email@scuola.it');

DELETE FROM mfa_backup_codes
WHERE user_id = (SELECT id FROM auth.users WHERE email = 'email@scuola.it');

5. App Permessi

5.1 Come funziona

App separata su sostitu.it/permessi. Ogni docente ha un account individuale su Supabase Auth (email + password proprie, non condivise): lo username nome.cognome inserito in login è solo una scorciatoia — dietro le quinte il sistema risale all'email del docente (RPC get_docente_by_username) e fa login con quella. Non esiste una password unica condivisa da tutto l'istituto: tutti i docenti sono ormai migrati a questo meccanismo (non esiste più il vecchio confronto password in chiaro sulla tabella, rimosso il 13 agosto 2026 come falla di sicurezza).

5.2 Reset password docente App Permessi

Il docente inserisce il proprio username nella schermata di login e preme Password dimenticata? — il sistema risale all'email registrata e invia il link di reset lì. Funziona per tutti i docenti, essendo tutti ormai su Supabase Auth.

Se il docente non ha un'email registrata (quindi il link non può essere inviato), va prima sistemata l'anagrafica in docenti_permessi, poi rifatta la sincronizzazione (5.2bis) prima di poter usare "Password dimenticata?".

5.2bis Aggiornamento annuale docenti

A settembre, dopo aver aggiornato la tabella docenti_permessi (nuovi docenti inseriti, usciti marcati attivo=false):

1. Vai in 👥 Utenti → 🔄 Sincronizza account docenti
2. Inserisci la password provvisoria annuale (es. Bonfigli2028)
3. Premi Sincronizza — la funzione crea gli account dei nuovi, blocca gli usciti e aggiorna le email cambiate. È sicura e ripetibile.
4. Subito dopo, lancia questa query per beccare eventuali account rimasti disallineati (email diversa da quella su Auth, mai sincronizzati, o utente Auth orfano) prima che i docenti ci sbattano contro da soli:

   select dp.username, dp.email, au.email as auth_email, au.email_confirmed_at,
          case
            when dp.user_id is null then 'mai sincronizzato su Auth'
            when au.id is null then 'user_id orfano (utente Auth cancellato)'
            when lower(dp.email) <> lower(au.email) then 'email disallineata'
            when au.email_confirmed_at is null then 'email Auth non confermata'
          end as problema
   from docenti_permessi dp
   left join auth.users au on au.id = dp.user_id
   where dp.attivo = true
     and (dp.user_id is null or au.id is null or lower(dp.email) <> lower(au.email) or au.email_confirmed_at is null);

5. Controlla anche gli username con uno spazio interno (capita con nomi/cognomi composti tipo "Maria Cristina" o "DE GIORGI": lo username va salvato senza spazi ma a volte resta, e siccome il confronto in get_docente_by_username è una stringa esatta, blocca login e reset allo stesso modo di un account disallineato):

   select username, nome, cognome, email from docenti_permessi
   where attivo = true and username ~ '\s';
   
   -- fix in blocco, sicuro: allinea sempre alla parte prima della @ nell'email
   UPDATE docenti_permessi SET username = replace(username, ' ', '') WHERE username ~ '\s';

5.3 Docente non trova il suo nome

Il nome utente è nome.cognome in minuscolo senza spazi. Se il cognome ha apostrofo (es. MALA') l'username è monica.mala'. Verificare su Supabase → docenti_permessi il campo username esatto.

5.4 Permesso non genera bozze in SostiTU

Le bozze vengono create solo dopo l'approvazione da parte del referente. Verificare su Supabase → permessi_assenze_sostitu se esistono righe per quel permesso_id. Se mancano, il permesso non è stato approvato o l'approvazione ha avuto un errore.

Se il docente lavora in due plessi lo stesso giorno/ora (compresenza, 8 set 2026), servono due prese visione — una per ogni referente coinvolto — prima che il permesso risulti davvero approvato: permessi.stato resta inviata e permessi_assenze_sostitu resta vuota finché non arriva anche la seconda. Verificare su permessi_approvazioni quante righe con plesso diverso esistono per quel permesso_id (una riga con plesso IS NULL è un admin/superadmin, e da sola copre tutti i plessi coinvolti). Una volta completo, vengono create due righe in permessi_assenze_sostitu, una per plesso.

6. Problemi comuni e soluzioni

Non riesco ad accedere / password errata

Verificare che l'email sia corretta. Se il problema persiste: Supabase → Authentication → trovare l'utente → Send password recovery. Per i docenti App Permessi usare la query SQL di reset (sezione 5.2).

Docente App Permessi: non riesce né al primo accesso né a "Password dimenticata?"

Entrambe le strade passano dallo stesso controllo lato codice (docente.user_id && docente.email): se falliscono tutte e due insieme, quasi sempre l'account Auth del docente è disallineato — email sbagliata/vuota in docenti_permessi, oppure user_id che punta a un utente Auth cancellato. Diagnosi:

select dp.username, dp.email, dp.attivo, dp.primo_accesso,
       au.email as auth_email, au.email_confirmed_at
from docenti_permessi dp
left join auth.users au on au.id = dp.user_id
where dp.username = 'nome.cognome';

Se email e auth_email non combaciano (o auth_id è nullo): correggi prima l'email in docenti_permessi, poi rilancia 👥 Utenti → 🔄 Sincronizza account docenti (sezione 5.2bis) per propagarla su Auth. Una volta che email e auth_email combaciano, se il docente resta comunque senza una password funzionante (caso tipico: account esistente da prima, quindi la sync non gli assegna la password provvisoria come fa per i nuovi), puoi impostargliela direttamente allineandola alla procedura standard di tutti i nuovi docenti:

update auth.users
set encrypted_password = extensions.crypt('Bonfigli2027', extensions.gen_salt('bf'))
where email = 'email.corretta@scuola.it';

Con primo_accesso già a true, al login con questa password provvisoria il docente vede la stessa schermata "Imposta la tua password" di qualsiasi account nuovo — nessuna procedura diversa dal resto della scuola. (Se extensions.crypt dà errore "function does not exist", riprova senza il prefisso: crypt(...) / gen_salt(...).)

I dati non si sincronizzano / spariti dopo refresh

Supabase è la fonte di verità — cloudLoad sovrascrive sempre il localStorage. Se i dati spariscono: verificare che il plesso attivo in Config corrisponda al plesso dell'utente. Controllare la tab ☁ Backup per ripristinare uno snapshot precedente.

Le ore REC ricompaiono dopo aver cancellato

Verificare su Supabase → tabella rec se esiste una riga con plesso = 'default'. Se sì, eliminarla:

DELETE FROM rec WHERE plesso = 'default';

Il PDF del permesso dà errore

Aprire la console del browser (F12) e cercare il messaggio di errore. Gli errori più comuni sono: variabile non inizializzata (aggiornare permessi.html), jsPDF non caricato (problema di connessione), dati_extra mancanti (il permesso non ha tutti i campi obbligatori compilati).

La licenza risulta scaduta ma è stata rinnovata

Il referente deve fare logout e login per ricaricare i dati della licenza. Se il problema persiste: verificare la data scadenza nella tabella licenze — deve essere in formato YYYY-MM-DD.

Il referente vede i dati di un altro plesso

Verificare nella tabella utenti che il campo plesso del referente sia corretto. Se è vuoto o errato:

UPDATE utenti SET plesso = 'NomePlesso' WHERE email = 'email@scuola.it';

Errore "primo accesso" anche dopo aver cambiato password

Per SostiTU: verificare primo_accesso nella tabella utenti. Per App Permessi: verificare primo_accesso nella tabella docenti_permessi. In entrambi i casi:

-- SostiTU
UPDATE utenti SET primo_accesso = false WHERE email = 'email@scuola.it';
-- App Permessi
UPDATE docenti_permessi SET primo_accesso = false WHERE username = 'nome.cognome';

Admin/superadmin bloccato dal codice MFA

Vedi sezione 4.7 per la query di sblocco (DELETE FROM auth.mfa_factors + mfa_backup_codes). Prima di usarla, chiedi se ha i 10 codici di backup salvati — con quelli può sbloccarsi da solo nella schermata di login, senza intervento SQL.

Deploy non aggiorna il sito

Il deploy non passa da GitHub Actions (non esiste una pipeline CI in questo repo): è Cloudflare che builda automaticamente ad ogni push su main — verificare lo stato su dash.cloudflare.com → Workers & Pages → progetto sostitu → Deployments. Se fallisce, il log è lì. Il sito si aggiorna entro 1-2 minuti dal push. Fare hard refresh (Cmd+Shift+R) per svuotare la cache del browser — i file statici non hanno nomi con hash, quindi il browser potrebbe tenerne una copia vecchia in cache anche dopo il deploy.

7. Riferimenti tecnici

GitHub repo	github.com/spezialiale/SostiTU (privato)
Upload file	github.com/spezialiale/SostiTU/upload/main
Supabase dashboard	supabase.com/dashboard/project/jwoqmnwvaufzfqladxwe
Supabase URL (produzione)	jwoqmnwvaufzfqladxwe.supabase.co
Supabase URL (staging)	krcuztpqxfcahfwexayh.supabase.co
Sito staging	staging.sostitu.it — pubblicato con caricamento diretto (drag&drop) sul progetto Cloudflare sostitu-staging, non da GitHub
IC Bonfigli istituto_id	8c08811b-f9d9-48c2-b500-d23ae9ae605b
IC Bonfigli codice licenza	ICBONFIGLI
Superadmin email	speziali.ale@gmail.com
Password provvisoria sync docenti Bonfigli	Bonfigli2027 — usata solo per creare in blocco i nuovi account (sez. 5.2bis); ogni docente la cambia al primo accesso, non è una password condivisa permanente
Brand colors	Blu #185FA5 · Blu scuro #123E6B · Verde #3B6D11 · Verde chiaro #8CC63F
Cloudflare nameserver	Aruba → Cloudflare