Community
    • Categories
    • Recent
    • Popular
    • Users
    • Search
    • Register
    • Login
    1. Home
    2. LFischer
    3. Best
    Offline
    • Profile
    • Following 1
    • Followers 5
    • Topics 0
    • Posts 594
    • Groups 2

    Posts

    Recent Best Controversial
    • RE: Design der 1.19

      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

      posted in Allgemein
      LFischerL
      LFischer
    • RE: Probleme mit der JSON RPC API - Immer code -32600

      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

      posted in Entwicklung
      LFischerL
      LFischer
    • RE: "Personengruppen Mitglieger"

      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

      posted in Allgemein
      LFischerL
      LFischer
    • RE: XML template for import

      Hello @finaria

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

      Best regards
      Leo

      posted in General
      LFischerL
      LFischer
    • RE: REST API - Parent oder Children finden

      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

      posted in Entwicklung
      LFischerL
      LFischer
    • RE: Abhängige Dialog+ Felder?

      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

      posted in Allgemein
      LFischerL
      LFischer
    • RE: Can't upgrade from v1.13.2

      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

      posted in Operating
      LFischerL
      LFischer
    • RE: Signal für \isys_cmdb_dao_category::save_data

      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

      posted in Entwicklung
      LFischerL
      LFischer
    • RE: unexpected token "::", expecting "(" bei OCS-Inventory Import

      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

      posted in Allgemein
      LFischerL
      LFischer
    • RE: Change company name.

      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

      posted in Operating
      LFischerL
      LFischer
    • RE: Neues Attribute (property) für Listenansicht

      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

      posted in Entwicklung
      LFischerL
      LFischer
    • RE: Zeilenabstände und Abstände in Menübäumen für alle Benutzer definieren

      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

      posted in Betrieb
      LFischerL
      LFischer
    • RE: PHP Fatal Error Memory exhausted beim search-index nach C__CATG__ADRESS

      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

      posted in Allgemein
      LFischerL
      LFischer
    • RE: Neues Attribute (property) für Listenansicht

      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

      posted in Entwicklung
      LFischerL
      LFischer
    • RE: Update auf Version 25 Wo sind die Menüpunkte hin?

      Hallo @tabacha

      die beiden Punkte sind in der neuen Verwaltung hier verortet:

      a1776c61-628b-42e2-854d-7ef39ecb90ac-image.png

      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

      posted in Betrieb
      LFischerL
      LFischer
    • RE: Import CSV Software

      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:
      26b0e8fe-544f-426d-b768-eb512194755d-image.png

      Viele Grüße
      Leo

      posted in Allgemein
      LFischerL
      LFischer
    • RE: Neuer Controller über Symfony Routing component -> Benutzerrechte

      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

      posted in Entwicklung
      LFischerL
      LFischer
    • RE: Bug mit API Addon 1.15

      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

      posted in Betrieb
      LFischerL
      LFischer
    • RE: PHP Fatal Error Memory exhausted beim search-index nach C__CATG__ADRESS

      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

      posted in Allgemein
      LFischerL
      LFischer
    • RE: Probleme mit der JSON RPC API - Immer code -32600

      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

      posted in Entwicklung
      LFischerL
      LFischer