Hallo,

das Verhalten wurde durch eine Änderung im Bereich der verknüpften Dialog-Plus-Felder hervorgerufen. In unserer Knowledge Base findet ihr dazu einen Hotfix, der die Änderung erst einmal rückgängig macht:

https://kb.i-doit.com/de/administration/hotfixes/index.html

Wir werden natürlich weiter daran arbeiten, die Änderungen in einer Form in zukünftige Releases zu bringen, die nicht die Pflege neuer Modelle unterbindet.

Lieben Gruß und weiterhin gutes Gelingen mit i-doit.
JD

//EDIT: Da war @Michael-Overkamp ein paar Sekunden schneller.

Hi 5t0ne,

die spezifische Kategorie "Rack" ist ein Feature zur Visualisierung und steht daher ausschließlich in i-doit pro zur Verfügung, weshalb du sie in i-doit open nicht findest. Eine Übersicht über die Unterschiede beider Varianten findest du unter: https://www.i-doit.org/cmdb-it-documentation/

Lieben Gruß
Jens

Hallo Chris,

ich vermute für die Zuordnung soll die Kategorie "Dateizuweisung" genutzt werden. Diese unterliegt allerdings einigen Besonderheiten. Man erkennt zum Beispiel bei der Zuweisung im Objekt-Browser das Baum-Menü, in dem die bereits existierenden Dateien ausgewählt werden können und die zusätzlich vorhandene Upload-Funktion.
Da diese Funktionen nicht auf die Listeneditierung abgestimmt sind, ist die Zuweisung über die Listeneditierung nicht möglich.
Hierfür steht jedoch die Massenänderung zur Verfügung:
https://kb.i-doit.com/pages/viewpage.action?pageId=20250697
In der Vorlage muss lediglich einmal die Zuweisung gemacht werden. Anschließend kann die Vorlage auf alle Objekte übertragen werden, damit der Lieferschein dort zugewiesen ist.

Freundliche Grüße
Jens

Hallo Herr Lehmann,

aktuell gibt es hierfür keine direkte Lösung, die das Löschen einzelner Einträge über mehrere Objekte erlaubt. Wir überarbeiten allerdings derzeit umfangreich die Listeneditierung. Prinzipiell ist diese Funktion natürlich, wie der Name schon sagt, zum Bearbeiten (Editieren) vorgesehen. Dies schließt eigentlich das Löschen aus, jedoch werde ich einmal schauen, ob sich eine solche Funktion noch in das Konzept integrieren lässt.

Ich hatte jedoch schon einmal einen vergleichbaren Fall, dessen Workaround sich mit einigen Änderungen auch auf Ihr Szenario übertragen lässt. Die Lösung läuft hier über einen Report (oder falls vorhanden über eine vorliegende Datengrundlage) und einen anschließenden CSV-Import.

Erzeugen Sie im ersten Schritt einen Report über die gewünschten Objekte. Lassen Sie sich hierbei alle Attribute der entsprechenden Multi-Value-Kategorie ausgeben. Stellen Sie außerdem sicher, dass alle Attribute, die zur eindeutigen Identifikation notwendig sind, im Report vorhanden sind.
Nun können Sie die CSV-Datei in einem Tabellenverarbeitungsprogramm Ihrer Wahl so anpassen, dass die nicht benötigten Einträge aus der Datei entfernt werden. Hierbei helfen zum Beispiel Gruppierungsfunktionen, wenn es darum geht, doppelte Einträge auf eindeutige Einträge zusammenzufassen. Sobald alle unerwünschten Einträge aus der CSV-Datei entfernt wurden und sichergestellt ist, dass die Datei die UTF-8 Kodierung nutzt, können Sie sie für den Import verwenden. Hierbei müssen die Attribute so gemappt werden, dass sie wieder zusammenpassen. Außerdem muss über die Identifikationsattribute sichergestellt werden, dass die Erkennung des Objekts möglich ist. Die mitunter wichtigste Einstellung beim Import lautet nun "Behandlung von Multi-Value-Kategorien". Die CSV-Datei sollte nun weiterhin alle Informationen zur Kategorie enthalten. Lediglich die doppelten Einträge sollten nicht mehr enthalten sein. Aus diesem Grund können Sie hier die Auswahl "Bestehende Kategorien überschreiben" nutzen. So werden die bisherigen Kategorie-Einträge komplett entfernt und nur die neuen Einträge werden importiert.

Sollte eine solche CSV-Datei, die alle Informationen zu den Multi-Value-Kategorien bereits vollständig enthält, existieren, muss die Datengrundlage natürlich nicht über einen Report geschaffen werden. Sollte diese Datengrundlage mehr Informationen erhalten sein, müssen natürlich nicht alle Felder gemappt werden. Hierbei ist es ausreichend, die zur Identifikation relevanten Attribute sowie die Inhalte der Multi-Value-Kategorie zu mappen und den Import im Modus "Bestehende Kategorien überschreiben" durchzuführen.

