Univention Bugzilla – Bug 21083
post_hooks werden nicht ausgeführt, wenn create_ou implizit aufgerufen wird
Last modified: 2012-06-11 06:29:33 CEST
Die post_hooks werden nicht bei impliziten Aufrufen von create_ou ausgeführt ( siehe bspw. import_networks).
*** Bug 21078 has been marked as a duplicate of this bug. ***
Es sollte kurz geprüft werden, ob dieser Bug im Produkt auch auftritt. Es ist möglich, dass es sich hierbei um ein kundenspezifisches Problem handelt.
In verify_school_ou() wird geschaut, ob die OU schon in verified_ous definiert ist. Falls ja springt er raus, falls nicht versucht er die OU anzulegen und speichert die OU dann in verified_ous. Das klappt natürlich beim ersten Auftreten einer OU nicht, da diese noch nicht geprüft wurde und nicht in verified_ous vorhanden ist. Daher wird in diesem Fall der ou_pre_hook immer ausgeführt. Später in verify_school_ou() wird dann verify_container() auf die OU aufgerufen. Diese Funktion gibt False zurück wenn der Container bereits existiert. Der ou_pre_hook wird nur aufgerufen, wenn verify_container() auf die OU nicht False ist. Bei mehrmaligem Import von z.B. Netzwerken wurde also nur der ou_pre_hook (beim erstmaligem Auftreten einer OU im Import File) und nicht der ou_post_hook (da der Container ja bereits existiert) aufgerufen. Beim erstmaligem Import (die OU gibt es im LDAP noch nicht), wurden die Hooks immer korrekt aufgerufen. Änderung: Vor dem ou_pre_hook wird nachgesehen, ob diese OU Objekt existiert. Nur wenn es nicht existiert wird der ou_pre_hook aufgerufen.
*** Bug 20201 has been marked as a duplicate of this bug. ***
Comment aus Bug 20201: > Ggf. ist es sinnvoll, den postcreate-Hook nachträglich auch noch mal > aufzurufen, um z.B. das Vorhandensein des Marktplatzes überprüfen zu können. Da der Pre-Hook für OUs jetzt nicht mehr aufgerufen wird, wenn die OU bereits existiert, kann mit den OU-Hooks z.B. kein zweiter Marktplatz für bestehende OUs nachgepflegt werden. Wir sollten diese Änderung daher wieder zurücknehmen und die pre-OU-Hooks vor jeder aktiven Prüfung der OU ausführen. Das Caching soll davon unbeeinflusst bleiben. D.h. wenn die OU in einem Programmdurchlaub bereits geprüft wurde, wird das pre-OU-Hookskript nicht nocheinmal aufgerufen. > Die post_hooks werden nicht bei impliziten Aufrufen von create_ou ausgeführt ( > siehe bspw. import_networks). Wann werden die Posthooks für OUs ausgeführt? Nur, wenn eine OU angelegt wurde? Oder auch, wenn z.B. ein fehlender Container nachgepflegt wurde? Wird das Posthookskript auch aufgerufen, wenn z.B. über import_networks eine unbekannte/neue OU verwendet wird und automatisch über das verify_ou() angelegt wird? Beim impliziten Aufruf sollte sich verify_ou() genauso verhalten, wie bei einem expliziten Aufruf.
So soll das Verhalten sein: | PRE | POST ------------------------+-----+---- create_ou OU fehlt | Ja | Ja create_ou OU existiert | Ja | Nein verify_ou OU fehlt | Ja | Ja verify_ou OU exisitert | Ja | Nein ("create_ou" meint das explizite Ausführen des create_ou-Skripts, "verify_ou" meint das implizite Erstellen durch andere Import-Skripte)
(In reply to comment #6) > So soll das Verhalten sein: > | PRE | POST > ------------------------+-----+---- > create_ou OU fehlt | Ja | Ja > create_ou OU existiert | Ja | Nein > verify_ou OU fehlt | Ja | Ja > verify_ou OU exisitert | Ja | Nein > > ("create_ou" meint das explizite Ausführen des create_ou-Skripts, > "verify_ou" meint das implizite Erstellen durch andere Import-Skripte) OK, pre ou hook wird nun immer ausgeführt (bis auf das Cache in verify_ou)
(In reply to comment #7) > (In reply to comment #6) > > So soll das Verhalten sein: > > | PRE | POST > > ------------------------+-----+---- > > create_ou OU fehlt | Ja | Ja > > create_ou OU existiert | Ja | Nein > > verify_ou OU fehlt | Ja | Ja > > verify_ou OU exisitert | Ja | Nein > > > > ("create_ou" meint das explizite Ausführen des create_ou-Skripts, > > "verify_ou" meint das implizite Erstellen durch andere Import-Skripte) > > OK, pre ou hook wird nun immer ausgeführt (bis auf das Cache in verify_ou) OK Changelog OK
UCS@school 3.0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS@school erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"