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

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

Hello @finaria

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

Best regards
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

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

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

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

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

Hallo @AndiKausG

das klingt ein wenig nach einem bekannten Problem, für das es bereits einen Hotfix in unserer Knowledge Base gibt, siehe hier: https://kb.i-doit.com/en/system-administration/hotfixes/index.html#add-support-for-new-jdisc-graphql-schema-id-11256

Alternativ könntest du überprüfen ob der eingetragene Host und Port korrekt sind. Wir hatten letztens den Fall das sich ein Leerzeichen im Hostnamen eingeschlichen hat - das hat zu einem ähnlichen Problem geführt

Viele Grüße
Leo

Hey @TheBob1

ja, es gibt eine Option um Templates in den normalen Objekttyp Listen darzustellen. Siehe dazu
Verwaltung > Einstellungen für {mandant} > Templates > Template Filter in den Objektlisten anzeigen

Das sieht dann so aus:

Viele Grüße
Leo

Hallo @Umezi

grundlegend gibt es bereits einen "Kabel" Objekttyp, bei dem allerdings ein Objkt ein physikalisches Kabel repräsentiert.

Du könntest aber einen eigenen Objekttypen erzeugen und hier eine Art "Sammelobjekt" pro Typ erzeugen. Ich würde hier mit einer benutzerdefinierten Kategorie arbeiten

Also - Neuer Objekttyp z.B. "Kabel (zusammenfassung)" mit den üblichen Standardkategorien + eine eigene benutzerdefinierte Kategorie die dann z.B. die Anzahl an Kabel und den Typen beinhaltet.

Diese zwei Attribute kannst du anschließend in der Objektliste darstellen lassen Das ist jetzt aber natürlich nur eine einzelne Idee - es gibt sicherlich noch genügend andere Möglichkeiten deinen Use-Case abzubilden.

WENN man es mit normalen Objekten und (benutzerdefinierten) Kategorien macht kann man diese Daten mittels Report auswerten und über die API auslesen und schreiben

Hilft das weiter?

Viele Grüße
Leo

Hey @StefanP74

freut mich das ich helfen konnte - ich habe tatsächlich schon öfters erlebt das der Cache zu solchem Verhalten führen kann. Das kann passieren, wenn Commands oder sonstige "i-doit bezogenen" Cronjobs als root ausgeführt werden.

Das kann u.a. dazu führen das Cache Dateien vom root User erstellt werden und der apache User kann dann nicht mehr darauf zugreifen oder verändern

Viele Grüße
Leo

Hey @StefanP74

könntest du mir hier einen Screenshot hinterlegen oder genau erklären an welcher Stelle das passiert? Hier z.B. konnte ich keinen Code finden der die Links deaktiviert

Auch auf der Detailseite innerhalb des Add-ons kann ich im Code nichts finden das diese Buttons deaktiviert

Ich glaube in der virtuellen Objekt Kategorie ist es möglich das die Buttons deaktiviert werden, das liegt am Recht "Vorlagen in Kategorien". Da muss der User "Ansehen" dürfen:

Soweit ich das sehe wurde das aber bereits in Dokumente Add-on in Version 1.7 eingeführt.

Konnte ich dir damit weiterhelfen?

Viele Grüße
Leo

Hallo @TheBob1

ich bin mir gerade nicht sicher warum es sich bei dem Dialog nicht um ein Dialog+ handelt

Du kannst aber über den "Dialog-Admin" in der Verwaltung neue Einträge hinzufügen, siehe:

Und anschließend beim klick auf "Neu":

Ich hoffe das hilft weiter. Ich werde mal schauen ob wir einfach ein Dialog+ aus dem Feld machen

Viele Grüße
Leo

update

OK ich sehe es gibt in der "Gerät" Kategorie ein wenig spezielle Logik für bestimmte Typen. Soll heißen, es werden dann ein paar Felder ein- und ausgeblendet.

Das schaue ich mir auch mal an. Vielleicht bekommen wir das in den kommenden i-doit Versionen gelöst

Hallo @StefanP74

das Verhalten sollte sich nicht durch das i-doit Update verändert haben Wurde denn auch das Dokumente Add-on aktualisiert? Da müsste ich kurz die Version kennen damit ich nachschauen kann.

In der neusten Version (1.9) vom 10.Okt sehe ich z.B. keine Änderungen bzgl. der Rechteprüfung im Add-on

Viele Grüße
Leo

Okay, das ging etwas schneller als erwartet

Könntest du bitte die Datei {i-doit}/src/classes/modules/cmdb/dao/isys_cmdb_dao_distributor.class.php um Zeile 200 herum prüfen und den markierten Text an der richtigen Stelle ergänzen?

Also in der if (...) Bedingung den Code $p_disttype == C__CMDB__CATEGORY__TYPE_CUSTOM && hinzufügen? Siehe:

Das müsste dein Problem lösen Leider wird es diese Änderung nicht mehr in die Version 33 schaffen sondern erst in die 34. Solltest du also updaten musst du die Änderung erneut einfügen.

Viele Grüße
Leo

Hallo @boni127

vielen Dank für deinen Beitrag und die Bugmeldung - dieser Fehler tritt bei dir auf, weil die community Version / i-doit OPEN keine benutzerdefinierte Kategorien mitbringt. Deswegen fehlt u.a. die Klasse isys_custom_fields_dao in deinem System.

Normalerweise dürfte die Logik für benutzerdefinierte Kategorien nur ausgeführt werden, wenn auch tatsächlich eine benutzerdefinierte Kategorie im System existiert.

Ich probiere das Problem später mal zu reproduzieren, vielleicht kann ich dir dann einen einfachen Fix vorschlagen

Viele Grüße
Leo

Hallo @Florian-0

unsere Systeme und Prozesse sind leider nicht für den externen Zugriff ausgelegt. Wir prüfen aber die Möglichkeiten, dies in der Zukunft zu erlauben.

Ich kann dazu aber keine Versprechungen machen

Viele Grüße
Leo