Kann ich bestätigen, scheint ein Bug zu sein.
Bau dir doch einfach ein Standard-Template mit ISMS Relevanz = Ja und hinterleg das beim Objekttyp "Client", dann sparste dir auch die Listeneditierung vollständig.


Kann ich bestätigen, scheint ein Bug zu sein.
Bau dir doch einfach ein Standard-Template mit ISMS Relevanz = Ja und hinterleg das beim Objekttyp "Client", dann sparste dir auch die Listeneditierung vollständig.


@IT_GAP Alternative wenn eure Bezeichnungen so aufgebaut sind "Client-123-hggdj-273" und du nur die 123 haben willst
dann kannst du zweiten Teil nehmen
{{ object.C__CATG__GLOBAL.title | split('-')[1] }}
oder wenn du z.B. nur den letzten Teil "273" willst
{{ object.C__CATG__GLOBAL.title | split('-') | last }}
Du kannst das ganze auch über die Twig Engine gestalten
{{ object.C__CATG__GLOBAL.title | replace({'a': '', 'b': '', 'c': '', 'd': '', 'e': '', 'f': '', 'g': '', 'h': '', 'i': '', 'j': '', 'k': '', 'l': '', 'm': '', 'n': '', 'o': '', 'p': '', 'q': '', 'r': '', 's': '', 't': '', 'u': '', 'v': '', 'w': '', 'x': '', 'y': '', 'z': '', '.': '', ' ': ''}) }}
Dann wird aus

Direkt die Nummer extrahiert

Einfach einfügen

@Matthe Wenn du schon Kabel erzeugt hast, wäre mir adhoc keine Möglichkeit bekannt es wieder bei 9000001 beginnen zu lassen. Gegebenenfalls könntest du aber als Präfix 9000 anstellen.
Wenn das letzte erzeugte Kabel die 973 hatte, würde das nächste zumindest die 9000974 bekommen.
Option: Präfix für automatische Bezeichnung von Kabelobjekten:

Kannst du mal in das Objekt reinklicken und dann die Druckansicht aufrufen. Wird es dann korrekt bei dir angezeigt mit den benutzerdefinierten Kategorien?
Moin
Erstelle dir doch einfach einen Bericht in i-doit über den Report Manager und lese den aus.
{
"version": "2.0",
"method": "cmdb.reports.read",
"params": {
"language": "en",
"apikey": "meinkey",
"id": "112" <---- report id
},
"id": 1
}
Report konfigurieren

Ergebnis:
{
"id": 1,
"jsonrpc": "2.0",
"result": [
{
"Title": "srv-erp",
"Contact": "Pattrick Bluhm",
"Primary": "Yes"
},
{
"Title": "srv-dc1",
"Contact": "Heike Müller",
"Primary": "Yes"
}
]
}
Hallo Matthe,
zu 1:
Je nach Komplexität kann es sinnvoll sein sich noch einen eigenen Objekttypen für den Controller anzulegen.
Du kannst einen AP als Template mit allen benötigten Informationen (z.B. SSID) anlegen und daraus Objekte beliebige Anzahl an Objekten erzeugen oder einen bestehenden AP der fertig konfiguriert ist duplizieren.
zu 2:
Option A: Du erstellst bei einem Client einen Netzwerkport und beim Access Point einen Netzwerkport und verbindest die Ports dann.
Option B: Du erstellst dir eine benutzerdefinierte Kategorie für AP und verknüpfst über Objekt beziehung die zugehörigen Clients. Dann hast du aber nicht die Verkabelungsansicht.
Ein anderer Weg würde mir adhoc nicht einfallen.
Ich hab das in einem Kundenprojekt z.B. folgendermaßen gelöst:
Die Benutzerkonten werden in den Personen erfasst und mit den Anwendungen verknüpft.

In den Anwendungen wird das dann einfach Rückwärts aufgelöst, sodass man eine Gesamtübersicht erhält.

Einen Button gibt es zwar nicht, aber du könntest dir über das kostenfreie Events Add-on einfach einen Workaround erstellen.
Neuen Objekttypen "LDAP-Sync" anlegen
Event konfigurieren, dass wenn ein neues Objekt in LDAP-Sync angelegt wird, das script zum LDAP Sync ausgeführt wird.
Wenn du nun ein neues Objekt mit "LDAP-Sync am 28.06.2024) erstellst, wird im Hintergrund das sh-Script ausgeführt und die Benutzer synchronisiert + du hast noch eine Übersicht wann manuelle Syncs getriggert wurden.
Moin,
lös das doch einfach über verschiedene JDISC Profile. Netzwerkkomponenten werden mit Verkabelung importiert, bei Clients Monitoren usw. deaktivierst du die Verkabelung.
Grüße
Ich hoffe ich hab den Use-Case richtig verstanden, ohne Screenshots ein wenig schwer sich da reinzufinden.
Warum nutzt du für den Standort des Werkzeugs nicht einfach die Kategorie Standort?
Person (Objekttypkonfiguration = Standort -> Ja)
Im Werkzeug wird nach dem scannen der Standort auf die Person eingestellt. Nach Rückgabe wird der Standort auf den Schrank gesetzt.
@mwaldeck die synchronisierung sorgt u.a. dafür das die aktuellen Daten der Mitarbeiter auch in i-doit vorhanden sind. Beispielweise wenn diese als Kontaktpersonen oder Ansprechpartner für bestimmte Geräte oder Verträge hinterlegt werden sollen.
Wenn nur bestimmte Nutzer in i-doit importiert werden sollen, würde ich diese in eine extra AD-Gruppe packen und dann die automation für den Import so einstellen, dass nur Nutzer der Gruppe importiert werden. Das bedeutet in jedem i-doit Mandanten einen eigenen Filter konfigurieren und dann über den cronjob steuern welcher Mandant mit welchem Servereintrag synchronisiert werden soll.
sudo -u www-data php console.php ldap-syncdn --user admin --password admin --tenantId 2 --ldapServerId 1