Der Bug scheint in 1.12.3 behoben zu sein. [Bug][Categories] Subcategory "RAID array/Device" Selection of a controller Siehe auch - https://kb.i-doit.com/display/de/Changelog+1.12.3

Hallo Im Nachgang und Anfrage an i-doit ergab sich folgen - für mich funktionierende Lösung Wähle das Register (obere Leiste) Kontakte Markiere in der Objektansicht die oberste Ebene Kontakte markiere in der Objekttyp-Konfiguration den gewünschten Typ (Personen) und klicke „Editieren“ Scrolle auf den Abschnitt „Kategorien“ Wähle dort aus der Tabelle Zugewiesene Kategorien den Eintrag „Softwarezuweisung“ durch Setzten eines Haken in der * * * Checkbox. Der Eintrag erscheint somit in der Tabelle Kategorien in der Übersichtsseite Klicke auf „Speichern“ Jetzt können sowohl über die Person eine Software und eine Lizenz als auch über die Software diese einer Person angezeigt werden. Funktioniert somit wieder wie zu Beginn (Version 1.12.2). Warum dies zwischenzeitlich "verschwand" ließ sich nicht mehr klären. Viele Grüße Marcel

Bei i-doit wird der HTTP-Proxy unter Verwaltung -> Systemeinstellungen konfiguriert.

Das Problem scheint sich erledigt zu haben. Der Kollege und auch alle anderen Benutzer bekommen die Mails nun. Leider kann ich nicht sagen woran es lag, bei Test mit der console bzw. mit dem controller hatte es vorgestern nicht bzw. nur mit den 2 Benutzer geklappt. Als der CronJob am Abend ausgeführt wurde bekamen auch die restlichen User die Mails. Es funktioniert nun auch über die console mit allen Benutzern. Vielen Dank.

Ich habe den Fehler gefunden: Im Objectbrowser fehlten die Objecttypen..trotz default?? Wo kann man denn den Default sauber einstellen?

Da liegt wohl ein Fehler vor: Entweder im Addon oder im Validierungscode von i-doit. Ich würde also empfehlen: Backup der Datenbank machen Unter Verwaltung -> Systemeinstellungen -> Experteneinstellungen einen Eintrag api.validation = 0 erzeugen (Ich glaube, der ist nicht per default vorhanden). Je nach Geschmack dann System- oder Tenent-wide. Noch mal den Import anstoßen und gucken was passiert.

Hi, ist mir auf meinem System auch aufgefallen und scheint ein Bug zu sein, der mit dem kommenden Minor-Release behoben wird. Lieben Gruß Christian

Hallo Christian, danke für die Info, aber das ist leider nicht die Antwort die ich hören wollte. Das Ziel ist ja, möglichst wenig in anderen Tools (wie hier Excel) machen zu müssen. Außerdem hatte ich vor, den Export aus unserem Inventory-Tool zyklisch in i-doit einlesen zu lassen, damit evtl. veränderte Hostnamen auch in i-doit übernommen werden. Dann werde ich mal schauen wie ich irgendwie die Daten möglichst simpel und automatisiert in i-doit bekomme. LG Thomas

Hallo André, den Button siehst du zum einen, wenn du das Recht dazu hast. Heißt, du kannst auch ohne Admin-Rechte arbeiten, um den Button nicht mehr zu sehen. Dazu kannst du ihn an vielen Stellen deaktivieren, in dem du in der Verwaltung in den Systemeinstellungen den Quickpurge-Button deaktivierst: [image: 1549331193744-16f73c97-a0eb-42c8-a199-10f6277760d6-image.png] [image: 1549331154571-6a3829d8-fbf0-49f9-972d-bb6d0cdf5727-image.png] Lieben Gruß Christian

Hi, funktioniert denn die Suche? Hast du mod rewrite aktiviert? -> https://kb.i-doit.com/pages/viewpage.action?pageId=10223831#DebianGNU/Linux-ApacheWebserver Lieben Gruß Christian

Guten Tag Herr Menzel, hier hilft ein leeren des Cache von i-doit damit Änderungen, im Rechtesystem, sofort übernommen werden.

