Univention Bugzilla – Bug 21608
Verbesserung der Infrastruktur für UDM-Module
Last modified: 2017-01-09 15:14:26 CET
Am UDM-Beispiel-Modul (Bug #17915) und auch an anderen Modules ist aufgefallen, daß die Handhabung von "UDM-Optionen" teilweise seht mühsam und fehleranfällig ist. Oft wirkt sich eine UDM-Option auf die LDAP-ObjectClasses aus, die in Objekt hat. 1. Wird eine UDM-Option deaktiviert, wird sehr häufig auch probiert, die ObjectClass zu entfernen. Das gelingt aber nur dann, wenn auch am Objekt alle Attribute entfernt werden, die NUR von dieser ObjectClass bereitgestellt werden. (Prinzipiell kann es mehrere Auxiliary-ObjectClasses geben, deren Attributmengen sich überschneiden.) Etwaige LDAP-Modify-Operation zum Entfernen der dann nicht mehr erlaubten Attribute müssen derzeit immer selber per Hand implementiert werden. Schöner wäre ein force_attribute_remove() und ein force_option_remove(), daß diese Funktionalität für alle Implementierungen zentral zur Verfügung stellt. 2. Beim öffnen eines Objekts, das bereits im LDAP existiert, implementieren viele Module eine Logik, die anhand der ObjectClasses die UDM-Optionen aktiviert. Auch das sollte nach Möglichkeit zentral implementiert sein.
Created attachment 4552 [details] Remove objectClass from object. Für einen Kunden ist ein Skript "univention-ldap-oc-drop" entstanden, daß es erlaubt, beliebige ObjectClasses inklusive der Attribute zu entfernen, die zwingend an die ObjectClass gebunden sind (d.h. es bleiben die Attribute bestehen, die durch die verbleibenden ObjectClasses weiterhin erlaubt sind.) Das kann als Grundlage für den 1. Punkt dienen.
(In reply to Philipp Hahn from comment #0) > Am UDM-Beispiel-Modul (Bug #17915) und auch an anderen Modules ist > aufgefallen, daß die Handhabung von "UDM-Optionen" teilweise seht mühsam und > fehleranfällig ist. Oft wirkt sich eine UDM-Option auf die > LDAP-ObjectClasses aus, die in Objekt hat. > > 1. Wird eine UDM-Option deaktiviert, wird sehr häufig auch probiert, die > ObjectClass zu entfernen. Das gelingt aber nur dann, wenn auch am Objekt > alle Attribute entfernt werden, die NUR von dieser ObjectClass > bereitgestellt werden. (Prinzipiell kann es mehrere Auxiliary-ObjectClasses > geben, deren Attributmengen sich überschneiden.) > Etwaige LDAP-Modify-Operation zum Entfernen der dann nicht mehr erlaubten > Attribute müssen derzeit immer selber per Hand implementiert werden. > Schöner wäre ein force_attribute_remove() und ein force_option_remove(), daß > diese Funktionalität für alle Implementierungen zentral zur Verfügung stellt. We currently don't have a force_attribute_remove/force_option_remove. But we have code which removes object classes which aren't required anymore. > 2. Beim öffnen eines Objekts, das bereits im LDAP existiert, implementieren > viele Module eine Logik, die anhand der ObjectClasses die UDM-Optionen > aktiviert. Auch das sollte nach Möglichkeit zentral implementiert sein. This is done in simpleLDAP.__init__() now. *** This bug has been marked as a duplicate of bug 41580 ***
<http://errata.software-univention.de/ucs/4.1/208.html>