Signal für \isys_cmdb_dao_category::save_data

steven_c

Hallo Zusammen,

wir würden gerne über ein Signal feststellen, ob und wann \isys_cmdb_dao_category::save_data aufgerufen wurde.

Leider reichen die vorhandenen Signale,

mod.cmdb.afterObjectTypeSave

mod.cmdb.objectChanged

mod.cmdb.afterCategoryEntrySave,

nicht, da diese in anderen Kontexten emitted werden.

Da es aber third-party addons gibt, wie z.B. das viva2 addon, die über

\isys_cmdb_dao_category::save_data

bestimmte Daten speichern, gibt es derzeit für uns keine saubere Möglichkeit, in diesen Prozess einzugreifen.

Die \isys_cmdb_dao_category::save_data Methode emitted zwar ein Signal (mod.cmdb.extendProperties), aber nur ganz zu Anfang um die Properties zu holen.

Habt ihr sonst noch andere Tipps?

Danke und viele Grüße

Steven

LFischer

Hallo @steven_c24

ich glaube um dir besser helfen zu können müsste ich zuerst verstehen wieso nur die save_data Methode so wichtig ist Was ist dein Use-case? Wenn du nur bei bestimmten Kategorien "reagieren" möchtest kannst du einfach die übergebene "DAO" prüfen (z.B. if ($dao instanceof isys_cmdb_dao_category_g_location) ).

Wenn du nur in einem bestimmten Kontext reagieren möchtest könntest du auch die Context Komponente nutzen - diese beinhaltet Informationen "von wo" der aktuelle Request kommt. Also von der GUI, aus der API oder einem CLI Command. Zusätzlich sind dort auch Infos hinterlegt welche Funktion genutzt wurde, wie z.B. "Import", "Templates", "LDAP", ...

Neben den genannten Signalen fällt mir gerade auch nichts ein - aber vielleicht gibt es ja andere Möglichkeiten

Viele Grüße
Leo

steven_c

@LFischer Hallo Leo, vielen lieben Dank für deine Antwort!

Also der Use-Case ist, dass wir gerne Änderungen eines third-party Addons loggen wollen, wenn sich Änderungen ergeben.
Das Third-Party Addon ist "Viva2".

Hier sehen wir, dass wenn sich Werte in einer Kategorie Liste ändern, dass das Addon die \isys_cmdb_dao_category::save_data Methode aufruft.

Und hier würde wir uns dann mittels Signal gerne rein-hooken, um dann einen Log zu erzeugen.
Im Moment machen wir das "hart" mit einem Patch, also direkte Code-Änderung im Addon.

Da das aber nicht sauber genug ist, da bei einem Addon Update wir die Datei erneut patchen müssten,
haben wir unser eigenes Addon geschrieben, das mittels isys_component_signalcollection einfach auf Signale lauscht.
Das funktioniert auch für Signale an den entsprechenden Stellen, wo sie geworfen werden,
aber es fehlt halt ein Signal, das bei \isys_cmdb_dao_category::save_data emitted wird.

Oder wäre es besser, dass das Addon nach dem call auf \isys_cmdb_dao_category::save_data, selbst ein Signal emitten sollte?

Vielen Dank

LFischer

Hallo @steven_c24

ich habe das VIVA2 Add-on technisch nicht mehr so genau im Kopf - aber wenn es sich um Kategorie DAO-Klassen handelt müsstest du es genau so machen können wie ich das vorgeschlagen habe:

Du hörst dazu auf das mod.cmdb.afterCategoryEntrySave Signal und fragst den ersten Parameter (die DAO Instanz) ab:

isys_application::instance()->container->get('signals')
   ->connect('mod.cmdb.afterCategoryEntrySave', function ($dao) {
      if ($dao instanceof isys_cmdb_dao_category_g_viva2_whatever) {
         // Do the magic...
      }
   });

Das könntest du für jede VIVA2 spezifische Klasse machen, oder alternativ auch so, damit du nicht jede Klasse einzeln abfragen musst (was aber sicherer wäre):

isys_application::instance()->container->get('signals')
   ->connect('mod.cmdb.afterCategoryEntrySave', function ($dao) {
      if (strpos(get_class($dao), 'isys_cmdb_dao_category_g_viva2_') === 0) {
         // Do the magic...
      }
   });

Ich hoffe damit konnte ich dir helfen

Viele Grüße
Leo

steven_c

@LFischer Hallo Leo, vielen Dank für deine Antwort!

Genau, also so wie du es vorgeschlagen hattest, haben wir es auch probiert, aber da das Viva2 Addon eine Routine durchläuft, wo halt kein Signal emitted wird (parent call zu \isys_cmdb_dao_category::save_data), können wir auf Änderungen in einer Liste nicht reagieren.

Ändern wir zB bei Schutzbedarf einen Eintrag aus der Liste, dann wird kein Signal emitted, weil das Addon ja über parent::\isys_cmdb_dao_category::save_data geht.

Ändern wir aber etwas im Reiter "Allgemein" einer Kategorie, dann wird ja generell das Signal (mod.cmdb.afterCategoryEntrySave) emitted und wir können darauf horchen.
Speziell für Änderungen in der Liste (vom Screenshot) aber, geht das nicht.

Wir konnten uns jetzt damit Abhilfe schaffen, dass wir im Viva2 Addon selbst ein Signal emitten, sobald \isys_cmdb_dao_category::save_data an die Caller-Methode des Addons returned und auf dieses Signal reagieren wir dann von unserem eigenen Addon auf mittels ->connect. Das funktioniert auch aber wir möchten am Liebsten ungern third-party Code patchen, aber im Moment bietet sich keine andere Möglichkeit für uns, dort reinzuhooken.

LFischer

Hey @steven_c24

danke für die Erklärung - langsam verstehe ich das Problem Was ich aber noch nicht ganz verstehe ist wieso mod.cmdb.afterCategoryEntrySave nicht aufgerufen wird - das müsste eigentlich ganz regulär passieren wenn eine Kategorie gespeichert wird (also auch wenn save_data genutzt wird)

Ich bin bei VIVA2 leider nicht so tief im Thema und weiß deswegen nicht ob es sich dabei um eine reguläre i-doit Kategorie (wie z.b. "Allgmein" oder "Buchhaltung") handelt. Ich versuche mich mal etwas schlau zu machen

Es könnte sich dabei theoretisch auch um einen Fehler im VIVA2 Add-on handeln, dann müsste das an den Hersteller becon GmbH gemeldet werden. Aber mal schauen ob ich was rausfinden kann.

Viele Grüße
Leo

steven_c

@LFischer Hallo Leo, vielen Dank für deine Antwort :)!

Genau du hast recht, in der Regel sollte dieses Signal emitted werden, aber wird es leider für diese custom Kategorie "Schutzbedarf" des Viva2 Addons nicht.

Wir konnten uns jetzt Abhilfe verschaffen, in dem wir über einen Mini-Patch ein Signal emitten, nachdem die Schutzbedarfswerte vom Addon gespeichert wurden.

In unserem eigenen Addon connecten wir dann auf das Signal und verarbeiten das für die Zwecke, für die wir die Daten benötigen.

Wir werden den Fehler an den Addon Hersteller melden, damit er ein Event zur Verfügung stellt, oder halt von Haus aus ein Logging anbietet.

Im Moment passt unsere eigene Lösung für uns.

Vielen Dank für deinen Support und einen schönen Tag

Steven