Add audit logs to supervison

[rschlossarek]

[JohannHoepfner]

@rschlossarek um Liegengebliebenes mal anzugehen: Was genau sind unsere Anforderungen hier? Was müssen wir aufzeichnen, was müssen wir wem anzeigen?

[rschlossarek]

Also vor langer langer Zeit war mal der Wunsch, dass wir jede Änderung der Anwesenheit aufzeichnen und Missbrauch der Aufsichtsfunktion zu verhindern.

Die Idee von #40 war noch, dass Mentor:innen nachvollziehen können, wann sich ihre Mentees umgeschrieben haben (also alle Einschreibungs-, Ausschreibungs- und Verschiebungsevents).

Man könnte das denke ich ganz gut in die Kommentarfunktion integrieren, da die Kommentare eh pro Block und nicht pro Einschreibung speichert (was wir hier brauchen).

Wenn wir für jede soartige Änderung einen nicht änderbaren Kommentar anlegen, sollte das ganz gut gehen.

Dafür müssen wir nur die Datenstruktur dahingehend ändern, dass eine Person mehrere Kommentare abgeben kann, und die Kommentare einen Flag für diese Systemkommentare haben. Im Frontend sollten wir die Kommentare dann auch vor- und nach dem Block einfach mit anzeigen, und aufpassen, dass wir den Kommentar-Knopf noch richtig färben.

[JohannHoepfner]

Kommentare sind natürlich unstrukturiert ziemlich unschön. Alternativ könnten wir einfach einen Invalidated-Timestamp beifügen, der bei aktuellen Einschreibungen null ist.

[rschlossarek]

Unschön, weil sich Einschreibungen in der Dauer verändern können ohne Invalide zu werden (bei verschieben im Block). Außerdem kannst du damit die Änderungen an der Anwesenheit nicht mit protokollieren, da die nicht an die Einschreibung geknüpft sind.

Ich sehe hier aber auch nicht ganz, warum wir strukturierte Daten brauchen sollten.

[JohannHoepfner]

Vor allem, weil ich mir nicht angewöhnen möchte, Berge an Strings in der DB zu speichern. Aber auch, weil mit diesen logs zu rechnen später unangenehm wird, falls wir das mal wollen.

[rschlossarek]

Dann folgender Alternativvorschlag:

{
  studentId: Guid
  blockId: Guid
  timestamp: timestamp
  authorId: Guid
  changeType: Enum // Einschreibung, Anwesenheit
  comment: string // z. B. "Aus {name} ausgeschrieben"
}

Ich fände es unschön, wenn wir eine Tabelle für jede Art Änderung machen müssen. Das wird sonst super nervig für jeden Request zusammenzusuchen.

Und wir sollten halt mit speichern, wer die handelnde Person ist, allein deshalb reicht ein timestamp schonmal nicht.

Schön wäre auch, wenn besondere Gründe mit dokumentiert werden können (z. B. das Losverfahren beim verkleinern der Teilnehmer:innen-Zahl). Mit strings lässt sich das einfach Menschenlesbar machen und ich sehe um ehrlich zu sein nicht, warum wir das schnell maschinenlesbar brauchen sollten. (Für einmalige Auswertungen, von denen ich auch nicht glaube, dass sie kommen werden, kann man auch aus den Strings rekonstruieren)