< Einbinden von LTI-Tools | Admin-Dokumentation | Was tun im Notfall? >

1.  Prinzipien

Seit Stud.IP Version 1.3 gibt es einen integrierten Mechanismus, bestimmte Nutzeraktionen zu protokollieren. Dabei gelten folgende Grundsätze:

• Zugriff auf die Log-Informationen haben nur Root-Nutzer
• Es werden nur wenige Aktionen geloggt, die vor allem für die Klärung administrativer Vorgänge notwendig sind
• Es ist nicht möglich, in Stud.IP nach Aktionen bestimmter Nutzer zu suchen, sondern nur nach Aktionen, die bestimmte Objekte betreffen (Veranstaltungen, Einrichtungen, Räume etc.)

2.  Nutzung

Die Logging-Einträge sind für Roots unter "Globale Einstellungen -> Log" zugänglich.

2.1  Logging-Einträge suchen und abrufen

Bei der Suche kann nach 2 Kriterien gefiltert werden:

1. Welche Aktionen sollen angezeigt werden? (Default: alle)
2. Für welche Objekte (Veranstaltungen, Einrichtungen, Nutzer, Ressourcen) sollen Aktionen angezeigt werden? (Default: alle)

Ein Klick auf "Anzeigen" löst die Suche mit den eingestellten Filter- und Darstellungsoptionen (kompakt oder ausführlich) aus.

Nach Auswahl eines Objekttyps kann das Eingabefeld neben der Objekttypauswahl zur Suche eines Objekts verwendt werden. Nach Klick auf "Anzeigen" erscheint dann zunächst eine Auswahlliste passender Objekte, er der nächste Klick auf Anzeigen löst tatsächlich die Suche aus.

Die angezeigten Events sind chronologisch rückläufig sortiert, d.h. neuere Events stehen weiter oben. Bei mehr als 50 gefundenen Events werden die Ergebnisse paginiert, so dass jeweils 50 Events pro Seite angezeigt werden.

Suche nach Veranstaltungs- und Einrichtungsevents

Veranstaltungen und Einrichtungen sind alle Events zugeordnet, die sich auf Ihre Grunddaten, auf Termin- und Ortsangaben, Zugangsberechtigungen und vor allem auch Personenzuordnungen beziehen. Sie können unter den Log-Events der Veranstaltung als z.B. herausfinden (entsprechende Konfiguration vorausgesetzt - s.u.), von wem und wann Zugangsberechtigungen geändert wurden, welche Personen sich selbst ein- und ausgetragen haben oder von wem und wann eine Veranstaltung angelegt wurde.

Suche nach Personen-Events

Die suche nach Personen-Events ermöglich kein umfassendes Tracking der Aktivitäten einer Person. Vielmehr sind vor allem Informationen über Veränderungen an den Basisdaten eines Accounts sowie Informationen über Einrichtungs- und Veranstaltungszuordnung zugänglich.

Suche nach Ressourcen-Events

Ressourcen-Events sind vor allem dann relevant, wenn die Ressourcen- bzw. Raumverwaltung intensiv genutzt wird. Wann und von wem Buchungen vorgenommen oder aufgehoben wurden, lässt sich mit der Log-Suche nachvollziehen.

2.2  Logging konfigurieren

Der Untermenupunkt "Einstellungen" führt zu einer Übersicht der vorhandenen Log-Aktionen. An dieser Stelle können Sie sehen:

• interne ID der Log-Aktion
• Kurzbeschreibung der Aktion
• Anzeigetemplate der Aktion
• Anzahl vorhandener Events pro Aktion
• wird die Aktion aktiv geloggt?
• wie lange werden Events für diese Aktion aufbewahrt?

Der Edit-Knopf ganz rechts ermöglicht es, Beschreibung, Template, Aktivität und Ablaufdauer zu verändern. Hinweise:

• Der Beschreibungstext ist nur für diese Auflistung relevant.
• Die Syntax für die Templates wird unten erläutert.
• Um alle Events zu einer Aktion zu löschen, setzen Sie die Ablaufdauer auf 0 Tage.

3.  Erweiterung

3.1  Neue Logging-Aktionen definieren

Es gibt zwei neue Tabellen:

1. log_actions

Entählt Beschreibungen und Daten von Aktionen, wie z.B. "Anlegen einer neuen Veranstaltung".

