Löschfunktion für sync-ldap2db.pl

[paulemann]

Hallo zusammen.
Ich Nutze OTRS 3.0.11 Windows Server 2008 R2, Eingesetzt wird das System in einem kleinen Unternehmen mit 120 Mitarbeitern. Die Mitarbeiterdaten holen wir uns per ldap Datenquelle. Jetzt hat sich der Personalrat überlegt, das die Namen ausgeschiedener Mitarbeiter nicht mehr mit von ihnen erstellten Tickets in Verbindung gebracht werden dürfen. Wenn also jemand das Unternehmen verlässt, soll er nicht mehr im AD stehen und der Name des Mitarbeiters muss in der Spalte customer_user_id der Tabelle ticket auf anonym gesetzt werden.

Nun war meine Überlegung diesen Vorgang der Anonymisierung zu automatisieren.

Das Script sync-ldap2db könnte ich über einen CronJob wöchentlich laufen lassen (es holt auch zuverlässig alle Mitarbeiterdaten ab und schreibt sie in die Tabelle customer_user). Nur leider werden keine Mitarbeiter in der Tabelle customer_user gelöscht, die nicht mehr im AD stehen.

Den Rest würde ich über einen Trigger lösen, der eben dann die Mitarbeiter in der Spalte customer_user_id (Tabelle:ticket) auf anonym setzt, die aus der Spalte customer_id (Tabelle customer_user) gelöscht werden. Der Trigger funktioniert auch nur nützt mir das leider wenig, wenn beim Sync keine Mitarbeiter aus der Spalte customer_user entfernt werden, die eben nicht mehr im AD stehen.

Deshalb meine Frage: Hat hier Irgendjemand schonmal das Script sync-ldap2db dahingehend geändert, das auch Mitarbeiterdatensätze gelöscht werden, die nicht mehr im AD stehen?

Über Tips und Anregungen jeglicher Art würde ich mich freuen.
MFG
Paulemann

[jojo]

Hallo,

wenn Du direkt auf das LDAP zugreifst anstannt die Daten zu kopieren ist das Problem gar nicht erst vorhanden...

[paulemann]

Was passiert denn dann, wenn ein Mitarbeiter aus dem AD entfernt wird ?
Ich vermute, dass der Mitarbeiter dann zwar nicht mehr im AD steht, jedoch seine alten Tickets immernoch fröhlich mit seinem Namen (customer_user_id) in der Datenbank stehen. Bin ich da auf dem falschen Dampfer ???
Es wird ja wohl kaum ne cascadierende Fremdschlüsselbeziehung zwischen der Ticket Tabelle und dem AD herschen.
Es reicht meinen Vorgesetzten leider nicht aus den probaten Weg zu gehen und einfach alle Tickets eines bestimmten Alters zu anonymisieren (Obwohl das den ganzen Sinn eines Ticketsystems pervertieren würde).
Das wäre ja bequem per generic agent machbar. Ich soll halt dafür sorgen, dass nur die Tickets anonymisiert werden zu denen es keinen Mitarbeiter/Ersteller mehr gibt (und das automatisch).

[jojo]

Die Customer_User_ID und die Customer_ID bleiben in beiden Fällen im Ticket drin, unabhängig davon wo die Kunden gespeichert werden.

Habt Ihr bereits anonymisierte Loginnamen? Am besten sollte auch Eure Revision mal drüber schauen, es kann durchaus sein, das die Daten auch für mehrere Jahre nachvollziehbar sein müssen, auch wenn der Mitarbeiter nicht mehr im Unternehmen ist.

[paulemann]

Die Logins sind nicht anonym (Mix aus Nach- und Vorname). Die Unternehmensleitung macht gemeinsame Sache mit dem Personalrat und die finale Version der Dienstvereinbarung zu diesem Thema sieht bei uns genau diesen Punkt mit der Anonymisierung vor. Und zu allem Überfluss hab ich von Perl und objektorientierter Programmierung an sich (hoffentlich noch) keine Ahnung.
Es müsste aber im Prinzip möglich sein den Überhang an Datensätzen auf der DB Seite zu identifizieren um diesen dann zu löschen.

[jojo]

Da die Daten auch ggf. im Ticket stehen (E-Mail Adressen etc) ist eine vollständige anomysierung fast unmöglich