Architettura, moduli e ruoli

Questa pagina riassume l'architettura applicativa di Omniscol e i ruoli visibili lato scuola. Gli impegni contrattuali precisi (disponibilità, backup, conservazione, monitoraggio) sono definiti nei documenti giuridici o commerciali approvati.

Hosting e affidabilità

Omniscol è ospitato nell'Unione europea, più precisamente su AWS Parigi e Scaleway Parigi. Il prodotto utilizza meccanismi di backup, di monitoraggio e di isolamento logico tra gli account degli istituti; i dettagli applicabili a un account dipendono dal contratto e dall'ambiente interessato.

Vedere FAQ — Sicurezza e hosting per il dettaglio lato utente.

Architettura software

• Applicazione web: l'applicazione si carica una sola volta, poi le schermate vengono generate dinamicamente con scambi REST/JSON (Single Page Application).
• CouchDB come database principale.
• Redis come database per la sincronizzazione lato applicazione e i log.
• TypeScript per l'interfaccia (webapp).
• Backend Node.js / Express che orchestra gli engine interni (api, webapp, portal, panel, ical, mcp, oauth2, ecc.).
• C++ per l'algoritmo di generazione, eseguito su VM dedicate avviate su richiesta.

Sicurezza

• HTTPS per le comunicazioni esposte.
• Cloudflare come unico punto di ingresso (protezione anti-DDOS).
• Password pre-cifrate lato client con scrypt, poi ricifrate e salate lato server. Non vengono memorizzate né trasmesse in chiaro.
• Autenticazione JWT con chiavi di firma e durata di vita breve; una rotazione o revoca di chiave può invalidare i token firmati.
• Link di condivisione firmati, con scadenza, legati all'account che li ha generati e invalidabili con la modifica della password o la disattivazione di tale account.
• Token API con chiave radice e token derivati, scope di endpoint e scadenze.
• OIDC / SSO disponibile in base al contratto e alla configurazione dell'account.
• Esportazione e backup interni JSON per la reversibilità dei dati.

Ruoli utente

Omniscol distingue diversi ruoli lato scuola:

La corrispondenza tra queste etichette e gli identificativi tecnici dei ruoli è descritta in Utenti e ruoli.

Uno stesso utente può cumulare più ruoli. Per esempio, un professore che partecipa alla pianificazione può essere allo stesso tempo Professore e Amministratore.

Il ruolo Link di condivisione non corrisponde a un account utente classico. Si tratta di link firmati: i link web dell'orario sono in sola lettura, mentre alcuni link mirati possono autorizzare un'azione limitata, come l'inserimento delle disponibilità di un professore fino a una data di scadenza.

Esistono inoltre ruoli interni riservati ai team di Omniscol: amministrazione della piattaforma, traduzione, attività commerciali e partner rivenditori. Alcuni di questi account sono autorizzati a connettersi agli account delle scuole, per motivi di manutenzione. Intervengono allora come superamministratori della scuola, con più possibilità di un amministratore: importazione di dati grezzi nel database, attivazione o disattivazione di opzioni a pagamento, connessione a nome di un utente. Questi accessi generano avvisi di connessione visibili e i relativi token scadono molto rapidamente. Da grandi poteri derivano grandi responsabilità.

Moduli

I moduli visibili in un account standard:

• Home (home) — pagina d'ingresso e sintesi della giornata.
• Orario (schedules) — consultazione e modifiche puntuali.
• Dashboard (dashboard) — statistiche di occupazione e di servizio.
• Gestione delle assenze (absences) — dichiarazioni e sostituzioni.
• Gestione degli orari (timetables) — costruzione, generazione e pubblicazione degli orari.
• Amministrazione (admin) — utenti, parametri, importazione / esportazione e integrazioni.

In base al contratto, possono comparire altri moduli, in particolare Servizio del personale per la pianificazione delle attività di vita scolastica e di sorveglianza.

Multi-scuola

Ogni scuola è isolata logicamente lato server e accede al proprio dominio. I dati di una scuola non sono visibili alle altre scuole dall'applicazione. Su richiesta, è però possibile attivare un canale di comunicazione tra gli account distinti, per condividere i conflitti di occupazione delle aule e dei professori. È molto utile nel contesto di edifici condivisi, o per un gruppo di scuole che condividono risorse.