@Michael-Huhn Hi, ist schon eine weile her, ich habe aber endlich eine Lösung gefunden. Ich habe mich gewundert warum das ändern der "api erzwinge Authentifizierung" im Admincenter keine Wirkung zeigte, es stand schon auf nein, wenn ich es auf ja stellte (was ich ja nicht wollte) war das nicht sticky, beim einem reload stand es wieder auf nein, da wusste ich das hier irgendwas kaputt ist. Die Lösung war dann folgende, ich musste in der idoit_system Datenbank in den isys_settings das das Feld "isys_settings__isys_mandator_id" von 1 auf 0 stellen. Danach konnte ich auch bei "api erzwinge Authentifizierung" umstellen und es blieb dann nach einem reload der Seite erhalten. Es steht jetzt also "wirklich" auf nein und Zammad kann auf die API zugreifen \o/ Ich vermute mal 0 ist das Gesammtsystem und 1 mein eigentlicher Mandant? ich habe nur einen Mandanten.

Hey Mathias, danke für den Input! Interessante Frage zu den Flows. Das mit dem Trigger ist mir auch aufgefallen. Könnte ein Bug sein? Ähnlich wie das mit dem Pokerogue Dex in Pokerogue , wo manche Features nicht wie erwartet triggern. Logs wären super, um Fehler zu debuggen, ähnlich wie bei der Fehleranalyse in komplexen Spielmechaniken! Grüße zurück!

@apfel-jan hast du das Thema lösen können? Ich habe heute dazu eine Anfrage bei der Synetics eingereicht.

It seems like mod_rewrite is enabled, but i-doit isn't detecting it. Check the following: Ensure LoadModule rewrite_module modules/mod_rewrite.so is uncommented in your Apache config. Set AllowOverride All in your virtual host configuration. Check for an .htaccess file in the i-doit directory. Restart Apache after any changes. Good luck!

Find much info here!

Interesting problem! Perhaps a caching issue within the Documents Add-On? Double-check the filter logic to ensure it's consistently applied. Also, could the archived status be changing after the initial data pull but before form generation?

Der Hinweis von StefanP74 (siehe weiter unten) war bei mir erfolgreich, die Problematik war identisch. Gruß, T1

Hallo @AndreasR es gab in den älteren i-doit Versionen einen Bug dazu. Dieser wurde aber zum Teil in i-doit 35 und dann final in i-doit 36 gelöst. Welche Version nutzt du? Könntest du uns auch einen Screenshot deines Mappings (inkl. der Optionen oberhalb) zeigen? Wichtig ist dass das Mapping den Objekttypen beinhaltet und im oberen Teil kein Objekttyp ausgewählt ist (da dieser ja durch die CSV bestimmt wird). Viele Grüße Leo

@mwaldeck Vielen Dank für die Rückmeldung.

@u2micha Für das SSO wird doch nur das AuthType verwendet, d.h. es müsste doch möglich sein, eine Location auszunehmen: <Location /src/jsonrpc.php> AuthType None Require all granted </Location> Ich kenne aber mod_auth_mellon nicht. Das README hat einen anderen Vorschlag: <Location /noSSO> MellonEnable "off" Require all granted </Location>

@Michael-Huhn Danke für die Rückmeldung. Ich habe zwei Drafts eingestellt. Ich muss nochmal in Ruhe schauen, ob ich was übersehen habe. https://github.com/i-doit/knowledge-base/pull/1093 https://github.com/i-doit/scripts/pull/50 Was mir generell am meisten aufstößt, ist dass die DocumentRoot komplett mit Schreibrechten für den Apache ausgestattet wird. Auf der Seite vom Hardening wird dann mit Permissions und immutable Attribute das wieder gesichert. Das macht IMHO wenig Sinn, dass man sichere Voreinstellungen des Systems (z.B. Owner root:root mit Context httpd_sys_content_t) aufweicht, um sie dann später umständlich wieder zu härten. Ich bin ja ein Fan davon, gleich alles richtig und sicher zu installieren (dann kann man es auch gut als RPM verpacken) und nur auf die Verzeichnisse dem Webserver Schreibrechte zu geben, wo diese tatsächlich notwendig sind. Aber dann kann man natürlich erstmal nicht den Web-Updater benutzen. Aber die sind aus Sicherheitsgesichtspunkten sowieso immer kritisch, wenn der Web-Update seinen eigenen Code aktualisieren will, sofern man keinen Umweg über ein Script geht, welches als root läuft (der Web-Update startet z.B. per sudo ein Script als root, welches den Code aktualisiert...) Soll man das hier diskutieren oder ist es besser, ich mache ein Issue im GitHub zu diesem Thema?

