Beschreibungen vereinheitlichen

[Kuddel071089 9]

Hallo zusammen,

 

bei unseren Usern und Gruppen ist im Beschreibungsfeld immer vermerkt, wann der User erstellt wurde, wer ihne erstellt hat und durch welches Ticket.

 

Da dies nicht immer einheitlich ist (Beispiel: mal 01.01.15 aber auch 15.01.2015) würde ich dies gern vereinheitlichen.

 

Sofern sich im Beschreibungsfeld nur eine Zeile befindet, bekomme ich das ersetzen via CSV-Export und Import hin, sofern ich irgendwie nach Usern mit nur einer Beschreibungszeile filtern kann.

 

Das größter Problem ist für mich aber, wie ich die zweite zeile bearbeiten kann, da der Export ein Fließtext ist.

 

Ist-Zustand:

10.10.15/XY/REQ-2015-12345 (User erstellt)
oder
11.10.2015/YX/-SR-2015-65481(User erstellt)
02.02.16/ZZ/REQ-2016-12354 (Mail Account hinzugefügt)

Soll:

10.10.15/XY/REQ-2015-12345 (User erstellt)
 
11.10.15/YX/REQ-2015-65481 (User erstellt)
02.02.16/ZZ/REQ-2016-12354 (Mail Account hinzugefügt)

Ich hoffe ihr versteht was ich meine.

 

Danke schon einmal für die Hilfe

[NilsK 2.930]

Moin,

 

das wird mit einem CSV-Export wahrscheinlich nicht funktionieren, weil dort der Zeilenumbruch das Kennzeichen für einen neuen Datensatz ist.

 

Ich würde den Ansatz aber noch mal grundsätzlich überdenken. Für eine administrative Historie dieser Art sind AD-Felder i.d.R. nicht gut geeignet. Solche Informationen würde ich in einer separaten Datenbank ablegen. Das description-Attribut hat auch ein Limit bei 1024 Zeichen, womit es sich für eine Historie noch weniger eignet. Schon allein dein Beispiel hat 145 Zeichen, da wäre dann bei 20-30 Zeilen der Art Ende.

(Abgesehen davon, ist das Attribut auch seltsam implementiert, wodurch manche externen Tools bei längeren Einträgen schnell auf die Nase fallen.)

 

Gruß, Nils

bearbeitet 27. Juli 2016 von NilsK

[daabm 1.348]

Naja, adminDescription und adminDisplayname kann man für sowas schon missbrauchen :-)

csvde und dann "Excel ist Admins Liebling"... Alles zu finden bei Nils - http://www.faq-o-matic.de

Aber grundsätzlich hat er natürlich recht - das ist überdenkenswert.

[NilsK 2.930]

Moin,

 

Naja, adminDescription und adminDisplayname kann man für sowas schon missbrauchen :-)

 

dann wäre description aber wohl die bessere Wahl, weil es im Standard-GUI sichtbar ist. Die Begrenzung auf 1024 Zeichen gilt bei adminDescription nämlich genauso, man würde also einen Vorteil (anderes Feld) durch einen vermutlich größeren Nachteil (nicht direkt sichtbar) einkaufen, würde die Beschränkungen (Textmenge) aber beibehalten.

 

Wenn man schon die Historie direkt im AD speichern will (was ich, wie gesagt, für nicht gut halte - nicht zuletzt, weil dort schnell Informationen drinstehen, die nur für Admins sind, und dann hat man auch noch ein Berechtigungsproblem am Hals), dann wäre zu erwägen, ob man nicht das Schema um ein eigenes Multivalue-Feld erweitert. Dann setzt man pro Eintrag einen neuen Wert ins Array, was technisch viel sauberer wäre.

 

Sobald man allerdings anfängt, darüber ernsthaft nachzudenken (hab ich alles schon bei Kunden durch ...), stellt man fest, dass ein separates Change Management weit besser ist. Da muss man dann nämlich nicht mit irgendwelchen Syntaxbeschränkungen innerhalb eines Textfelds arbeiten, sondern kann pro Datensatz separate, wohldefinierte Felder wie Zeitpunkt, Admin-User und Text trennen und teils automatisch befüllen lassen.

 

Gruß, Nils

[blub 115]

 

10.10.15/XY/REQ-2015-12345 (User erstellt)

Die Information "User erstellt am 10.10.15" hast du redundant an mindestens drei Stellen

- dieses unstrukturierte Beschreibungsfeld

- im UserCreated-Attribut

- in deinem Ticket REQ-2015-12345

- ..

Redundanz ist nicht gut für Datensätze.

 

Ich würde ins AD nur Daten schreiben, nach denen man mit LDAP sinnvoll filtern kann.

Prinzipiell ist euer Ansinnen nach "Datenhygiene" sicher sinnvoll.  Useraccounts, von denen keiner mehr weiß, "wer, warum und wann die erstellt bzw. beauftragt hat", sind ein erhebliches Risiko!

 

blub

[lefg 276]

Moin,

 

früher habe ich auch mal Notizen/Bemerkungen geführt, das wurde schnell lästig. Und ich fragte mich mal, wozu brauche ich das? Es  war für mich nicht erkennbar.

 

- Benutzerkonten werden angelegt auf Anweisung des Personalabteilung, Rückmeldung

- Löschen etc geschieht auf Anweisung der Personalabteilung, Rückmeldung

- Die Personalabteilung kann sich das anschauen, kontrollieren, überprüfen

 

Der nächste Schritt: die Personalabteilung macht des selbst automatisiert, die IT hat damit nichts mehr zu tun. Der Admin pflegt das Skript.

bearbeitet 28. Juli 2016 von lefg