@Danny:

…Damit hättest du dann nur noch das Syntaxproblem!

Und die Usability

@Danny:

• Mir ist bist jetzt gar nicht aufgefallen, dass nur "Textfelder" von Benutzerdefinierte Kategorien "durchsucht" werden, die Dialogfelder nicht
• Sehr schön wäre, wenn man den Status unter "Allgemein" erweiteren könnte.

jap genau, allgemein wäre sehr schön

wie gesagt, wir nutzen wohl weiterhin einen Raum für defekt, einen Raum für in Reparatur usw. Damit kann man sich eine Liste anzeigen lassen (über die Standorte Baumansicht), und wenn ein Gerät z.B. wieder funktionstüchtig ist, kann man es leicht wieder woanders einsortieren, und es wird optimal im Logbuch vermerkt

Danke für Deine Antwort!

Manuelle Eintragungen im Logbuch halte ich nicht für sinnvoll. Es ist unwahrscheinlich dass sich die IT Mitarbeiter an eine gemeinsame Syntax halten, außerdem wird das Logbuch bei der Suche nicht mit durchsucht.

Die Benutzerdefinierte Kategorie wäre denkbar, scheitert aber auch an der Durchsuchbarkeit

Hallo zusammen,

wir haben einen Großteil unseres Inventars inzwischen im Idoit eingetragen. Allerdings häufen sich die Fragen, wie man mit Objekten umgeht, die quasi einen besonderen Status haben. Wie könnte man z.B. vermerken, dass ein Gerät defekt ist, es bereits zur Reparatur gegeben ist (es also physikalisch nicht vorhanden ist, es aber dennoch zum Inventar gehört), oder z.B. gestohlen wurde?

Es soll natürlich auch durchsuchbar und auflistbar sein, welche Geräte nun im Normalbetrieb sind, welche defekt sind, usw…

Unsere "Notlösung" sieht z.Z. so aus, dass wir für "defekt" und "in Reparatur" einen separaten Raum angelegt haben, und diesen dann als Standort des betroffenen Objekts angegeben haben.

Sind normalerweise die Attribute "Einsatzzweck" oder "Kategorie" dafür zu gebrauchen? Einen tiefergehenden Nutzung dieser Flags habe ich aber noch nicht entdeckt...

Wir handhabt Ihr diese Fälle?

Hallo,

nach meinen Beobachtungen ist das Löschen eines Eintrags aus der Kategorie "Kontakt" nur bedingt möglich.

Situation: Ein Objekt hat einen Kontakt (primär). Dieser Kontakt wird erwartungsgemäß sowohl in der Kategorie Kontakt, als auch in der Übersichtsseite als auch auf der Übersichtsseite in dem grauen Kasten mit dem Bar Code angezeigt.

Lösche ich nun den primären Kontakt, wird er sowohl in der Kategorie Kontakt als auch auf der Übersichtsseite nicht mehr angezeigt. Auch über die Suche ist diese Zuordnung zwischen Kontakt und Objekt nicht mehr auffindbar. Im grauen Kasten neben dem Barcode steht der Kontakt aber weiterhin drin.

Unschöner Workaround: Der Kontakt muss vor dem Löschen als nicht mehr Primär markiert werden (roter Button). Das ist aber ziemlich nervig und führt zu Mehrarbeit und Verwirrung bei den CMDB Benutzern.

Kann das jemand bestätigen?

siehe http://www.i-doit.org/forum/index.php/topic,1482.0.html

kann das zumindest jemand bestätigen?

Hallo,

gibt es hier Aussicht auf eine Implementierung?

Gruß, Clemens

Hallo,

Wenn ich nach einem Kontakt suche, und es wird etwas gefunden, dann führt mich der Link in der Spalte "Objekt" nicht, wie man praktischerweise erwarten würde, zu dem Objekt, sondern zu den Eigenschaften des Kontaktes. Ist das so beabsichtigt?

Gruß, Clemens

Beim Erzeugen eines Client Objekts aus einem Template werden die Eintragungen für Storage/Gerät nicht übernommen. Es wird lediglich ein Eintrag erzeugt ohne Inhalt.