Architectuur, modules en rollen

Deze pagina vat de applicatiearchitectuur van Omniscol samen en de rollen die aan de kant van de school zichtbaar zijn. De precieze contractuele afspraken (beschikbaarheid, back-ups, bewaartermijn, bewaking) staan in de goedgekeurde juridische of commerciële documenten.

Hosting en betrouwbaarheid

Omniscol wordt gehost in de Europese Unie, meer bepaald op AWS Parijs en Scaleway Parijs. Het product gebruikt mechanismen voor back-up, bewaking en logische isolatie tussen de accounts van de onderwijsinstellingen; welke details op een account van toepassing zijn, hangt af van het contract en van de betrokken omgeving.

Zie FAQ — Beveiliging en hosting voor de details aan gebruikerszijde.

Softwarearchitectuur

• Webapplicatie: de applicatie laadt één keer, daarna worden de schermen dynamisch weergegeven met REST/JSON-uitwisselingen (Single Page Application).
• CouchDB als belangrijkste database.
• Redis als database voor de synchronisatie aan applicatiezijde en voor de logboeken.
• TypeScript voor de interface (webapp).
• Node.js- / Express-backend die de interne engines aanstuurt (api, webapp, portal, panel, ical, mcp, oauth2 enzovoort).
• C++ voor het algoritme van de roostergeneratie, dat draait op speciaal daarvoor bestemde VM's die op aanvraag worden gestart.

Beveiliging

• HTTPS voor de communicatie die naar buiten wordt opengesteld.
• Cloudflare als enige toegangspoort (bescherming tegen DDOS).
• Wachtwoorden die aan de clientzijde vooraf worden gehasht met scrypt en daarna aan de serverzijde opnieuw worden gehasht en van een salt voorzien. Ze worden niet in leesbare vorm opgeslagen of verstuurd.
• JWT-authenticatie met ondertekeningssleutels en een korte geldigheidsduur; een sleutel roteren of intrekken kan de ondertekende tokens ongeldig maken.
• Deellinks die ondertekend zijn, kunnen vervallen, gekoppeld zijn aan het account dat ze heeft aangemaakt en ongeldig worden door een wachtwoordwijziging of het uitschakelen van dat account.
• API-tokens met een hoofdsleutel en afgeleide tokens, endpoint-scopes en vervaldatums.
• OIDC / SSO beschikbaar afhankelijk van het contract en de instellingen van het account.
• Export en interne back-ups in JSON voor de omkeerbaarheid van de gegevens.

Gebruikersrollen

Omniscol onderscheidt verschillende rollen aan de kant van de school:

De koppeling tussen deze labels en de technische identificatiecodes van de rollen wordt in detail beschreven in Gebruikers en rollen.

Eén gebruiker kan meerdere rollen combineren. Een docent die meewerkt aan de planning kan bijvoorbeeld tegelijk Docent en Beheerder zijn.

De rol Deellink komt niet overeen met een gewoon gebruikersaccount. Het gaat om ondertekende links: de weblinks naar een rooster zijn alleen-lezen, terwijl bepaalde gerichte links wel een beperkte handeling kunnen toestaan, zoals het invullen van de beschikbaarheid van een docent tot een vervaldatum.

Daarnaast bestaan er interne rollen die aan de teams van Omniscol zijn voorbehouden: beheer van het platform, vertaling, commerciële activiteiten en distributiepartners. Sommige van die accounts mogen zich om onderhoudsredenen aanmelden bij de accounts van de scholen. Ze treden dan op als superbeheerder van de school, met meer mogelijkheden dan een beheerder: ruwe gegevens rechtstreeks in de database importeren, betaalde opties in- of uitschakelen, zich aanmelden namens een gebruiker. Dergelijke toegang veroorzaakt zichtbare aanmeldwaarschuwingen en de bijbehorende tokens vervallen zeer snel. Grote macht brengt grote verantwoordelijkheid mee.

Modules

De modules die zichtbaar zijn in een standaardaccount:

• Home (home) — startpagina en overzicht van de dag.
• Rooster (schedules) — raadplegen en losse wijzigingen.
• Dashboard (dashboard) — statistieken over bezetting en diensturen.
• Afwezigheidsbeheer (absences) — meldingen en vervangingen.
• Roosterbeheer (timetables) — opbouw, roostergeneratie en publicatie van de roosters.
• Beheer (admin) — gebruikers, instellingen, import / export en integraties.

Afhankelijk van het contract kunnen er nog andere modules verschijnen, met name Personeelsinzet voor het plannen van de taken rond leerlingenbegeleiding en toezicht.

Meerdere scholen

Elke school is aan de serverzijde logisch geïsoleerd en werkt op een eigen domein. De gegevens van een school zijn vanuit de applicatie niet zichtbaar voor de andere scholen. Op verzoek kan er wel een communicatiekanaal tussen de afzonderlijke accounts worden geactiveerd, om de bezettingsconflicten van lokalen en docenten te delen. Dat is erg nuttig bij gedeelde gebouwen, of voor een groep scholen die resources deelt.