Ich bin auf der Suche nach einem guten Weg für den Import von Patchdosen mit Anschlüssen.
Wir haben Patchdosen mit zwei Anschlüssen, die z.B. als P2-07/08 beschriftet sind.
Die Anschlüsse habe ich bisher manuell passend angelegt, also 07, 08, 07 - BACK, 08 - BACK
Ich finde keinen Weg, diese Anschlüsse über den CSV-Import entweder anzulegen oder nachträglich zu benennen.
Wie macht Ihr das? Bei einer großen Anzahl Patchdosen möchte man das ja nicht alles manuell anlegen.
Alternative wäre, die Anschlüsse bei den Patchdosen immer einheitlich zu benennen, z.B. als 01, 02, 01 - BACK, 02 - BACK und diese per Massenänderung zu erstellen.

@LFischer Hallo Leo,
entschuldige die späte Antwort - das Problem wurde mit dem passenden Hotfix bereits behoben.
Vielen Dank!

Hallo,
ich wundere mich, warum normale Templates und Templates für Massenänderung unterschiedlich sind.
Es gibt bei uns einige Fälle, z.B. Schränke, Patchpanels usw. für die ich die spezifischen Eigenschaften nach dem CSV-Import per Massenänderung setze (Hersteller, Anschlüsse usw.).
Für diese Objekttypen habe ich aber auch schon normale Templates, wenn man einzelne Objekte per Hand anlegt.
Beide Template-Sorten machen doch eigentlich das gleiche, würde nicht ein Template für beide Zwecke genügen?

Ich versuche, mehre Objekte mit verschiedenen Objekttypen per CSV in i-DoIT zu importieren.
Dabei nutze ich zum Test dieses Beispiel, https://kb.i-doit.com/de/daten-konsolidieren/csv-datenimport/beispiel-fuer-den-csv-import-standorte-erstellen.html

und ein minimales Beispiel im Anhang.
Auf unserer Instanz bekomme ich in allen Fällen einen Fehler im Log: "Notiz: Given object type could not be found:"
Die Objekt-Typ-Konstanten sind alle vorhanden.
Ich finde auch in den i-DoIT-Logs keine Hinweise, an was selbst der einfachste Import scheitern könnte.
Ich habe das gleiche auf demo.i-doit.com 1:1 identisch gemacht, dort funktioniert der Import wie erwartet.
Ich vermute ein Problem mit unserer i-DoIT-Instanz.
Gibt es erweiterte Log-Optionen oder andere Hinweise, wie wir dem Problem auf die Spur kommen können?

ObjektName;Standort;Objekttyp
EinServerImport;SAFZ;C__OBJTYPE__SERVER

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

Ich versuche gerade, einer Personengruppe Rechte für CMDB-Objekte unterhalb einer Lokation zu geben, und habe es nun auch hinbekommen, aber das Konzept noch nicht ganz verstanden.

Mein erster Ansatz war, in den Berechtigungen für diese Personengruppe das Recht "Objekte unterhalb einer Lokation" zu nutzen, aber die Berechtigung "Erstellen" ist immer ausgegraut.
Wieso?
Nun habe ich es gelöst wie im Bild: Man kann alle Objekte erstellen/ändern, aber nicht betrachten.
Das geht nur für Objekte unterhalb der Lokation.
So sehen die Mitglieder der Gruppe nur "Ihre" Objekte und können dort frei arbeiten.
Wenn sie jetzt aber ein neues Objekt erstellen, können sie es an jeden Standort verorten, nicht nur an Standorte innerhalb der eigenen Lokation wie bekomme ich das hin, und ist das überhaupt eine sinnvolle Umsetzung?

Hallo zusammen,

ich habe noch nicht ganz verstanden, was mit dem o.g. Objekttyp ursprünglich abgebildet werden soll.
Geht es hier um die einzelnen Out-of-Band-Controller, so dass man z.B. als Objekte iDrac8, iDrac9, iDrac10 anlegt und das bei den entsprechenden Systemen verknüpft?
Oder ist das eher für Lösungen wie Dell OME gedacht? Dann würde die Verknüpfung "Verwaltete Geräte" irgendwie sinnvoller erscheinen.

Beste Grüße

@Instructor Das Problem scheint weiterhin zu bestehen.
Ich habe ein Template angelegt für eine Steckdosenleiste, 1 Eingang -> 7 Ausgänge, alle dem gleichen Eingang zugeordnet.
Erstelle ich daraus Objekte, ist nur noch 1 Eingang einem Ausgang zugeordnet.

@sargon
Das gleiche Problem habe ich auch - es bleibt nur EINE Zuordnung übrig, wenn man aus so einem Template ein neues Objekt anlegt.
Das passiert in der Demoinstanz auch.

https://demo.i-doit.com/?viewMode=1002&tvMode=1006&objID=5457&catgID=50