@mamawe Hast Du hier ggf. schon eine Möglichkeit gefunden? Besten Dank im Voraus! VG TheBob

@LFischer Hi Leo, alles klar. Dann werde ich entsprechende Vorschläge einreichen. Danke für die Rückmeldung! Grüße Malte

Hallo @jakob dein Ansatz ist soweit eigentlich ganz gut, es fehlt nur der richtige Wert für assigned_connector. In solchen Fällen kann es schon weiterhelfen die Daten auszulesen und mit der GUI zu vergleichen { "version": "2.0", "method": "cmdb.category.save", "params": { "object": 1234, <-- Objekt ID (Server) "category": "C__CATG__CONNECTOR", "data": { "title": "Connector", "assigned_connector": 123, <-- Anschluss Datensatz ID "cable_connection": 234 <-- Kabel Objekt ID }, "apikey": "<hello-api>" }, "id": 1 } Der Wert für assigned_connector muss die Datensatz ID des zu verbindenden Anschlusses sein, das kannst du in der GUI z.B. hier sehen: [image: 1755614326990-4e304c88-3318-4f3c-84da-0fc801b49966-image.png] Alternativ kannst du dir den value der Checkbox anschauen (falls das data-connector-id Attribut nicht existiert). Bezüglich entry ist wichtig zu wissen das die save Methode zum erstellen und aktualisieren genutzt werden kann. Lässt man entry leer wird ein Datensatz erstellt (= create), gibt man eine Datensatz ID an, wird diese aktualisiert (= Update). Viele Grüße Leo

Hallo @kholzenhauer , die Lösung für diesen Fehler ist der Hotfix ID-11972. Wenn man im apache2 error.log nachschaut (/var/log/apache2/error.log), ist dort auch die Fehlermeldung zu finden, welche auf der KB Seite für den Hotfix angegeben wurde. Also einfach den Hotfix installieren, wie auf der KB Seite beschrieben und dann sollte die Kategorie wieder normal laufen.

Hallo @Michael-Huhn vielen Dank für den Link. Er hat mein Problem behoben. VG, Cherif

Hat sich da noch etwas getan? Ich habe das Problem auch z.B. bei Servern mit mehreren CPUs

Hi @LFischer, ich habe das Problem mit den Icons gelöst . Hier ist nochmals eine Zusammenfassung zu den zwei jeweiligen Problemen. Falls jemand dieses Problem auch haben sollte. Hinweis: Persönliche Informationen habe ich entfernt. Die wichtigen Informationen habe ich nochmals zusammengefasst. Die Auszüge sind verkürzt außerdem verwende ich hier einige Platzhalter. Fehlermeldung i-doit system error: Error Bei der migration von der idoit (Produktivumgebung) zu idoittest (Testumgebung) habe ich auf der Datenbank einige Konfigurationen vergessen. Auf der Datenbank habe ich nochmals die Konfigurationen angepasst. Auf der Datenbank folgenden Befehl ausführen: SELECT * FROM isys_settings WHERE isys_settings__value LIKE '%idoit%'; Hier ist der Auszug aus der Datenbank von der Produktivumgebung: +-----------------------------+---------------------------------------------------------------+----------------------------------+ | isys_settings__key | isys_settings__value | isys_settings__isys_mandator__id | +-----------------------------+---------------------------------------------------------------+----------------------------------+ | ido_monitos__debug_file | /path/to/idoit/log/monitos.log | x | | system.base.uri | https://idoit.de/ | x | | system.dir.file-upload | /path/to/idoit.de/upload/files/ | x | | system.dir.image-upload | /path/to/idoit.de/upload/images/ | x | +-----------------------------+---------------------------------------------------------------+----------------------------------+ In der Spalte isys_settings__value müssen die Einträge angepasst werden. In diesem Fall zu idoittest. Icons werden nicht angezeigt Der Hinweis mit .htaccess war sehr hilfreich. Auf dem idoittest fehlten einige dotfiles. Ich habe diese 1:1 kopiert.