Hallo @Pippo

ein valider JSON RPC Request hat ein paar Voraussetzungen, unter anderem:

• Es muss sich um einen POST Request handeln
• Der "Content-Type" muss "application/json" lauten
• Bei den übergebenen Daten muss es sich um valides JSON handeln (das muss im Request Body stehen)

In unserem PHP API Client (siehe hier: https://packagist.org/packages/idoit/apiclient#dev-main ) kannst du dir die Header Daten ausgeben lassen. Diese lauten bei mir z.B.

POST /idoit/src/jsonrpc.php HTTP/1.1
Host: localhost
User-Agent: idoit/apiclient 0.11-dev
Accept: */*
Accept-Encoding: application/json
Content-Type: application/json
X-RPC-Auth-Username: admin
X-RPC-Auth-Password: admin
Content-Length: 90

(X-RPC-Auth-* Header sind nur notwendig, wenn man sich mit einem User anmelden möchte)

Viele Grüße
Leo

Hallo zusammen,

ein kurzer Hinweis aus dem "Maschinenraum" Wenn ihr eigene CSS Dateien verwenden möchtet könnt ihr diese für gewöhnlich einfach nur in den Ordner src/themes/default/css/ legen - i-doit wird diese dann sammeln und cachen (wobei die style.css immer zuerst und mit Priorität geladen wird).

Wir lesen uns dieses Thema natürlich durch und möchten in den kommenden Versionen darauf eingehen. Das Redesign ist nicht mit i-doit 1.19 "abgeschlossen".

Aber zurück zum eigentlichen Thema:
Alternativ wäre es auch möglich die eigenen Stylesheets mittels Add-on bereitzustellen, dafür braucht ihr eigentlich nur eine PHP Datei mit folgendem Inhalt und eine entsprechende CSS Datei:

<?php

// file "src/classes/modules/custom-style/init.php".
isys_application::instance()->container->get('signals')->connect('mod.css.attachStylesheet', function () {
    // file "src/classes/modules/custom-style/style.css".
    return __DIR__ . '/style.css';
});

Das ist eine stark vereinfachte Form eines Add-ons, die sich auch nicht mittels Admin-Center installieren, aktivieren, deaktivieren oder deinstallieren lässt. Wenn man es "richtig" machen möchte kann man sich den entsprechenden KB Artikel durchlesen

Der Vorteil dies mittels Add-on zu lösen ist in erster Linie, das Add-ons (bzw. deren Code) nicht von i-doit Updates angepasst werden - somit könnte diese Lösung über mehrere Versionen erhalten bleiben. Und es hilft natürlich auch solche Anpassungen an eine "dafür vorgesehene" Stelle zu packen anstatt direkt Änderungen im Kern Quellcode vorzunehmen... Davon möchte ich dringend abraten

Viele Grüße
Leo

Hey @Pippo

ich habe noch mal im Code nachgesehen - die Meldung "Provided request is not a valid json rpc" wird nur in zwei Situationen ausgegeben:

• Wenn der übergebene Request kein "valides" JSON beinhaltet bzw. nicht aus dem Request-Body heraus dekodiert werden konnte (siehe JSON lint)
• Wenn das dekodierte JSON kein Array ist

Ich denke den zweiten Fall können wir ausschließen, denn dein gegebener Payload ist sowohl valides JSON als auch ein Array. Es kann also eigentlich nur noch der Fall sein, das dieses nicht als Request Body übergeben wird

Hast du mal im i-doit den API Log auf "debug" geschaltet und nach dem Request geschaut was im {i-doit}/log Verzeichnis geschrieben wird?

Viele Grüße
Leo

Hallo @lord_helmchen

dieser Tippfehler wird in i-doit 33 korrigiert, aktuell planen wir diese Version in KW 41 zu veröffentlichen

Du kannst alternativ natürlich die Übersetzung selbst korrigieren über "Verwaltung > Datenansicht > Sprachprofile"

Da kannst du die Sprachkonstante LC__CONTACT__TREE__MEMBERS mit der korrigierten Übersetzung Personengruppen Mitglieder ersetzen.

VG Leo

Hello @finaria

for this you can export a object from i-doit and use the resulting XML

Best regards
Leo

Hallo zusammen,

@MartinV hatte es richtig erkannt - um die zugewiesenen Standorte eines Objekts zu erhalten braucht man die Methode cmdb.location_tree.read hier kann man mittels Parameter id entscheiden wessen "children" man sehen möchte.

Also z.B.

{
    "version": "2.0",
    "method": "cmdb.location_tree.read",
    "params": {
        "id": 1234,
        "apikey": "<key>"
    },
    "id": 1
}

Im Ergebnis erhält man dann ein Array mit allen direkt zugewiesenen Objekten, die Daten schauen dabei so aus (pro Objekt):

[
    {
        "id": 302,
        "title": "0.01 Office",
        "sysid": "ROOM_00000302",
        "type": 26,
        "type_title": "Room",
        "status": 2,
        "cmdb_status": 6,
        "cmdb_status_title": "in operation"
    },
    {
        "id": 1073,
        "title": "pool.ntp.org",
        "sysid": "CLOUD_0001073",
        "type": 39,
        "type_title": "Host",
        "status": 2,
        "cmdb_status": 6,
        "cmdb_status_title": "in operation"
    },

    ...
]

Viele Grüße
Leo

Hallo @stephan ,

aktuell ist das noch nicht möglich, wir haben dieses Feature aber im Auge und für dieses Jahr geplant

Viele Grüße
Leo

Hey @MarcelP

also eine dedizierte Einstellung gibt es dafür nicht - du könntest aber probieren die folgenden zwei "Expertensetting" hinzuzufügen:

Die "keys" müssen gui.tree.spacing und gui.category.padding lauten und deren Werte ein einfaches s. Achte darauf das es eine "Tenant Setting" sein sollte.

Das müsste dazu führen das User, die noch keine persönliche Einstellung vorgenommen haben, die "Mandanten"-Einstellung erben

Lass mich wissen ob es geklappt hat!

Viele Grüße
Leo

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

Hey @apfel-jan

welche PHP Version hast du im Einsatz? Ich kann an der entsprechenden Stelle keinen "Fehler" finden, vor allem da es ja bei dir auf dem System über die Web GUI läuft

Ist es möglich das Apache und das CLI verschiedene PHP Versionen nutzen?

VG Leo

Hey @jan.weinhold

das Problem ist, dass der Sync probiert einen duplizierten Benutzer anzulegen. User müssen in i-doit einen einzigartigen (= unique) Usernamen haben.
In deinem i-doit existiert scheinbar bereits ein User mit Username imi.
In i-doit 35 wird diese Meldung etwas Benutzerfreundlicher sein und das Problem erklären.

Viele Grüße
Leo

Hallo @NdsMetall

hast du ggf. einen Service filter oder ein Profil ausgewählt das "zu viel" Daten zurückliefert? Das würde die Ladezeiten erklären - aber "irgendwann" sollte der Request abgeschlossen werden und du solltest die Einstellungen korrigieren können.

ALTERNATIV kannst du über die folgende Query alle CMDB-Explorer Widgets ausfindig machen:

SELECT * FROM isys_widgets_config
INNER JOIN isys_widgets ON isys_widgets__id = isys_widgets_config__isys_widgets__id
WHERE isys_widgets__const = 'C__WIDGET__CMDB_EXPLORER';

Optional kannst du auch noch diese Bedingung hinzufügen um die Widgets eines Nutzers darzustellen (hier kannst du deine User Objekt-ID eintragen)

[...]
AND isys_widgets_config__isys_obj__id = 123;

Wenn du die schuldige Widget Konfiguration gefunden hast (siehe isys_widgets_config__id) kannst du die betroffene Zeile direkt über die Datenbank löschen:

DELETE FROM isys_widgets_config WHERE isys_widgets_config__id = 123;

Bitte erstelle vorher eine Sicherung deiner Datenbank

Viele Grüße
Leo

Hallo @StefanP74

ich habe gerade gesehen das die angepeilte Code-Änderung in i-doit 35 veröffentlicht werden soll Dadurch dürften sämtliche indexierten und nicht-virtuellen Felder sortiert werden.

Gleiches gilt auch für Reports.

Hallo @StefanP74

ich habe gerade gesehen das die angepeilte Code-Änderung in i-doit 35 veröffentlicht werden soll Dadurch dürften sämtliche indexierten und nicht-virtuellen Felder sortiert werden.

Gleiches gilt auch für Objektlisten.

Hallo @Fragesteller

ich fürchte den Upload von PDF werden wir nicht so einfach hinbekommen, da das Format viel mehr als eine einfache "Grafik" ist. SVG sollte aber machbar sein - vor allem weil der Raumplan allgemain mit SVG Grafiken arbeitet.

Leider ist aktuell kein Release für den Floorplan vorgesehen... Das heißt ich kann dir auch leider kein Datum o.Ä. sagen wann ein solches Feature bereit wäre.

Bis dahin müsstest du leider mit gerasterten Bilddaten (ich würde PNG vorschlagen) arbeiten. Du könntest ja die Vektorgrafiken in einer ausreichenden Qualität als PNG exportieren um diese zu nutzen?

Viele Grüße
Leo

Hallo @aziller

ich glaube das Problem hierbei ist, dass das "Objekt" als solches nicht aktualisiert wird. Das einzige, was aktualisiert wird sind dessen Kategorie-Daten (z.B. die "Allgemein" Kategorie).

Die Option "Speichern" für den Bezug "Objekt" tut tatsächlich nichts und müsste eigentlich entfernt werden... Das habe ich bereits aufgenommen.

Probier es besser mit dem Bezug "Kategorie"

Viele Grüße
Leo

Hey @StefanP74,

könntest du ggf. ein paar mehr Infos zu deiner benutzerdefinierten Kategorie posten? Sollten die Attribut-Schlüssel und Inhalte stimmen könnte ich mir noch vorstellen das es ggf. doppelt in einem Array stehen muss, also anstatt:

[...]
'categories' => [
    'C__CATG__CUSTOM_FIELDS_XYZ' => [
        'attr' => 'wert',
        'attr2' => 'wert2',
        ...
    ]
],

Müsste es so aussehen:

[...]
'categories' => [
    'C__CATG__CUSTOM_FIELDS_XYZ' => [
        [
            'attr' => 'wert',
            'attr2' => 'wert2',
            ...
        ]
    ]
],

Der Grund dafür (wenn ich mich richtig erinnere) ist das wir keinen Unterschied zwischen Single- und Multivalue Kategorien machen, wenn diese beim erstellen des Objekts erzeugt werden.
Deswegen müssen auch Singlevalue Kategorien noch mal in ein Array geschachtelt werden

Ich hoffe damit klappt es!

Viele Grüße
Leo

Hey @CookieMonster

wir haben einen Hotfix vorbereitet der das Problem zu lösen scheint. Sollte dieser von unserer internen QS abgesegnet werden landet er ggf. auch in unserer KB https://kb.i-doit.com/de/administration/hotfixes/index.html - alternativ wird der Fix mit i-doit 35 regulär veröffentlicht.

Bitte beachte das dieser Hotfix aktuell ungetestet ist. Ein einspielen erfolgt daher auf eigene Gefahr - ich würde definitiv empfehlen vorher einen Snapshot oder eine Sicherung vorzunehmen.

i-doit_34_hotfix_ID-11788_bbefcb3.zip

Viele Grüße
Leo

Hallo @CookieMonster

der Bug ist bei uns bereits eingetrudelt - es betrifft leider auch Tabellen in der Verwaltung

Die Ursache dafür ist, das wir mit i-doit 34 die Pager für Objekt- und Kategorielisten angepasst haben um effizienter zu arbeiten, bei einigen Usern kam es zuvor zu Performance Problemen. Leider haben wir damit einen Folgefehler verursacht an dem wir bereits arbeiten.

Ein Workaround ist nach einem einzelnen Zeichen (z.B. ein Leerzeichen) zu suchen, in diesem Kontext funktioniert der Pager wieder.

Ein anderer Workaround ist die "Einträge pro Seite" Einstellung nach oben zu setzen:

Wir sind zuversichtlich den Fehler in der kommenden i-doit 35 zu lösen

Viele Grüße
Leo

Kurzes Update: Gelöst in Add-on Version 1.5

Die hier beschriebenen Probleme wurden in der Zwischenzeit in Version 1.5 des Add-ons gelöst. Dieses wurde am 26.Februar veröffentlicht

Viele Grüße
Leo