Univention Bugzilla – Bug 29635
Änderungen von initial nicht gesetzten ComboBox-Werten werden nicht korrekt übernommen
Last modified: 2013-01-15 15:18:23 CET
Der eigentliche Fehler wurde nicht generisch zu 3.1 gelöst, es wurde nur für den speziellen Fall ein Workaround gefunden. Deshalb wird der Bug noch einmal geklont. +++ This bug was initially created as a clone of Bug #26425 +++ Ist in einer Domäne kein Mailserver vorhanden, dann ist beim Anlegen/Bearbeiten eines Benutzers die ComboBox "Erweiterte Einstellungen / Mail / Erweiterte Einstellungen / Mail Home Server" leer. Wird nachträglich ein Mail-Server der Domäne hinzugefügt, enthält die ComboBox eine Liste mit genau einem Element. Dies hat zur Folge, dass beim Öffnen eines Benutzers, für den kein Mail-Home-Server gesetzt ist, der erste Eintrag in der ComboBox ausgewählt wird. Beim Speichern wird dies allerdings nicht als Änderung erkannt. Idealerweise wird beim Anlegen eines neuen Benutzers der erste verfügbare Mail-Server für das Feld ausgewählt und beim Öffnen eines Benutzers ohne Mail-Home-Server das Feld als leer angezeigt. In der ComboBox befindet sich zusätzlich ein leerer Eintrag, der ausgewählt werden kann. Zur Lösung gibt es verschiedene Ansatzpunkte: * Zum Erkennen von Änderungen werden derzeit die Werte des Formulars gesetzt und wieder ausgelesen und dann mit den Werten beim Speichern abgeglichen. Der Vergleich könnte mit den ursprünglichen Werten, die vom Server geschickt wurden vorgenommen werden (das steht auch in Zusammenhang mit Bug 26215) * Es wird ein Default-Template standardmäßig verwendet, dessen Mail-Home-Server bei der Installation der Mail-Komponenten entsprechend gesetzt wird (→ ausgelagert nach Bug 26424) * Es wird der ComboBox ein leerer Listeneintrag hinzugefügt (siehe Bug 26098), dadurch wird allerdings beim Anlegen eines Benutzers der Mail-Server nicht automatisch vorausgewählt (und somit kann dem Benutzer keine Mail zugestellt werden)
Andere Möglichkeit: mit null oder "" kann eine ComboBox leer gesetzt werden, auch wenn es keinen leeren Eintrag gibt.
Bei der Fetchmail Integration betrifft das nur Benutzer, die vor der Installation der Fetchmail Erweiterung angelegt wurden.
Es wurde eine Variante von diesem Vorschlag umgesetzt: * Zum Erkennen von Änderungen werden derzeit die Werte des Formulars gesetzt und wieder ausgelesen und dann mit den Werten beim Speichern abgeglichen. Der Vergleich könnte mit den ursprünglichen Werten, die vom Server geschickt wurden vorgenommen werden (das steht auch in Zusammenhang mit Bug 26215) Der Vorschlag mit dem Template wäre programmatisch kaum umzusetzen, ein manuelles Anlegen von Seiten des Administrators kann aber nicht vorausgesetzt werden. Das Verhalten so, wie es war, durfte aber nicht so bleiben. Der Vorschlag mit den automatisch hinzugefügten leeren Listeneinträgen halte ich für sehr problematisch. Wenn eine Syntax explizit den leeren Eintrag ausschließt, sollte er nicht vom Frontend angeboten werden. Ein Eingreifen in die ComboBox selbst wäre ein so weitreichender Schritt, dass man ihn nicht in einem Errata-Update umsetzen sollte. Folgendes Verhalten jetzt: Bei der UDM-DetailPage werden kurz nach Forminitialisierung die Werte gespeichert. Bei ComboBoxen wird jetzt überprüft, ob dieser Wert überhaupt vom Server geliefert wurde. Wenn nicht, ist davon auszugehen, dass u.U. ein Eintrag automatisch ausgewählt wird (z.B. bei mailHomeServer vor Bug#26425). Also wird in dem Fall der anfänglich gespeicherte Wert vom Formular durch '' überschrieben. So wird die automatische Auswahl als Änderung erkannt. Die QA muss hier aber aufpassen, ob es nicht ein Attribut gibt, das auf diese Weise falsch behandelt werden würde. Wahrscheinlich greift das alles nicht bei MultiInput. Hier muss geprüft werden, ob das problematisch ist. Ein abschließender Satz zu der grundsätzlichen Problematik: Ich bin der Meinung, dass Attribute, die initial leer sein dürfen (weil zum Beispiel kein Mail Server zur Verfügung steht), dann aber nachträglich einen Wert zugewiesen bekommen können, falls die entsprechenden LDAP-Objekte angelegt werden, *immer* weiterhin einen leeren Listeneintrag behalten können sollten. D.h. ich halte es für die Aufgabe des UDM-Entwicklers, dass die Syntax, die er hier vorgesehen hat, einen leeren Listeneintrag zulässt. Wenn er das nicht will, sollte der Wert von Beginn an "required" sein. Anders ausgedrückt: Das Problem hier ist zwar vorhanden, hätte aber eigentlich nie auftauchen dürfen. Wenn man der Meinung ist, jeder Benutzer müsse zwingend ein mailHomeServer haben, dann darf man eben erst Benutzer anlegen, nachdem man einen Mail-Server angelegt hat. Das hier sind meiner Meinung nach eigentlich so viele seperate Bugs, wie es Widgets gibt, die dieses Problem aufweisen. Fixed in univention-management-console-module-udm 3.0.61-1.292.201212212148
Created attachment 4950 [details] Recognize values that are automatically chosen (first possible value) as a change Patch für Errata-Update
Es gibt noch ein Verhalten für die Mailserver-Syntax, die angepasst werden müsste. Beim Anlegen eines neuen Benutzers wird nun kein Mailserver standardmäßig ausgewählt, das ist ungünstig. Der einfachste Workaround hierfür wäre, den leeren Eintrag als letzten anzuzeigen. Ansonsten habe ich Bug 29925 angelegt, der den Idealzustand beschreibt :) .
LDAP_Search hat ein addEmptyValue entsprechendes appendEmptyValue bekommen, mailHomeServer setzt es ein. Fixed in: univention-management-console-module-udm 3.0.61-1.293.201301041824 univention-directory-manager-modules 8.0.99-1.967.201301041756
Das Verhalten ist nicht ganz so wie erwünscht, aber OK: * In einer Domäne ohne Mailserver existiert ein leerer Wert in der Liste. * In einer Domäne mit Mailserver kommt in der Liste zunächst der Mailserver und dann der leere Wert. + Neuer Benutzer → Mailserver ist Defaultwert + Wert kann zurückgenommen werden durch Auswahl des leeren Elements + Editieren eines Benutzers ohne Mailserver → beim Speichern wird in jedem Fall Mailserver gesetzt, da kein Wert für Mailserver übertragen (ist ja nicht gesetzt) und somit der Defaultwert (erst in der Liste) ausgewählt wird Änderung → OK YAML-Datei → OK Patches → FAILED Ich glaube, dass der Patch 020_bug29635.patch obsolet ist, oder? Übernahme 3.1-1 → OK Changelog 3.1-1 → OK
(In reply to comment #7) > ... > Patches → FAILED > Ich glaube, dass der Patch 020_bug29635.patch obsolet ist, oder? mein Fehler → also OK
YAML-Datei: 2013-01-04-univention-directory-manager-modules.yaml
und YAML-Datei: 2013-01-04-univention-management-console-module-udm.yaml
http://errata.univention.de/3.1-errata11.html
http://errata.univention.de/3.1-errata14.html