Termin- und Anwesenheitsprozesse als geregelter Portal-Workflow.
Wer darf auf einen Termin reagieren? Was passiert bei einer Verschiebung? Und wie bleibt die Entscheidung nachvollziehbar? Dieser Einblick zeigt einen konkreten Ausschnitt des Gauss-Academy-Portals – mit getrennten Rollen, fachlichen Regeln und einem administrativen Verlauf.
Muharrem Uzun (mu digital) hat an der technischen Umsetzung des dargestellten Termin- und Anwesenheitsworkflows mitgewirkt. KERNSTEG zeigt diesen abgegrenzten Projekteinblick heute als technische Referenz.
01 / PROJEKTKONTEXT
Ein Workflow im bestehenden Lernportal.
Das geschützte Portal bildet Nutzerrollen und Abläufe rund um Schüler, Erziehungsberechtigte, Lehrkräfte, Kurse und Unterricht ab. Hier geht es ausschließlich um die Rückmeldung zu Terminen und die anschließende Dokumentation der Anwesenheit.
Reales Projekt, originale Benutzeroberflächen. Die drei gezeigten Aufnahmen verwenden synthetische Testdaten und unterschiedliche Testszenarien.
02 / ENTSCHEIDUNGEN UND ZUSTÄNDE
Drei Perspektiven auf den Termin.
SCHÜLER / ERNEUTE RÜCKMELDUNG
Ein verschobener Beginn braucht eine neue Entscheidung.
Die Administration verändert den Unterrichtsbeginn. Eine bereits erfolgte Rückmeldung erhält den Zustand „Erneute Bestätigung erforderlich“. Der Schüler sieht den neuen eigenen Termin und kann vor Beginn bestätigen oder absagen. Die folgende Aktion wird im administrativen Verlauf festgehalten.
Schüleransicht: erneute Bestätigung nach verschobenem Unterrichtsbeginn. Testvorschau mit synthetischen Daten. Die Aufnahme ist vertikal scrollbar. Vollständige Originalaufnahme öffnen↗
GUARDIAN / ABSAGE
Für ein zugeordnetes Kind absagen.
Der Guardian kann den kommenden Termin eines aktiv zugeordneten Kindes absagen. Der Server ordnet die Absage als rechtzeitig oder verspätet ein. Die gezeigte Testansicht bestätigt die gespeicherte rechtzeitige Absage; die Administration kann die Aktion im Verlauf nachvollziehen.
Guardian-Ansicht: gespeicherte rechtzeitige Absage. Testvorschau mit synthetischen Daten. Die Aufnahme ist vertikal scrollbar. Vollständige Originalaufnahme öffnen↗
ADMINISTRATION / VERLAUF
Sehen, wer wann was verändert hat.
Der administrative Testverlauf zeigt Schülerabsage, Terminverschiebung und Guardian-Absage mit vorherigem und neuem Zustand. Frühere Rückmeldungen und damalige Fristergebnisse bleiben erhalten.
Die tatsächliche Teilnahme ist eine eigene Entscheidung nach Unterrichtsende. Sie wird durch die Administration dokumentiert und folgt nicht automatisch aus einer Bestätigung oder Absage.
Administration: Aktionen und Zustandsänderungen im Testverlauf. Testvorschau mit synthetischen Daten. Die Aufnahme ist vertikal scrollbar. Vollständige Originalaufnahme öffnen↗
03 / ROLLEN UND BERECHTIGUNGEN
Die Zuständigkeit endet an einer klaren Grenze.
Schüler
Eigene kommende Termine bestätigen oder absagen – vor Unterrichtsbeginn. Nach einer Verschiebung des Beginns eine erneute Rückmeldung geben.
Guardian
Kommende Termine aktiv zugeordneter Kinder absagen – vor Unterrichtsbeginn. Keine Bestätigung und keine Dokumentation tatsächlicher Anwesenheit.
Administration
Nach Unterrichtsende tatsächliche Teilnahme oder Nichtteilnahme dokumentieren. Den protokollierten Verlauf des jeweiligen Termins einsehen.
Lehrkraft
Dem Unterricht zugeordnet. Die neue operative Anwesenheits-API in V1 bietet der Rolle allein keine eigenen Lese- oder Schreibrechte.
04 / TECHNISCHE UMSETZUNG
Was hier technisch interessant ist.
Die Zuordnung zählt, nicht nur die Rolle.
Berechtigungen
Der Server prüft die angemeldete Rolle und den konkreten Teilnehmerzugriff. Bei Guardian-Absagen wird die aktive Zuordnung zum Kind auch innerhalb der Schreibtransaktion geprüft.
Fristen werden am tatsächlichen Aktionszeitpunkt geprüft.
Zeit- und Statusregeln
Die Datenbankzeit entscheidet: Mindestens 24 Stunden vor Unterrichtsbeginn gilt eine Absage als rechtzeitig. Ein geänderter Beginn setzt bereits erfolgte Rückmeldungen auf „Erneute Bestätigung erforderlich“. Frühere Absagezeitpunkte und Fristergebnisse bleiben erhalten.
Statusänderung und Verlauf gehören zusammen.
Transaktionen & Versionen
Status und Audit-Eintrag werden in derselben Transaktion gespeichert. Ein fehlgeschlagenes Audit-Schreiben rollt die Änderung zurück; dieser Fehlerfall ist im vorhandenen Modultest geprüft. Veraltete Termin- oder Teilnehmerversionen werden zurückgewiesen.
Die administrative Aktion hat eine zusätzliche Grenze.
Admin-Zugang
Die Anwesenheitsaktionen der Administration erfordern die bestehende Sitzungs-, Rollen- und MFA-Prüfung. Teilnahme oder Nichtteilnahme kann erst nach Unterrichtsende dokumentiert werden; Korrekturen erzeugen neue Protokolleinträge.
Der Workflow erweitert das vorhandene Datenmodell.
Migration
Die Erweiterung ergänzt Rückmeldestatus, Zeitpunkte, Fristeinordnung und Version an der Teilnehmerzeile. Eine weitere Migration ergänzt den Zustand für erneute Bestätigung. Vorhandene Anwesenheitsdaten werden beibehalten.
05 / EINORDNUNG
Ein abgegrenzter technischer Projekteinblick.
Die Referenz zeigt den Termin- und Anwesenheitsworkflow, nicht sämtliche Funktionen des Gauss-Academy-Portals. Die originalen UI-Aufnahmen verwenden Testdaten. Sie zeigen technische Zustände und Entscheidungen; Aussagen zu Nutzerzahlen oder wirtschaftlichen Ergebnissen werden daraus nicht abgeleitet.
Der Bezug zu KERNSTEG liegt in der technischen Projektarbeit: Rollen, Zustände und fachliche Entscheidungen als zusammenhängendes Softwaresystem umsetzen.