Mit Hilfe des Supports unter help.i-doit.com wurde das Problem nun behoben. Danke! Bei uns war die PHP-Extensions php-zip nicht installiert. Vermutlich lag dies daran, dass der Server unter Debian 8 aufgesetzt worden war und dann später - während i-doit bereits installiert war - auf die Debian-Version 9 aktualisiert wurde. Die Zip-Extension von PHP war in der Installationsdoku von Debian 8 nicht als Requirement aufgeführt. Beim Überprüfen der installierten Extensions fiel dann noch auf, dass auch die Extension php-mbstring fehlte. Falls jemand also dasselbe Problem hat, am besten mal diese beiden Extensions kontrollieren.

@creiss Das hilft aber nicht wirklich. Da wird das Passwort dann in dem Skript an das PHP-Skript weitergegeben und erscheint wieder in der Prozesstabelle für alle sichtbar. Ich hab vom Support aber mittelerweile eine Info bekommen: Unter src/handler/config/examples/isys_handler_ldap.ini findet man die neuen beispielhaften Konfigurationsdateien die mittels --config oder -c dem entsprechenden Command übergeben werden können (absoluter Pfad). In einer solchen Datei gibt es die Gruppen [commandArguments], [commandOptions]. Mittels dieser Gruppen können dem Command Args oder Optionen übergeben werden, welche das sein können sieht man in der Hilfe des entsprechenden Commands (--help). Für diesen Anwendungsfall sähe das dann so aus: [commandArguments] [commandOptions] user=admin password=admin tenantId=1 Das funktioniert problemlos. Die Informationen sollen in Kürze auch in die KB übernommen werden.

Hallo zusammen, gibt es hier ein Best practice Ansatz für dieses Thema? Wir haben hier genau das gleiche Problem. Viele Grüße Daniel

Moin Moin, ich hätte da noch eine Ergänzung. Ich habe die RAIDs über mehrere Shelfs verteilt (wg Performance und Ausfallsicherheit). Könnte das auch mit aufgenommen werden?

Hey @Batzlen und @klaus-langthaler wir haben uns dran gesetzt und letzte Woche die neue Version des Add-ons veröffentlicht, damit sollte das Problem behoben sein Könnt ihr das bestätigen? VG Leo

genau. ich lass meine user ein virtual server objekt befuellen.. mehrere kategorien.. am schluss setzt der user den status auf 'to_deploy', und nur auf dieses event reagiere ich in einem eventhook, und stosse dann den deploy-eine-vm prozess an... die logik um das event zu filtern ist relativ kompliziert geworden.. weil 10mal nachbessern.. function check_event($event) { // at idoit overview category savebutton click -> we get two events, global and overview // at idoit global category savebutton click -> we get only one event if ($event->categoryConst=='C__CATG__OVERVIEW') { die (getmypid().": not reacting on events of overview category. quitting\n"); } //print_r ($event); $proceed=false; if ($event->categoryConst=='C__CATG__GLOBAL') { if (count ($event->changes)==0) die (getmypid().": no changes. quitting\n"); if (isset ($event->changes->C__OBJ__CMDB_STATUS->to)) { if ($event->changes->C__OBJ__CMDB_STATUS->to !=STRING_DEPLOY) die (getmypid().": status didnt change to '".STRING_DEPLOY."'. quitting\n"); else $proceed=true; } if (isset ($event->changes->{'isys_cmdb_dao_category_g_global::cmdb_status'}->to) ) { if ($event->changes->{'isys_cmdb_dao_category_g_global::cmdb_status'}->to!=STRING_DEPLOY) die (getmypid().": status didnt change to '".STRING_DEPLOY."'. quitting\n"); else $proceed=true; } } if ($proceed) debug( "checking server...\n"); else die (getmypid().": event didnt match categories global or cmdb_status, quitting\n"); } function get_event() { $deploy=""; while($l = fgets(STDIN)){ $deploy.=$l; } $event=json_decode(base64_decode($deploy)); if (json_last_error()) die (getmypid().": error json decode, quitting\n"); return $event; }