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

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

at the bottom of the updater it says your current version is 1.13.2 - in this state i-doit is only able to update to the next major version (= 1.14). After this you should be able to update to 1.14.1 or directly 1.14.2

Best regards

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

Hello @cdito

that name represents the name of your current tenant. You can rename it from your "Admin Center" -you can access it from the login page or by adding /admin to your i-doit URL (for example https://my-idoit.int/admin).

The login credentials have been set during setup

Best regards
Leo

Hallo @steven_c24

Ich fürchte ich habe hier etwas vertauscht und dir den Weg für ein Attribut genannt das nur im Report Manager auftaucht

Aktuell gibt es für dein Vorhaben nur die folgende Möglichkeit:
Jedes Kategorieattribut kann einen eigenen Callback Code für die Objektlisten mitbringen, dafür gibt es aber aktuell keine Schnittstelle - somit ist das nur über Umwege machbar.

Zur Zeit funktioniert die Logik über den Namen:

Aus dem Attribut guarantee_status in der Klasse isys_cmdb_dao_category_g_accounting würde der folgende Namespace erstellt werden:

idoit\Module\Cmdb\Model\Ci\Category\G\Accounting\GuaranteeStatus - die zusammensetzung sieht dabei folgendermaßen aus:

Kategorie Art: "G" für Global oder "S" für Spezifisch
Kategorie Identifier in CamelCase "Accounting"
Attribut Identifier in CamelCase "GuaranteeStatus"

idoit\Module\Cmdb\Model\Ci\Category\{Kategorie Art}\{Kategorie Identifier}\{Attribut Identifier}

Wenn diese Klasse existiert und das Interface idoit\Module\Cmdb\Model\Ci\Category\DynamicCallbackInterface implementiert kann es für die Objektliste verwendet werden.

Diese Klasse benötigt nur eine statische render Methode Als Beispiel kannst du dir src/classes/modules/cmdb/src/Model/Ci/Category/G/Accounting/GuaranteeStatus.php ansehen.

Das einzige Problem stellt also aktuell nur der statische Namespace dar... Im eigenen Add-on könntest du vermutlich sowas machen wie:

\idoit\Psr4AutoloaderClass::factory()
   ->addNamespace(
      'idoit\Module\Cmdb\Model\Ci\Category\G\MyCustomCategory', 
      __DIR__ . '/src/MyCustomCategory'
   );

Ich glaube das sollte funktionieren - ist aber natürlich nicht der "sauberste" Weg

Ich habe einen Entwickler-Task erstellt um für diesen Use-Case eine Schnittstelle zu implementieren, damit solche Callbacks auch "von außerhalb" hinzugefügt werden können.

Ich hoffe das Hilft weiter!

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

Hi @jimwendrich

das Problem ist tatsächlich sehr merkwürdig, vor allem wenn man betrachtet wie "wenig" Daten indexiert werden. Gibt es ggf. andere Kategorien welche mehr Datensätze indexieren?

Hast du vielleicht ein paar Logs mit weiteren Informationen oder ggf. Stacktrace?

Alternativ würde mich auch mal interessieren wie groß der Index ist - du könntest hierzu auf der Datenbank die folgende Query ausführen:

SELECT COUNT(1) AS cnt FROM isys_search_idx;

Anschließend könntest du den Suchindex neu aufbauen lassen und erneut die Größe auslesen... Eigentlich sollte sich diese nicht ändern Wächst sie allerdings kontinuierlich scheint es tatsächlich ein Problem zu geben!

Viele Grüße
Leo

Hallo @steven_c24

verstehe ich es richtig das es sich dabei um ein "virtuelles" Attribut handeln soll? Also eines, das keine eigenen Daten beinhaltet und nur in der Tabelle auftauchen soll?

Dafür müsstest du das folgendermaßen machen:

use idoit\Component\Property\Type\DynamicProperty;

protected function dynamic_properties()
{
    return [
        '_prop' => new DynamicProperty(
            'LC__CMDB__CATG__GLOBAL_PRICE',
            'isys_catg_accounting_list__isys_obj__id',
            'isys_catg_accounting_list',
            [
                $this,
                'dynamic_property_callback_prop'
            ]
        )
    ];
}

Diese sogenannten "dynamischen properties" funktionieren mit Code-Callbacks Leider ist die Formatierung im Forum etwas kaputt, aber es dürfte trotzdem verständlich sein. Der Callback muss eine public Methode sein, als Parameter wird die komplette Zeile übergeben:

public function dynamic_property_callback_prop(array $row)
{
   return 'custom content :)';
}

Hilft das weiter?

Viele Grüße
Leo

Hallo @tabacha

die beiden Punkte sind in der neuen Verwaltung hier verortet:

Also der "{mandant} Verwaltung" beinhaltet, neben der Lizenz-Info, die Systemübersicht und in der Navbar ist der "i-doit Update" Button

Viele Grüße
Leo

Hallo zusammen,

manche Objekt Browser zeigen nur eine bestimmte Auswahl an verfügbaren Objekttypen an, das hat in der Regel mit einem internen Filter zu tun, der auf zugewiesene Kategorien reagiert.

Bedeutet: Wenn dein Objekttyp "SAP System" z.B. die spezifische Kategorie "Anwendungen" beinhaltet sollte diese hier aufgeführt werden. Weitere Informationen zu diesen Filtern (bzw. zur Frage "Warum taucht mein Objekttyp in Objekt Browser XY nicht auf?") findest du hier:

Verwaltung > CMDB Einstellungen > Objekt-Browser

Hier wählst du den entsprechenden Objekt Browser aus "Softwarezuweisung / Anwendung" und solltest anschließend folgende Information sehen:

Viele Grüße
Leo

Hallo @steven_c24

in i-doit sind alle Routen und Parameter erst nach dem Login verfügbar, das ist das gewollte Verhalten Es sollte auch nicht möglich sein dieses Verhalten mittels OAuth o.Ä. zu umgehen.

Das wäre genau der Punkt an dem die API übernimmt. Um dann auf eigenen Code zuzugreifen müsste die API um einen eigenen Endpunkt erweitert werden, dazu gibt es in der Knowledge Base einen Artikel, siehe https://kb.i-doit.com/de/software-entwicklung/add-ons-entwickeln/api-erweitern.html

Ich hoffe das Hilft weiter

Viele Grüße
Leo

Hallo @spirit21ms

der Bug ist uns bereits bekannt und kann mit nur einer kleinen Änderung repariert werden. Dazu müsste die Zeile 148 in der Datei {i-doit}/src/classes/modules/api/model/isys_api_model_cmdb.class.php getauscht werden.

Diese Zeile

$l_return[$l_map] = $routeGenerator->generate('cmdb.object-type.image', ['objectTypeId' => $p_mapping['isys_obj__isys_obj_type__id']]);

Muss durch diese hier ersetzt werden

$l_return[$l_map] = $routeGenerator->generate('cmdb.object-type.image', ['objectTypeId' => $p_row['isys_obj__isys_obj_type__id']]);

Der Fix wird natürlich auch in der nächsten API Version gelöst sein.

Viele Grüße
Leo

Hey @jimwendrich

ich habe eben einen Kollegen gefragt - der Bug bzgl. den "JDISC Custom Attributes" ist bekannt, aber es gibt noch keinen Fix dafür. So wie es aktuell aussieht wird es auch nicht mehr den Weg in die i-doit 1.17.2 finden.

Die Anmerkung zur White- bzw Blacklist verstehe ich sehr gut. Ich werde das mal mitnehmen, ggf. bekommen wir hier in der Zukunft eine zufriedenstellende Lösung hin

Wenn ich es richtig sehe sollte es (ohne Seiteneffekte) möglich sein die DB Tabelle isys_catg_jdisc_ca_list zu leeren. Vorher aber bitte unbedingt eine Sicherung machen!

Zum letzten Punkt: es kann natürlich sehr gut sein, das die zusätzlichen ~135k Einträge auftauchen weil der Prozess vorher abgebrochen ist... Ich fürchte das kann man nicht wirklich nachvollziehen

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