@Instructor Das Problem scheint weiterhin zu bestehen. Ich habe ein Template angelegt für eine Steckdosenleiste, 1 Eingang -> 7 Ausgänge, alle dem gleichen Eingang zugeordnet. Erstelle ich daraus Objekte, ist nur noch 1 Eingang einem Ausgang zugeordnet.

Servus @LFischer Version 2.2 Danke für die Aufklärung, das war mir neu. Anhand des Umstandes, dass ich keinen Login durchführe sondern nur via API-Key den Connect herstelle, ziehen hierfür die Expertensettings vom Admin-Center. Ich habe nun api.log-level in den Expertensettings im Admin-Center auf 400 gesetzt (war auf 100 Debug) ... und tataaaa, tut. Danke. LG Stefan

Ich habe es mit Hilfe von https://kb.i-doit.com/de/software-entwicklung/add-ons-entwickeln/kategorien-programmieren.html und etwas Wissen über den Aufbau von i-doit selber rausgefunden. Der obigen Artikel fehlen aus meiner Sicht insbesondere die Pfade bzw. Datei-Namen, um das im System besser nachvollziehen zu können. Daher hier kurz mein Vorgehen: Passende Data-Access-Objekt (DA) Klasse finden. Diese Dateien liegen aktuell hier (ich hatte einfach nach dao gesucht, da dass ja recht eindeutig ist) /var/www/html/i-doit/src/classes/modules/cmdb/dao/category/ Hier am besten nach der Sprachkonstante der Kategorie oder eines (eindeutigen) Attributs suchen. In meinem Fall grep -r 'LC__CMDB__CATG__GLOBAL_TAG' *" Das liefert isys_cmdb_dao_category_g_global.class.php Wenn man sich ein wenig mit der Datenbank bzw. den Konstanten auskennt, hätte man die passende Datei aber auch so gefunden. Zur Dao gibt es (eigentlich) immer eine passende UI Interface Klasse. Diese liegen aktuell hier: /var/www/html/i-doit/src/classes/modules/cmdb/ui/ In meinem Fall ist das dann die /var/www/html/i-doit/src/classes/modules/cmdb/ui/global/isys_cmdb_ui_category_g_global.class.php (Also anderer Pfad und ui statt dao) Hier werden die "Rules" (gesammelte Daten aus DAO + ggf. verarbeitete Daten aus dem UI) an das Smarty-Template übergeben: smarty_tom_add_rules('tom.content.bottom.content', $l_rules); Die Templates sind dann aktuell hier zu finden (das ist das, was ich eigentlich wollte): Statt Punkt ein Verzeichnis-Trenner und tom wird zu templates: /var/www/html/i-doit/src/themes/default/smarty/templates/content/bottom/content/ In meinem Fall benötige ich die catg__global.tpl (angelehnt an die Konstante für die Kategorie) welche HTML Code beinhaltet/erzeugt und dass man relativ leicht anpassen kann, da der content/bottom/content hauptsächlich aus einer html Tabelle besteht. Grüße

Hi, cool, stimmt. Funktioniert wieder! Vielen Dank für den Hinweis. LG, Sebastian

vielleicht hilft euch nun dieses Add-on weiter: https://www.i-doit.com/events/vergangenes-event-das-neue-i-doit-add-on-jira-asset-import

@Niklas-K Unter der Verwaltung -> Vordefinierte Inhalte -> CMDB Status existieren allerdings diese Einträge "in Betrieb" bzw. "außer Betrieb" nicht, jedoch kann ich sie für alle Objekte auswählen. Das ist schonmal ziemlich komisch? Diese CMDB Status auszublenden ist vielleicht nicht toll aber das wurde so gemacht, damit die von uns benötigten CMDB Status nicht editiert werden können. Ohne den Request zu kennen ist es ziemlich schwer zu sagen was da falsch ist. Ansonsten schau mal hier: https://kb.i-doit.com/de/i-doit-add-ons/api/methoden/v1/cmdb.category.html#cmdbcategoryupdate Und prüf mal diesen Request: { "method": "cmdb.category.save", "params": { "object": 1122600468, "category": "C__CATG__GLOBAL", "data": { "cmdb_status": 10 }, "apikey": "bierbank" }, "id": 1, "version": "2.0" } Über cmdb.status.read kannst du dir die IDs anzeigen lassen: { "version": "2.0", "method": "cmdb.status.read", "params": { "apikey": "bierbank", "language": "en" }, "id": 1 }

@Michael-Huhn Danke für die Info

