Extended Attribute Dropdown

german
integration

#1

Hallo,

Ich habe ein “Extended Attribute” erzeugt, dessen Datentyp “string” ist. Das Attribut kann dann im “Advanced” Tab in der entsprechenden Rubrik gefunden und editiert werden. Soweit gut. Nun aber möchte ich dieses Feld zu einer Dropdown-Liste machen und habe versucht, die Anleitung ab 6.4.2 zu befolgen.

Ich habe also eine Syntax-Definition angelegt und diese als Datentyp zugewiesen, was zumindest soweit funktioniert, daß mein Eingabefeld wunschgemäß zu einem Dropdown-Feld wird (mit dem zusätzlichen Leerstring, so wie ich es verlangt habe). Aber die Liste bleibt immer leer, und ich sehe nicht warum. Ich will die Liste mit Servernamen füllen, die entsprechende LDAP-Query von Hand abgesetzt (mit univention-ldapsearch) liefert genau die beabsichtigten Ergebnisse. Da die Server, die ich da ermittle, auch unterschiedliche Rollen haben können, kann ich in der Syntax-Definition keine UDM-Klasse referenzieren, denn ich müßte da immer genau EINE Klasse angeben (siehe Beschreibung von “value” und “attribute”). Deshalb greife ich zurück auf die Methode, die als “LDAP_Search” beschrieben ist, und statt der Felder “attribute” and “value” benutze ich die Felder “ldapattribute” und “ldapvalue”, so wie es unter “UDM API” steht. Hier ist der Ausschnitt, der die Syntax-Definition für den Datentyp “myListOfProperties” erzeugt:

univention-directory-manager settings/syntax create "$@" --ignore_exists \
   --position "cn=my_position,cn=custom attributes,cn=univention,$ldap_base" \
   --set name='myListOfProperties' \
   --set addEmptyValue='1' \
   --set ldapattribute='the_attribute'
   --set filter='(&(univentionService=a_distinct_service)(the_attribute=*))' \
   --set ldapvalue='the_attribute' 

Es soll also aus allen Hosts, die den univentionService=a_distinct_service haben, die Werte von the_attribute auslesen (dies ist ein Multivalue-Feld) und dem Nutzer zur Auswahl anbieten. Das Resultat ist immer, daß die Auswahl leer bleibt. Ich bekomme das gleiche Ergebnis, wenn ich diese Angaben selbst in der UMC als “Syntax” anlege und die betreffenden Felder entsprechend fülle.

Wo ist der Denkfehler? Ich möchte mir gern den Aufwand sparen, unbedingt eine zusätzliche UDM-Klasse zu erfinden, bloß als Umweg um solch ein Dropdown zu bekommen.

viele Grüße
Frank Greif.


#2

Hallo

folgendes sollte funktionieren:

[code]eval “$(ucr shell)”

univention-directory-manager settings/syntax create “$@” --ignore_exists
–position “cn=custom attributes,cn=univention,$ldap_base”
–set name=‘mysyntax’
–set addEmptyValue=‘1’
–set ldapattribute=‘cn’
–set filter=’(&(univentionService=LDAP)(cn=*))’
–set ldapvalue=‘cn’

univention-directory-manager settings/extended_attribute create “$@” --ignore_exists
–position “cn=custom attributes,cn=univention,$ldap_base”
–set name=“myattr”
–set module=users/user
–set tabName=“myattr”
–set shortDescription=“test”
–set longDescription=“test”
–set objectClass=“univentionFreeAttributes”
–set syntax=“mysyntax”
–set mayChange=1
–set ldapMapping=“univentionFreeAttribute1”
–set multivalue=1[/code]
“myattr” am Benuzterobjekt ist dann eine Auswahlbox, die alle cn’s der Objekte mit “univentionService=LDAP” enthält.

Alternative sollte auch die “UDM_Objects” Syntax-Klasse möglich sein (über udm_modules können auch mehrere UDM Objekttypen für die Suche definiert werden). Dafür braucht es dann aber eine eigene Syntax-Klasse.

class MyServers(UDM_Objects): udm_modules = ( 'computers/domaincontroller_master', 'computers/domaincontroller_backup', 'computers/domaincontroller_slave', 'computers/memberserver', ) label = '%(name)s' udm_filter = 'service=LDAP'

Habe ich Ihr Problem richtig verstanden?
Hilft Ihnen das weiter?

Mit freundlichen Grüßen
Felix Botner


#3

Hallo,

danke für die schnelle Antwort. Ja, das Problem ist genau so, allerdings sind noch zwei weitere Details, die es zusätzlich schwierig machen:

[ul]
[li] das zu holende Attribut ist kein Standardattribut (wie im Beispiel ldapvalue=cn) sondern ein “extended attribute”. Bei meinen Versuchen habe ich nicht ein einziges Mal hinbekommen, daß ich ein extended attribute in der Auswahlliste gesehen hätte.[/li]
[li] das zu holende Attribut ist ein Multivalue, und ich habe gesehen, wenn ich ein Multivalue Standardattribut (z.B. objectClass) referenziere, zeigt mit die Auswahlliste immer nur den ersten Wert an.[/li][/ul]