Freundliche Grüße
Jens

Hallo,

das Thema wurde von uns aufgenommen und für unsere Entwicklungsabteilung aufbereitet. Die Kollegen streben aktuell eine Lösung zur kommenden Version 1.11.1 an. Ich gehe davon aus, dass die beschriebenen Umstände mit dieser Version korrekt berechnet werden. Falls weitere Dinge auffallen, gerne Bescheid geben, dann nehmen wir das mit auf.

Freundliche Grüße
Jens

Hallo Florian,

die dynamische Vergabe von Rechten auf Basis gleichgerichteter Informationen ist in i-doit nur bedingt möglich. Der bereits angesprochene Ansatz über den logischen Standort setzt voraus, dass die Verträge einzelnen Arbeitsplätzen zugeordnet werden. Da in der Realität jedoch ein Vertrag nicht Teil eines Arbeitsplatzes ist, macht das wenig Sinn. Außerdem wird dieses System nur funktionieren, wenn es sich um eine 1:1-Beziehung zwischen Benutzer und Vertrag handelt. Sollte es hier Überschneidungen geben, muss sichergestellt werden, dass nicht Teile des logischen Standorts verrechtet werden, auf die ein anderer User keine Rechte erhalten soll.

In der Regel wird ein solcher Umstand tatsächlich darüber gelöst, die Objekte einzeln, anhand ihrer IDs, zu verrechten. So wird auch die Thematik umgangen, dass Rechte auf andere Objekte versehentlich vergeben werden.

Auch bei der Auswahl der Rechte über eine Personengruppe müssen die entsprechenden Verträge einzeln selektiert werden.

Ein Workaround bietet sich eventuell an, wenn er mit der Anforderung vereinbar ist: Bei einer umfangreichen Dokumentation von Verträgen wäre es denkbar, eine neue Objekttyp-Gruppe "Verträge" zu erstellen. Diese wird mit unterschiedlichen Objekttypen die die einzelnen Vertragsgruppen klassifizieren ausgestattet. Denkbar wäre hier eine Aufteilung nach Abteilung/Verantwortlichkeit (Verträge Abteilung A, Verträge Abteilung B, ...)
Anschließend werden für die Mitarbeiter von Abteilung A über ihre Personengruppe die Verträge des Typs "Verträge Abteilung A" verrechtet. Gleiches passiert dann für Abteilung B, C, etc.
Durch die Verrechtung über den Objekttyp werden automatisch neue Verträge automatisch verrechtet, wenn sie im korrekten Objekttyp dokumentiert werden. Auf diesem Weg können Pools von Verträgen mit geringem Aufwand verwaltet werden.

Andernfalls bietet sich nur die Lösung über einen Feature Request. Ich empfehle in diesem Fall den Kontakt über unser Helpcenter https://help.i-doit.com
Mit einer möglichst präzisen Beschreibung der Anforderung werden wir diesen Request aufnehmen und an unser Product Management übermitteln.

Freundliche Grüße
Jens

Hallo,

in einem ersten Versuch konnte ich das Verhalten nicht nachstellen. Da wir hier weitere Informationen benötigen, habe ich für diese Frage ein Ticket in unserem Support-Portal erstellt.

Lieben Gruß
JD

Hallo yaa9k47,

derzeit sieht das Design vor, dass der Standort-Pfad maximal auf fünf "Schritte" begrenzt wird. Wenn also die Root-Location den sechsten Schritt darstellt, wird der gesamte Pfad um diese gekürzt.
Dies ist eine Vorgabe, die von i-doit vorgegeben wird und derzeit nicht umgestellt werden kann.
Hierzu gibt es jedoch einen Feature-Request, der die Anpassbarkeit dieser Einstellung beschreibt. Zukünftig wird es also möglich sein, die Anzahl der maximalen Schritte, die im Standort-Pfad angezeigt werden, selbst festzulegen.

Viele Grüße
Jens

Hallo Dexter,

wir haben uns die Thematik noch einmal im Detail angesehen. Anscheinend gibt es hier einen parallelen Auslöser für die Kategorie "Ports". Mit dem zuvor bereitgestellten Fix lässt sich das Ganze für die "Anschlüsse" korrigieren. Unsere Entwickler werden sich den Ursprung daher noch einmal gründlicher ansehen und sicherstellen, dass es keine weiteren Kategorien gibt, bei denen es in der Listeneditierung zu dieser Meldung kommt und alle betroffenen Stellen anpassen. Eine Korrektur wird definitiv zur Version 1.9.2 erfolgen, welche in etwa vier bis sechs Wochen veröffentlicht wird.

Hallo zusammen,

ich konnte diese Darstellung im Logbuch ebenfalls beobachten. Die Entwickler sind informiert und werden eine Korrektur für zukünftige Versionen durchführen.

Freundliche Grüße
Jens

