Hey @coffee_junkie

da warst du etwas schneller als ich i-doit prüft verschiedene Verzeichnisse in denen sich die Bilder befinden können... Eines davon sollte natürlich passen. Wenn du im "Antwort" oder "Response" Teil des Requests schaust, steht dort The requested image could not be found!?

Der "Location" Teil taucht nur auf, wenn sich das Icon in einem öffentlichen Ordner befindet (also z.B. in /images/...).

Wenn du i-doit im Browser nutzt, verwendest du es in einem Unteroder, z.B. https://my-idoit-host.int/i-doit/ oder direkt in https://my-idoit-host.int? Das könnte ggf ein Indiz dafür sein wieso die Pfade nicht aufgelöst werden können.

ODER es könnte sein das eine Migration beim Update auf i-doit 27 nicht korrekt gelaufen ist. Wir könnten mal einen Objekttyp (z.B. "Server") explizit debuggen.

Dazu müsstest du die folgende Query auf der Mandanten Datenbank (oder als "SQL Report") ausführen:

SELECT isys_obj_type__icon  AS 'objectTypeIcon'
FROM isys_obj_type
WHERE isys_obj_type__const = 'C__OBJTYPE__SERVER'
LIMIT 1;

Für mich taucht hier ein solcher String auf images/axialis/hardware-network/server-single.svg. Wie oben beschrieben ist der images Order "öffentlich" - da sollte es eine Redirect Response geben (Status 302).

Was steht bei dir drin?

edit

Der String aus der DB wird verwendet um eine Reihe von möglichen Pfaden zu bauen:

1. upload/images/{$tenantId}/object-type/icons/{$iconName} hier werden selbst hochgeladene Icons hinterlegt (Mandantenspezifisch)
2. {$iconName} beinhaltet den Pfad, siehe mein Beispiel
3. images/tree/{$iconName} Veraltete PNG Icons
4. Weitere Pfade können via Add-on registriert werden
5. images/axialis/documents-folders/document-color-grey.svg Fallback Icon

Hey @coffee_junkie

das freut mich Hast du eine kurze Info woran es gelegen hat?

Das laden der Objekttyp Icons wurde vor einigen Versionen (in i-doit 27) angepasst. Auch hier könntest du dir mal den Network Tab der Web Entwickler Konsole anschauen - wo liegt der Flaschenhals?

Wenn die Icons geladen wurden sollten diese für einen Monat gecached werden. Im Grunde wird das aber alles von Apache gehandhabt.
Werden diese bei jedem Seitenaufruf neu geladen? Ist bei dir ggf. das Browsercaching deaktiviert?

Du kannst dir im Network Tab auch die "Response Header" ansehen - da sollte stehen das die Icons für einen Monat gecached werden sollen.
Eine ähnliche Konfiguration gibt es in der .htaccess Datei von i-doit. Hier wird für einie Bildformate eine "Expiration" von 30 Daten definiert, sofern das mod_expires Modul aktiviert ist. Könntest du das prüfen?

Viele Grüße
Leo

Hallo @coffee_junkie

diese (zugegeben nicht aussagekräftige) Meldung wird während des Login ausgegeben wenn der technische "Login" Prozess mit einem HTTP Status antwortet der nicht "OK" ist. Für weitere Infos müssten wir uns das mal genauer anschauen.

Könntest du dazu den Login mit geöffneter "Web Entwickler Toolbar" (kann üblicherweise über "F12" geöffnet werden) ausführen?

Dazu bitte VOR dem Login Prozess öffnen und den Netzwerk / Network Reiter öffnen und sicherstellen das die Logs bestehen bleiben (sonst verschwinden die Infos, nachdem die Seite neu geladen wurde). Das sollte so aussehen:

Sollten dort bereits Zeilen drin stehen bitte leeren

Nach dem Login, sollte es etwa so aussehen (die Liste geht weit nach unten, wir benötigen aber nur die ersten Zeilen):

Bei dir scheint es so zu sein das einer der ersten beiden Zeilen keinen Status 200 zurückmeldet (siehe grüne Zahl ganz links). Könntest du hier ggf. ein paar mehr Infos liefern?

Ggf. werden auch Fehler in deinem Apache Error Log geschrieben - die könnten uns weiterhelfen

Viele Grüße
Leo

Hallo @mio

bzgl. der Dokumentation kann ich leider nichts sagen - habe die Infos aber weitergeleitet.

Ich habe mir aber den Fehler angeschaut (Implicitly marking parameter $short as nullable is deprecated, the explicit nullable type must be used instead (...)) - dieser tritt eigentlich erst mit PHP 8.4 auf. Damit ist i-doit (und auch die Add-ons und Partner Add-ons) noch nicht kompatibel.