CREATE TABLE `log_actions` (
`action_id` INT( 10 ) NOT NULL AUTO_INCREMENT , // ID
`name` VARCHAR( 128 ) NOT NULL , // Bezeichner, wird auch im Code verwendet
`description` VARCHAR(64),  // Kurzbeschreibung für Suchinterface
`info_template` TEXT, // Template für Klartextausgabe
`active` TINYINT( 1 ) DEFAULT '1' NOT NULL , // derzeit aktiv?
`expires` INT( 20 ) , // Anzahl Sekunden bis automatischer Löschung
   PRIMARY KEY ( `action_id` )
  );

Ein Eintrag sieht dann z.B. so aus:

Der Info-Template-String kann ein paar Platzhalter enthalten, insgesamt wird daraus bei der Anzeige des Logs der Text generiert, der oben im Scrrenshot zu sehen ist.

expires kann genutzt werden, um Einträge nach einer bestimmten Zeit automatisch löschen zu lassen, z.B. aus datenschutzgründen oder zum Platz sparen. Über ein spezielles Interface (noch nich implementiert) kann das Logging bestimmter Aktionen einfach ein- und ausgeschaltet werden.

Die einzelnen Events werden in einer zweiten Tabelle gespeichert:

2. log_events

CREATE TABLE `log_events` (
`event_id` INT( 20 ) UNSIGNED NOT NULL AUTO_INCREMENT , // ID
`timestamp` INT( 20 ) NOT NULL , // Unix-Timestamp
`user_id` VARCHAR( 32 ) NOT NULL , // Handelnder Nutzer (Subjekt)
`action_id` INT( 10 ) NOT NULL , // Handlung (Verb)
`affected_range_id` VARCHAR( 32 ) , // primär betroffenes Objekt (direktes Objekt)
`coaffected_range_id` VARCHAR( 32 ) , // sekundär betroffenes Objekt (indirektes Objekt)
`info` TEXT, // zusätzlicher Informationstext
`dbg_info` TEXT, // zusätzliche technische Informationen
   PRIMARY KEY ( `event_id` )
);

info_templates können folgende Platzhalter beinhalten:

• %user - Name + Link des Benutzers
• %sem(%[co]affected) - Name + Link einer Veranstaltung
• %res(%[co]affected) - Name + Link einer Ressource

Mal ein Beispiel:

Es gibt ein Event mit folgenden Werten:

event_id = ...
timestamp = 11...
user_id = User-ID von Tobias
action_id = Action-ID von "RES_ASSIGN"
affected_range_id = Seminar-ID von "Strafrecht I"
coaffected_range_id = Ressourcen-ID von "Stadthalle"
info = "Montags, 10-12 Uhr"
dbg_info = "...egal..."

Das info_template sieht für das Event RES_ASSIGN so aus: "%user bucht %res(%coaffected), %info für %sem(%affected)"

Das führt dann zu: "Tobias bucht Stadthalle, Montags, 10-12 Uhr für Strafrecht I."

D.h. das info_template kann verschiedene Platzhalter enthalten, die dann mit Text (und Links) aus den Werten aus log_events ersetzt werden. Info enthält nur zusätzliche Infos, die nicht in affected oder coaffected abgelegt werden können. Nach Werten in info kann man dann natürlich auch nicht Suchen oder sortieren. Text und Verlinkung werden dann erzeugt, wenn Root sich über das Anzeigeinterface Infos anzeigen lässt.

3.2  Logging-API

Durch den gewählten Ansatz leistet das Logging zweierlei:

• Lesbare Ausgaben in natürlicher Sprache
• Volle Durchsuchbarkeit nach betroffenen Objekte (Veranst., Räume, Einrichtungen)

Im Code müssen die Stellen identifiziert werden, an denen eine Aktion ausgelöst wird und meist eine Zeile wie:

log_event("SEM_CREATE",$sem_id);

eingefügt werden. Sind mehr als zwei Objekte betroffen, kommen die Zusatzinformationen (nicht durchsuchbar) in den Infotext, z.B. die Angabe über die gebuchte Zeit beim Auflösen einer Raumanfrage. In die Debug-Infos können z.B. Details über die Stelle im Code eingebaut werden, von der aus die Aktion ausgeführt wurde, komplette Queries abegelegt werden etc.