@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

@LFischer Lieber Leo,

vielen Dank heute nochmal für die Dev-Sprechstunde und deinen super Support!
Mit der Anleitung aus der Sprechstunde und dem Beitrag hier hat es funktioniert !

Wir können jetzt von unserem Addon aus ein neues Kategorie Attribut hinzufügen.

Ich finde die Lösung so gar sauber ^^ (klar ist das mit dem Namespace so ne Sache, aber dafür ist der Autoloader ja da, dass man beliebig Klassen reinladen kann)

Vielen Dank für deine Unterstützung, du hast uns sehr geholfen!

Viele Grüße

Steven

@tschreinercomp Das ist relativ einfach lösbar über eine Erweiterung der JSON-RPC API in i-doit.
Das haben wir so auch gelöst.

Hier hast du zwei Optionen:

• JSON-RPC Api erweitern https://kb.i-doit.com/de/software-entwicklung/add-ons-entwickeln/api-erweitern.html
• Eigener Controller über Symfony Routing component

Beachte, dass letztere Option etwas sperriger ist, weil für den Aufruf eine gültige Session existieren muss.
Erste Option, also via JSON-RPC, ist angenehmer weil du dort username+password+api-key oder halt session dem Request mitgeben kannst.

Referenz:

https://kb.i-doit.com/de/software-entwicklung/add-ons-entwickeln/api-erweitern.html

@LFischer Hallo Leo, vielen Dank für deine Unterstützung

Wir haben die API auf Basis der Anleitung erweitert.

Viele Grüße

Steven

Hallo Zusammen,

ich habe einen neuen Controller über die neue Symfony Routing Möglichkeit hinzugefügt.

Allerdings ist mir aufgefallen, dass die definierten Routes nur aufrufbar sind, wenn man auch in i-doit eingeloggt ist.
Ist man ausgeloggt, dann wird man zum Login Screen weitergeleitet.

Ist dieses Verhalten expected? Wenn Ja, gibt es eine Möglichkeit über Basic Auth o.Ä. trotzdem auf die Route zuzugreifen?
Wenn Nein, ist ein eigener Controller dann die falsche Wahl und ich sollte eher die API erweitern, um dann mittels API Key auf eine eigene API route zuzugreifen?

Und als abschließende Frage: Kann ich trotzdem eine Route mit Controller definieren die kein Auth braucht? Use-Case wäre hier eine Webhook z.B. wo ich kein RPC verwenden kann.

Vielen Dank,

Grüße Steven

@LFischer Lieber Leo,

vielen Dank heute nochmal für die Dev-Sprechstunde und deinen super Support!
Mit der Anleitung aus der Sprechstunde und dem Beitrag hier hat es funktioniert !

Wir können jetzt von unserem Addon aus ein neues Kategorie Attribut hinzufügen.

Ich finde die Lösung so gar sauber ^^ (klar ist das mit dem Namespace so ne Sache, aber dafür ist der Autoloader ja da, dass man beliebig Klassen reinladen kann)

Vielen Dank für deine Unterstützung, du hast uns sehr geholfen!

Viele Grüße

Steven

@LFischer Hallo Leo,

vielen Dank für deine Hilfe.
Ich habe jetzt den Code von dir implementiert und auch den Cache geleert und Kategorie-Attributes neu indeziert, aber leider taucht in der Übersicht kein virtuelles Attribut auf, auch nicht bei der Attribute Auswahl.

Muss ich noch etwas beachten?

Viele Grüße

Steven

Guten Tag,

wir möchten gerne ein neues Property (Attribute) hinzufügen zu einer Kategegorie.
Das geht auch, allerdings kann man für die Datenquelle nur SQL verwenden, auf den ersten Blick:

 protected function   properties()
    {
        return [
            'some_attribute'         => array_replace_recursive(isys_cmdb_dao_category_pattern::text(), [
                C__PROPERTY__INFO     => [
                    C__PROPERTY__INFO__TITLE       => 'Something',
                    C__PROPERTY__INFO__DESCRIPTION => 'Something'
                ],
                C__PROPERTY__DATA     => [
                    C__PROPERTY__DATA__SOURCE_TABLE => 'xxxx',
                    C__PROPERTY__DATA__SELECT     => idoit\Module\Report\SqlQuery\Structure\SelectSubSelect::factory('field',
                        'field'),
                ],
                C__PROPERTY__UI       => [
                    C__PROPERTY__UI__ID     => 'ui_id',
                    C__PROPERTY__UI__PARAMS => [],
                ],
                C__PROPERTY__PROVIDES => [
                    C__PROPERTY__PROVIDES__LIST => true,
                ]
            ]),

Gibt es eine Möglichkeit die Datenquelle dahingehend zu ändern, dass man zB den Inhalt für C__PROPERTY__DATA aus ner PHP Funktion oder so zu holen?

Weshalb wir das fragen ist, da wir gerne in der Listenansicht für einen ObjektTyp gerne eine neue Column hinzufügen wollen aber mit Daten die nicht aus der Datenbank kommen:

Oder ist unser Ansatz falsch und wir sollten das lieber mit nem Report lösen, der Daten aus einer custom PHP Funktion (o.Ä) zusammenstellt?

@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

@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 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

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