Version 1.0.0 (2025-02-18): Version 1.0.0

GitAdministrationKurzdokumentation.adoc

@@ -0,0 +1,116 @@
+= Administration der Online-Umgebung
+:author: Thomas Niesenhaus <thomas.niesenhaus@zsl-rska.de>
+include::kapitel-settings.adoc[]
+
+== Nutzerinnen und Nutzer zentral anlegen
+Beim Upload einer CSV werden diverse benutzerbezogene Kriterien vom Controller überprüft und bei
+Bedarf angepasst. Der CSV-Upload findet getrennt nach Lehrkräften sowie Schülerinnen und
+Schülern statt (in Umsetzung). Es muss beim Upload der Radiobutton gesetzt werden (Lehrkräfte oder
+Schülerinnen und Schüler). Dadurch wird Nutzerinnen und Nutzern auch die jeweilige Rolle
+zugewiesen.
+
+=== CSV-Upload
+Zunächst findet ein Abgleich der hochgeladenen CSV-Datei statt. Dabei wird wie folgt verfahren:
+
+* Benutzer in DB und CSV vorhanden, dann Aktualisierungen übernehmen
+* Benutzer in DB vorhanden, aber nicht in CSV, dann Benutzer/in deaktivieren
+* Benutzer in DB nicht vorhanden, aber in CSV, dann Nutzer/-in neu anlegen
+
+=== Nutzer
+Folgende Daten werden aus der CSV-Datei importiert, verarbeitet, generiert und
+gespeichert:
+
+* Vorname (importiert)
+* Nachname (importiert)
+* Primärschlüssel (importiert)
+* Klassenzuordnung (importiert)
+* E-Mail Adresse (importiert, falls vorhanden, ansonsten Vergabe einer Platzhalter E-Mail
+Adresse)
+* Initialpasswort (generiert)
+* Rolle (ergibt sich aus dem Upload)
+
+==== Nutzer anlegen
+Dies aus der CSV übernommenen Vor- und Nachnamen werden:
+
+* transponiert
+* Umlaute werden entfernt
+* doppelte Vornamen werden entfernt. Z.B.: aus "Ben Marlon MüllerHofholz" wird
+"Ben.MuellerHofholz"
+* Der Benutzer jedes Nutzers Users wird nach folgendem Schema
+erzeugt: Vorname.Nachname
+* Bei identischen Vornamen, Nachnamen und/oder Geburtsnamen jedoch unterschiedlicher ID
+wird an den generierten Nutzernamen eine fortlaufende Nummer angehängt.
+
+==== Nutzerzuordnung
+Beim Import von Nutzern aus der CSV-Datei werden diese bereits in die richtigen Klassen
+(Organisationen) eingepflegt. Nutzer, die sowohl in der CSV, als auch in der DB vorhanden sind,
+werden bei Bedarf neuen Klassen (Neues Schuljahr) oder zusätzlichen Organisationen (zB neue
+Lerngruppe) zugeordnet. Vorhandene Nutzer (DB + CSV) werden aus allen, nicht in der CSV zu
+diesem jeweiligen Nutzer hinterlegten Klassen gelöscht.
+
+== Passwörter
+=== Initialpasswort
+Beim Import wird automatisch ein Initialpasswort generiert, welches bei der ersten Anmeldung
+geändert werden muss. Die Lehrkraft erhält per E-Mail eine Liste mit den Nutzerdaten der
+Klasse(n) in denen sie unterrichtet.
+
+=== Passwortreset
+Der Controller spielt je nach Lehrkraft die von ihr unterrichteten Klassen (Organisationen) in der
+GUI aus. Nach Auswahl der Klasse (Organisation) zeigt der Controller die Schülerinnen und
+Schüler der Klasse (Organisation) an. Nun kann die Lehrkraft in der jeweiligen Spalte der
+Schülerin oder des Schülers den Button „Passwort zurücksetzen“ anklicken. Anschließend wird
+der Lehrkraft ein temporäres Passwort angezeigt, welches bei der nächsten Anmeldung geändert
+werden muss.
+
+== Klassen
+Klassen (Organisationen) werden nach folgendem Schema erstellt:
+
+* Klassen (Organisationen) die beim CSV-Import erzeugt werden, erhalten automatisch ein
+Suffix mit dem Erstellungsjahr. Muster: 10b-2023
+* Jede automatisch angelegte Klasse wird in einer Organisation abgebildet und die
+entsprechenden Nutzer werden dieser Organisation zugeordnet.
+* Eine Organisation "Lehrkräfte" wird einmalig erstellt. Die importierten Lehrkräften werden
+der Organisation automatisch zugeordnet.
+
+Schülerinnen und Schüler können keine Klassen anlegen.
+
+== Repository
+Jede Organisation (Klasse) erhält automatisch ein Repository. Der Besitzer des Repository ist die
+unterrichtende Lehrkraft. Repositories werden nach folgendem Schema erzeugt:
+
+* Der Zeitpunkt der Repoanlage wird automatisch im Repotitel als Suffix angehängt, sofern die
+Anlage durch einen Schüler erfolgt. Z.B. Robotik-2023
+* Repos die in Organisationen liegen können ausschließlich von Lehrkräften erzeugt werden.
+* Maximal 50 Repos je Nutzer.
+
+== Löschroutine
+Die automatische Löschung von Klassen (Organisationen), Repos und Nutzern wird von einer Routine
+übernommen. Dabei wird nach folgendem Schema vorgegangen:
+
+* *Organisationen*:
+** Organisationen mit - im Namen oder automatisch über CSV erzeugte Organisationen
+werden automatisch am 30. September des nachfolgenden Jahres archiviert.
+** Wenn eine langfristige Organisation benötigt wird (z. B. "Informatik-AG"), muss diese
+beim Schul-Verwalter beantragt werden.
+** Nach 365 Tagen erfolgt die automatische Löschung von archivierten Inhalten, dies
+kann nur durch den Schul-Verwalter verhindert werden.
+** Die Organisation "Lehrer" beinhaltet keine automatische Archivierung von Repos.
+* *Nutzer*:
+** 365 Tage nach Deaktivierung erfolgt die automatische Löschung von deaktivierten
+Benutzern und deren Inhalten, dies kann nur durch den Schul-Verwalter verhindert
+werden
+* *Repos*:
+** Repos, die In Organisationen liegen, werden 1 Jahr nach der Anlage automatisch
+archiviert, wenn sie ein - im Namen tragen.
+** 365 Tage nach Archivierung erfolgt die automatische Löschung von archivierten
+Inhalten, dies kann nur durch den Schul-Verwalter verhindert werden.
+Logs
+** Zugriffs-Logs der Schulinstanz werden automatisch nach 21-90 Tagen gelöscht
+
+== Quota
+
+Die Löschroutine trägt einen wesentlichen Teil dazu bei, dass keine unnötigen Daten dauerhaft
+gespeichert werden. Zusätzlich wird GitCamp eine Quota beinhalten (Aktuell noch in der Testphase).
+Die Quota kann über eine Weboberfläche innerhalb GitCamps geändert werden. Für jede Instanz ist
+die Quota bei der Einrichtung identisch. Sollte die Quota von einem Nutzer überschritten werden, so
+werden der Schul-Admin und der Nutzer per E-Mail benachrichtigt.