[Allegro] acon: Operator code beim Speichern

[Thomas Berger]

Lieber Herr Eversberg, liebe Liste,

>> Da diese Funktionen tendenziell Benutzer ausserhalb des engeren
>> eigenen Mitarbeiterkreises betreffen koennen (Mitarbeiter Uni-
>> Bibliographie, Selbsverbucher, ...), hat die Speicherung des
>> "echten" Benutzernamens (der auch eine IP-Adresse oder ein
>> Pseudonym sein mag: Es kommt nicht darauf an, ob es der "echte
>> Name" des Benutzers) in der Datenbank heftige datenschutzrechtliche
>> Konsequenzen.
>>
> Tatsächlich? Und wirklich heftige?
> Handelt es sich in der Tat um ein personenbezogenes Datum im Sinne
> des Gesetzes und strafbewehrt durch dasselbe?

Sie haben selber die Antworten gegeben: Da die Motivation ist,
"Verursacher" von irgend etwas dingfest zu machen, duerfte
jede Loesung, die ansatzweise etwas taugt, etwas mit einem
Speichern von personenbezogenen Daten zu tun haben, die bislang
nicht gespeichert wurden. Und "personenbezogene Daten" ist auch
genau der Knackpunkt. Und da kommt es auch weniger auf den Sinn
des Gesetzes an, sondern auf die gemeinsame Linie der Daten-
schutzbeauftragten der Laender und des Bundes. Zu "strafbewehrt"
oder nicht kann ich wenig sagen (ausser: IANAL), wissen- und
willentlich Gesetze zu missachten duerfte im hiesigen Kreis zudem
allerhand dienstrechtliche Konsequenzen haben, da kenne ich mich
aber noch weniger aus...

[Nach meiner unmassgeblichen Meinung ist das Speichern von
Bearbeitervermerken bei vom eigenen Personal durchgefuehrten
Taetigkeiten etwa so, wie es PRESTO und a99 seit immer taten,
unbedenklich, insbesondere wenn es im sog. "Verfahrensverzeichnis"
der Institution hinterlegt ist und von der Mitarbeitervertretung
abgenickt. D.h. es kommt auch da natuerlich auf den Zweck an:
Nimmt man #99e zum Anlass, jeden Herbst den "unproduktivsten
Mitarbeiter des Jahres" zu ermitteln und zu feuern, duerfte es
Probleme geben. Oder realistischer: Bevor man solche Zeit-
stempel heranzieht um sich ein Bild darueber zu machen, ob und
welche Mitarbeiter regelmaessig ihre Mittagspause ueberziehen,
sollte man sich vorher durch einen Juristen beraten lassen]


>> Insofern waere ich dafuer, die "anonyme" Kennung aus avanti.con[f]
>> weiterhin in die Zeitstempel fliessen zu lassen und sich fuer das
>> Vermerken von "Verursachern" einen neuen Mechanismus auszudenken,
>> entweder eine Zusatzkategorie oder - vermutlich juristisch
>> belastbarer - einen Logging-Mechanismus ausserhalb der eigentlichen
>> Datenbank, etwa in dem acon Zeitstempel, Kennung und Datensatznummern
>> von Speicherungen in eine Protokolldatei schreibt.
>>
> Würde eine Zusatzkategorie einen entscheidend anderen
> datenschutzrechtlichen Status haben als die Eintragung der Kennung
> im Zeitstempel? Der logische Zusammenhang bliebe doch gegeben.

Eine Zusatzkategorie haette immerhin den Vorteil, dass man sie
regelmaessig nach ein paar Tagen oder anlassbezogen komplett loeschen
kann, ohne dann ganz ohne Zeitstempel da zu stehen.

"Externe" Speicherung haette den weiteren Vorteil, dass sich
der Kreis der Anwender, die Zugriff auf diese Daten haben,
stark einschraenken laesst (der /Vorteil/ besteht also tatsaechlich
darin, dass der beabsichtigte Zweck sich nicht mehr so einfach
realisieren laesst).


> Wie auch immer, Bergers Vorstellungen wären außerhalb von acon
> realisierbar, zumal im Rahmen von a35, weil dabei eigentlich alles
> über Jobs läuft.  Man hätte hier nur den Job  prsave.job, denn der
> erledigt jede Speicherung, zu modifizieren.
> Ebenso wäre unser Vorschlag dann keineswegs obligatorisch, sondern
> optional, im prsave.job mit zwei Zeilen so oder so zu regeln, ganz
> wie es der Anwender für besser hält. Nur die neue set-Option wäre
> in acon einzubauen, im Normalfall bliebe alles beim alten. Nichts wäre
> präjudiziert und festgeschrieben, man gewänne im Gegenteil einen
> Freiheitsgrad.

Faende ich gut. V.a. wenn es ueber eine Konfigurationseinstellung
von a35 ginge und der eigentliche Job dafuer vom Anwender nicht
modifiziert werden muesste.

viele Gruesse
Thomas Berger