Ist tatsächlich nur PHP 8.3 installiert oder könnte es sein das idoitcmk auf etwas anderes zugreift? Ich habe da leider keine Einsicht

Viele Grüße
Leo

Hallo @sj

zu diesem Problem gibt es bereits einen Hotfix in unserer Knowledge-Base Siehe hier: Category is not displayed or the category list is empty and a PHP Fatal error is logged mit ID-11972.

Das sollte weiterhelfen!

Viele Grüße
Leo

Hallo @StefanP74

ich habe noch mal recherchiert - wir hatten damals zu diesem Problem ein Bug im Dokumente Add-on erstellt der inzwischen gelöst ist. Die Version mit dem Fix ist allerdings noch nicht veröffentlicht

In der neuen Version werden verlinkte Bilder in Beschreibungsfeldern (und aktuell NUR in Beschreibungsfeldern) rausgesucht und beim kompilieren des Dokuments geprüft.

Bei öffentlich verfügbaren Bildern wird nichts gemacht - aber bei Bildern "aus i-doit", konkret über den WYSIWYG hochgeladene oder aus der "Bilder" Kategorie stammend, wird nun Logik ausgeführt die den Inhalt des Bildes vernünftig laden.

Ich fürchte ich kann gerade noch kein genaues Datum für die Add-on Version geben. Werde aber mal nachhaken Ein möglicher Termin KÖNNTE das Release von i-doit 36 sein (Ende August) aber dazu wurde noch nichts entschieden.

Viele Grüße
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

Hallo @StefanP74 ,

ich fürchte ich muss dir sagen dass das die gleiche Ursache hat wie https://community.i-doit.com/topic/4932/report-nach-datum-sortieren/6

Ich habe das Thema inzwischen noch mal intern angestoßen und wir werden schauen ob wir die sortierung für alle Attribute verfügbar machen können.

Ich kann aktuell leider keine Aussage darüber machen ob/wann wir das umsetzen werden...

Viele Grüße
Leo

Hello @inasutin

the error tells us that your machine (or rather PHP) does not have enough memory to index all your data.

The simple solution would be to increase the memory limit for PHP.

The "proper" solution would be to find out which category is causing this issue and also re-evaluate if the data that is currently being indexed in terms of "do we really need to index this?"

In order to do so you can manually re-index the search by running the command @StefanP74 supplied but add the -vvv option to see all details. You will see which categories gets indexed and the amount of entries (please note: the process will slow down due to this output).
This can help you find the culprit (= the category that causes the memory issue).

sudo -u www-data php /var/www/html/console.php search-index --user admin --password XXXXXXXXX --tenantId 1 -vvv

Afterwards you can try to adjust the indexing. For example you can prevent certain categories from beeing indexed as you might not need them to be searchable - that will free up resources!

For this you can call the search-index command and pass a list of categories that you actually want to be indexed via --category ... This will be a bit tedious, but ideally you'll only have to do it once.

sudo -u www-data php /var/www/html/console.php search-index --user admin --password XXXXXXXXX --tenantId 1 --category C__CATG__GLOBAL --category C__CATG__CPU

Best regards,
Leo

Hallo @StefanP74

ich kann dir hierzu leider nichts neues liefern.

Ich habe mit einem Kollegen gesprochen ob wir das technisch abbilden können und die Antwort darauf lautet erst mal "Ja". ABER wenn wir erlauben nicht-indizierte Felder per Query zu sortieren kann es bei komplexen Reports schnell zu performance Problemen kommen

Ich werde ein Ticket (Feature Wunsch) dazu für i-doit 35 schreiben - mit etwas Glück können wir das bis dahin umsetzen!

edit

Mir fällt gerade ein - wir arbeiten gerade daran die Tabellen-Komponente der Reports gegen die allgemeine Komponente (aus Objekt- und Kategorielisten) zu tauschen. Damit wäre es bereits möglich die Einträge beliebig zu sortieren (was aktuell ja nicht immer klappt) - allerdings erst nachdem der Report geöffnet wurde. Wäre das ein Plan B?

Viele Grüße
Leo

Hallo @sihadmin

ich verstehe... Ich habe auch gerade noch mal genauer nachgesehen: für i-doit 1.12.2 kannst du nur bis Dokumente Add-on Version 1.3.3 nutzen, ab Version 1.4 wird i-doit 1.13 vorausgesetzt.

Hast du diese beiden Portale geprüft?

Es gibt (noch) das portal.i-doit.com Portal.
Wenn du einen Lizenz-Token hast, kannst du auch center.i-doit.com probieren.

Sollte dir das nicht weiterhelfen kannst dich bei help@i-doit.com melden - unser Support sollte dir die nötigen Version zuschicken können

Viele Grüße
Leo