@leno2206 das Problem bei Dateien ist, die müssen als Base64 kodiert sein . Datei Objekt erstellen und eine Datei hochladen: { "id": 1, "version": "2.0", "method": "cmdb.object.create", "params": { "type": "C__OBJTYPE__FILE", "title": "UserImage", "categories": { "C__CATS__FILE_VERSIONS": [ { "file_physical": "UserImage.png", "file_content": "BASE64=", "file_title": "UserImage.png" } ] }, "apikey": "key", "language": "en" } } Dann hab ich hier noch ein Beispiel für das Zuweisen einer Datei zu einem Objekt: { "id": 1, "version": "2.0", "method": "cmdb.category.save", "params": { "object": 1123375323, "category": "C__CATG__FILE", "data": { "file": 1123375614, "link": null, "description": null }, "apikey": "key", "language": "en" } } Ps. wenn ich versuche die Datei hochzuladen und direkt zuzuweisen, bekomme ich einen 500er. AH01071: Got error 'PHP message: PHP Fatal error: Uncaught TypeError: isys_application::getUploadFilePath(): Argument #1 ($fileName) must be of type string, null given, Dazu erstelle ich einen Bug Report { "id": 1, "version": "2.0", "method": "cmdb.object.create", "params": { "type": "C__OBJTYPE__FILE", "title": "UserImage", "categories": { "C__CATS__FILE_VERSIONS": [ { "file_physical": "UserImage.png", "file_content": "BASE64=", "file_title": "UserImage.png" } ], "C__CATS__FILE_OBJECTS": [ { "assigned_objects": 9 } ] }, "apikey": "key", "language": "en" } }

@Michael-Huhn Danke erstmal für die zwei Beispiele. Beide setzen aber voraus, dass der "contact" schon existiert - das ist bei mir nicht der Fall. Da wäre halt die Idee beides in einer Abfrage zu vereinen, ich kann mir aber gut vorstellen, dass das so nicht vorgesehen ist.

@plox also in der Demo seh ich dazu nichts, daher wohl nein. [image: 1723718747078-a68625b5-6574-4b21-be32-aafa3337f42b-image.png]

Alles klar. Danke für die Erklärung und den Workaround

Hallo @uhaase der API Client unterstützt noch keine der v2 Endpunkte - wobei das bisher auch gar nicht nötig ist. Die v2 Endpunkte wurden in erster Linie ins leben gerufen um die Parameter zu vereinheitlichen (z.B. werden objID, catgID oder catsID mit object und category usw. getauscht) - der API Client übernimmt dies aber schon im Vergleich zur "rohen" Kommunikation mit der API. Ich muss auch gestehen das die v2 Endpunkte nur sehr langsam Fortschritte machen und viele der object und category Endpunkte im v2 Kontext noch nicht existieren, da wir damit auf eine i-doit interne API aufbauen wollen, die noch nicht fertig ist. Ich denke lediglich die cmdb.external.pull.v2 und cmdb.external.push.v2 müssten wir hier nachziehen, da es sich dabei um neue Endpunkte handelt die vorher nicht existiert haben. Oder wolltest du auf etwas anderes hinaus ? Viele Grüße Leo

Moin Erstelle dir doch einfach einen Bericht in i-doit über den Report Manager und lese den aus. { "version": "2.0", "method": "cmdb.reports.read", "params": { "language": "en", "apikey": "meinkey", "id": "112" <---- report id }, "id": 1 } Report konfigurieren [image: 1720173725514-fc6b4012-577c-4251-ad23-9f5abb7fb138-grafik.png] Ergebnis: { "id": 1, "jsonrpc": "2.0", "result": [ { "Title": "srv-erp", "Contact": "Pattrick Bluhm", "Primary": "Yes" }, { "Title": "srv-dc1", "Contact": "Heike Müller", "Primary": "Yes" } ] }

@LFischer Super Sache, genauere Fehlermeldungen sind natürlich immer gerne gesehen! Danke nochmals fürs Helfen. Grüsse, Pippo

@Franky779 ich denke dir sollten die Infos aus der Knowledge Base helfen. -> https://kb.i-doit.com/en/i-doit-pro-add-ons/api/methods/index.html

OK, mit SEHR viel rumprobieren komme ich dorthin wo ich will. Wer das noch braucht. Hier meine Abfrage. params = { "id": 12345, "categories": ["C__CATS__PERSON"], "filter": { "type": 53, "ids":[12345] }, } contactDetails = objIdoit.getJsonData(method='cmdb.objects.read', params=params) id = Contact ID in idoit categories C__CATS__PERSON = die erweiterten Infos zum Kontakt inkl. Custom Fields type 53 = Personen

@LFischer Danke. Der Benutzer hat auf jeden Fall "Administrator und primary" Die Abfrage mit C__RELATION_TYPE__ADMIN liefert kein Ergebnis. C__RELATION_TYPE__USER mir brav den Contact. [image: 1708606513164-59f6a2cc-1cf3-499f-91cd-1903c1be5560-image.png]

@MartinV danke für die Antwort. Jetzt funktionierts ich hab übersehen das ich einen Array mitgeben muss.