Da werde ich mich wohl doch um eine Syntaxklasse bemühen müssen, wegen der Notwendigkeit, mehrere UDM-Objektklassen zusammen abzufragen. Wenn die beiden zusätzlichen Detailprobleme allerdings ohne solch eine Klasse lösbar sind, würde ich mich über einen Hinweis freuen.

Vielen Dank und viele Grüße
Frank Greif.


#4

Hallo,

ich habe nun versucht, das Problem mit Hilfe von Syntaxklassen anzugehen, leider sind alle drei Basisklassen nicht dazu geeignet, immer fehlt eine Eigenschaft:

[ul]
[li]LDAP_Search und UDM_Objects sind nicht in der Lage, von dem abzufragenden Attribut alle Werte zurückzuliefern, sie liefern pro gefundenes LDAP Objekt immer nur einen Wert (aber wie bereits oben geschrieben: ich will alle Werte eines MULTIVALUE in die Auswahl bekommen)[/li]
[li]UDM_Attribute ist zwar explizit für das Abfragen von MULTIVALUEs gemacht, aber dafür fehlt hier die Möglichkeit, mehrere UDM Objektklassen (Module) anzugeben.[/li][/ul]

Dadurch sieht es so aus, als würde es noch mehr Aufwand bedeuten:
[ul]
[li]Ich mache eine Syntax-Klasse, die von UDM_Attribute abgeleitet ist, und versuche sie so zu überladen, daß sie über mehrere UDM-Module suchen kann,[/li]
[li]oder ich muß wirklich noch einen eigenen UDM-Modul schreiben, der am Ende überhaupt nicht genutzt wird (mit allen seinen Möglichkeiten: eigener Reiter im UDM, Dialoggestaltung, Eingabevalidierung, eigener JavaScript Code und das alles), nur damit ich der UDM_Attribute Syntaxklasse die Möglichkeit habe, die zu befragenden Objekte (Computer unterschiedlicher Rollen) als eine Klasse anzusprechen.[/li][/ul]

Könnte mir jemand einen Hinweis geben, was angesichts dieser Situation die Lösung ist, die den geringsten Aufwand erfordert?

Vielen Dank,
Frank Greif.


#5

Hallo allerseits,

ich habe mich nun dafür entschieden, nach dem Vorbild von ‘computers/computer’ einen eigenen UDM Modul zu schreiben. Ich habe mich dabei versucht, nach wiki.univention.de/index.php?tit … ry_Manager zu richten. Der Modul wird aber schlichtweg nicht geladen, oder genauer gesagt, nach Ablegen des .py Files in /usr/share/pyshared/univention/admin/handlers und Aufruf von stop_udm_cli_server startet der Cli-Server nicht wieder, aber ich finde keinerlei Logeinträge, aus denen hervorgeht warum. Meine Fragen:

[ul]
[li] Was muß ich außer dem Hineinkopieren des .py Files (in ein entsprechendes Unterverzeichnis, selbstverständlich), plus einem leeren init.py, und dem anschließenden Stop des Cli-Servers noch tun, um mein Modul dem UCS bekanntzumachen?[/li]
[li] Ich habe directory/manager/cmd/debug/level = 4 gesetzt und warte in /var/log/univention/directory-manager-cmd.log auf Fehlermeldungen… muß ich evtl. andere Variablen setzen und finde die Fehler in anderen Logfiles?[/li][/ul]

vielen Dank,
Frank Greif.


#6

Hallo Herr Greif,

Schuss ins Blaue: die .py-Files müssen i.d.R. noch gegen die installierte(n) Python-Version(en) gelinked werden. Zum Beispiel gibt es für das Computer-Modul einen Symlink unterhalb von “/usr/lib/pymodules/python2.6/”:

root@ucs:~# ls -la /usr/lib/pymodules/python2.6/univention/admin/handlers/computers/computer.py lrwxrwxrwx 1 root root 67 6. Jun 08:20 /usr/lib/pymodules/python2.6/univention/admin/handlers/computers/computer.py -> /usr/share/pyshared/univention/admin/handlers/computers/computer.py
Wenn man das in ein .deb-Paket packt gibt es da so nette Helferlein wie python-support, die das für einen übernehmen. Wenn man die Datei aber (z.B. zum Testen) von Hand nach “/usr/share/pyshared/univention/…” ablegt, muss man den Symlink ebenfalls von Hand erstellen.

Schönen Gruß,
Michael Grandjean


#7

Hallo,

Danke für den Tip, eigentlich klar wenn es Debhelper gibt, sollten sie auch genutzt werden, das spart einfach Pflegeaufwand. Hab ich sofort eingebaut. (Vielleicht wäre ich auch selbst drauf gekommen, wenn im Wiki auf den aktuellen Beispielmodul verwiesen würde und nicht auf den von 2.4). Das hat aber mein Problem nicht wirklich gelöst.

Das eigentliche Problem lag nur in einem Tippfehler (Groß/Kleinschreibung eines Klassennamen), der mir beim wiederholten Vergleich mit computers/computer.py dann doch noch aufgefallen ist. Damit weiteren Autoren von UDM-Modulen (und mir selbst, für die Zukunft) die Sucharbeit erspart wird, noch eine Frage: Welchen Loglevel muß ich hochdrehen und in welcher Logdatei würde ich den Fehler finden, wenn in einer UDM-Modulquelle ein Syntaxfehler ist?

Danke und viele Grüße
Frank Greif.