Architektur, Module und Rollen

Diese Seite fasst die Anwendungsarchitektur von Omniscol und die auf Schulseite sichtbaren Rollen zusammen. Die genauen vertraglichen Zusagen (Verfügbarkeit, Sicherungen, Aufbewahrung, Überwachung) ergeben sich aus den freigegebenen rechtlichen oder kaufmännischen Dokumenten.

Hosting und Zuverlässigkeit

Omniscol wird in der Europäischen Union gehostet, genauer gesagt auf AWS Paris und Scaleway Paris. Das Produkt nutzt Mechanismen für Sicherung, Überwachung und logische Trennung zwischen den Konten der Einrichtungen; die für ein Konto geltenden Details hängen vom Vertrag und der betreffenden Umgebung ab.

Siehe FAQ — Sicherheit und Hosting für die Details auf Nutzerseite.

Softwarearchitektur

• Webanwendung: Die Anwendung wird einmal geladen, anschließend werden die Bildschirme dynamisch über REST/JSON-Austausch gerendert (Single Page Application).
• CouchDB als Hauptdatenbank.
• Redis als Datenbank für die Synchronisation auf Anwendungsseite und die Protokolle.
• TypeScript für die Oberfläche (Webapp).
• Node.js- / Express-Backend, das die internen Engines orchestriert (api, webapp, portal, panel, ical, mcp, oauth2 usw.).
• C++ für den Generierungsalgorithmus, der auf dedizierten, bei Bedarf gestarteten VMs ausgeführt wird.

Sicherheit

• HTTPS für die nach außen exponierte Kommunikation.
• Cloudflare als ausschließliche Eingangstür (Schutz vor DDOS).
• Passwörter, die clientseitig mit scrypt vorgehasht und dann serverseitig erneut gehasht und gesalzen werden. Sie werden weder im Klartext gespeichert noch übertragen.
• JWT-Authentifizierung mit Signaturschlüsseln und kurzer Lebensdauer; eine Rotation oder ein Widerruf eines Schlüssels kann signierte Token ungültig machen.
• Freigabelinks, die signiert und ablaufbar sind, an das erzeugende Konto gebunden und durch eine Passwortänderung oder Deaktivierung dieses Kontos ungültig gemacht werden.
• API-Token mit einem Wurzelschlüssel und abgeleiteten Token, Endpoint-Scopes und Ablaufzeiten.
• OIDC / SSO verfügbar je nach Vertrag und Konfiguration des Kontos.
• JSON-Export und interne Sicherungen für die Reversibilität der Daten.

Nutzerrollen

Omniscol unterscheidet auf Schulseite mehrere Rollen:

Die Zuordnung zwischen diesen Bezeichnungen und den technischen Rollen-Identifikatoren wird in Benutzer und Rollen ausführlich beschrieben.

Ein und derselbe Nutzer kann mehrere Rollen gleichzeitig innehaben. Eine Lehrkraft, die an der Planung mitwirkt, kann beispielsweise zugleich Lehrkraft und Administrator sein.

Die Rolle Freigabelink entspricht keinem klassischen Nutzerkonto. Es handelt sich um signierte Links: Die Web-Links für Stundenpläne sind schreibgeschützt, während bestimmte gezielte Links eine begrenzte Aktion erlauben können, etwa die Eingabe der Verfügbarkeiten einer Lehrkraft bis zu einem Ablaufdatum.

Darüber hinaus gibt es interne Rollen, die den Teams von Omniscol vorbehalten sind: Plattformverwaltung, Übersetzung, kaufmännische Aktivitäten und Vertriebspartner. Einige dieser Konten dürfen sich aus Wartungsgründen bei den Konten der Schulen anmelden. Sie treten dann als Superadministratoren der Schule auf, mit mehr Möglichkeiten als ein Administrator: Import von Rohdaten in die Datenbank, Aktivierung oder Deaktivierung kostenpflichtiger Optionen, Anmeldung im Namen eines Nutzers. Diese Zugriffe lösen sichtbare Anmeldewarnungen aus, und ihre Token laufen sehr schnell ab. Große Macht bringt große Verantwortung mit sich.

Module

Die in einem Standardkonto sichtbaren Module:

• Startseite (home) — Einstiegsseite und Tagesübersicht.
• Stundenpläne (schedules) — Einsicht und punktuelle Änderungen.
• Dashboard (dashboard) — Statistiken zu Belegung und Deputat.
• Abwesenheitsverwaltung (absences) — Meldungen und Vertretungen.
• Stundenplanverwaltung (timetables) — Aufbau, Generierung und Veröffentlichung der Stundenpläne.
• Verwaltung (admin) — Nutzer, Einstellungen, Import / Export und Integrationen.

Je nach Vertrag können weitere Module erscheinen, insbesondere Personaleinsatz für die Planung der Aufsichts- und Betreuungsaufgaben.

Mehrere Schulen

Jede Schule ist auf Serverseite logisch getrennt und greift auf ihre eigene Domain zu. Die Daten einer Schule sind für die anderen Schulen aus der Anwendung heraus nicht sichtbar. Auf Anfrage lässt sich hingegen ein Kommunikationskanal zwischen den getrennten Konten aktivieren, um die Belegungskonflikte von Räumen und Lehrkräften zu teilen. Das ist sehr nützlich bei gemeinsam genutzten Gebäuden oder für eine Gruppe von Schulen, die sich Ressourcen teilen.