sonst_git-fortbildung/GitAdministrationKurzdokumentation.adoc

= 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.