@mnicolaij:

hat leider nichts gebracht. Werde mal ein Ticket aufmachen.

Danke für die Antworten.

Viele Grüße
Monika Nicolaij

Hallo,

welches Bild ergibt sich denn, wenn das Dashboard in einem anderen Browser aufgerufen wird? Ist diese Darstellung bei allen Usern gleich oder gibt es hier Unterschiede, wenn man sich zum Beispiel mit dem Editor einloggt? Alternativ wäre es ein Ansatz, die Widgets vom Dashboard einmal zu entfernen und im Anschluss neu hinzuzufügen.

Liebe Grüße
Jens

@StefanScherer:

Hallo Benjamin,

wir haben jetzt den Wert in  der Spalte isys_obj__undeletable wie angegeben geändert.
Leider ohne Erfolg. Der Client lässt sich nicht purgen. Fehlermeldung wie gehabt.

Was kann ich noch machen ?

Hallo,

wie Benjamin bereits beschrieben hat, ist dieses Verhalten in der Tat sehr merkwürdig. Welche Objekt-ID wird zu dem Objekt in der Kategorie "Allgemein" angezeigt? Ich möchte ausschließen, dass es sich tatsächlich um ein Objekt handelt, das vom System benötigt und vielleicht nur durch den JDisc-Import umbenannt wurde.
Bevor wir zur "Brechstange" greifen und das Objekt vielleicht sogar in der Datenbank löschen, wäre es noch interessant zu wissen, über welche Beziehungen das Objekt verfügt. Ein Screenshot aus der Beziehungsübersicht des Objekts wäre hier hilfreich um auszuschließen, dass das Objekt über benötigte Abhängigkeiten verfügt.

Freundliche Grüße
Jens

Hallo frisbee23,

vielen Dank für deinen Hinweis und den Lösungsansatz. Das Verhalten ist unseren Entwicklern bereits bekannt und es gibt einen offiziellen Hotfix für dieses Verhalten.
Dieser ist in unserer Knowledge Base in folgendem Artikel zu finden: https://kb.i-doit.com/pages/viewpage.action?pageId=10223732

Lieben Gruß
JD

Hallo noch einmal,

unsere Entwickler haben sich das Thema noch einmal genau angesehen. Anscheinend ist dies die übliche Arbeitsweise der Indexierung in MySQL. Einen ständigen "Refresh" einzubauen würde die Performance merklich verringern. Die Empfehlung der Kollegen lautet daher, den Reindex der Suche zum Beispiel in einem Intervall von fünf Minuten, automatisch mit einem Aufruf des Controllers durch einen CronJob durchzuführen: https://kb.i-doit.com/display/de/Suche#Suche-Indexierung
Hierdurch sind gelöschte Daten maximal fünf Minuten nach dem Zeitpunkt, zu dem sie gelöscht wurden, auffindbar.

Lieben Gruß
jd

Hallo bvoigt,

mit der i-doit Version 1.8 ist das Recht "Erstellen" ergänzt worden. Da es sich bei der Kategorie "Kontaktzuweisung" im Prinzip um eine Multi-Value-Kategorie handelt, muss der Author-Gruppe die Berechtigung "Erstellen" in den Kategorien ergänzt werden. Ich empfehle hier die Rechtekonfiguration der Gruppe aufzurufen, das Recht zu überprüfen und in jedem Fall zu "überspeichern".

Freundliche Grüße aus Düsseldorf!

Hallo Quintillii,

damit die Softwarezuweisung über den CSV-Import möglich ist, muss das Software-Objekt vor der Zuweisung in i-doit existieren.
Hier kann das Objekt entweder zuvor mit derselben CSV-Datei angelegt werden oder auf ein bereits bestehendes Objekt zugegriffen werden.

In der CSV-Datei ist es notwendig, dass der Name der Software exakt dem Objekt-Titel in i-doit entspricht.
Wenn also Versionsnummern oder ähnliche Daten Teil des Software-Titels sind, müssen diese ebenfalls so in das Feld der CSV-Datei übertragen werden.

Beim Mapping ist nun für das Feld die Kategorie "Softwarezuweisung" und die Eigenschaft "Anwendung (Verbindung)" auszuwählen.

Die Variante kann nicht über den CSV-Import importiert werden. Diese Eigenschaft ist Teil der spezifischen Ordner-Kategorie "Anwendungen" des Software-Objekts.
Inhalte spezifischer Kategorien können generell nicht über den CSV-Import importiert werden.

Freundliche Grüße
jd

Hallo Bernhard,

anscheinend erfüllt der i-doit Server nicht die Systemvoraussetzungen für die Verwendung des VIVA-Moduls.
Hier ist es zwingend notwendig, dass die PHP-Einstellung "short_open_tag" aktiviert (on) ist (siehe: VIVA-Dokumentation Punkt "2.1 Systemvoraussetzungen")

Grüße
Jens