Hallo @philipp-hörselmann Phil,

ja, damit klappt es nun wieder.
Vielen Dank für die schnelle Reaktion.

Gruß
Armin

Hallo,

dafür gibt es den Objekttyp Lizenz. Hier kann man das Ende-Datum eintragen.
Über den Menu-Punkt Benachrichtigungen kann man dann einstellen wann und welche Objekte beim Ablauf
von dem Lizenz-Datum eine Mail abschicken. Dazu muss natürlich per Cronjob auch das console Kommando
"notifications-send" ausgeführt werden.

Armin

Hallo zusammen,

hier mal keine Frage, sondern die Info zu einem kleinen Erfolgserlebnis.

Wir hatten das Problem, daß wir bei Kontakten nicht sehen konnten ob bzw. bei welchen Objekten diese in dem Feld "Eingekauft bei" unter "Buchhaltung" verlinkt waren.

Eine "rückwärtige" Ansicht war nur möglich, wenn der Kontakt zusätzlich auch bei den "Kontaktzuweisungen" der Objekte eingetragen war. Dies ist bei uns aber nicht (immer) der Fall.

Damit wir nun bei den Kontakten auch die "eingekauften Produkte" sehen, hat uns der variable Report und eine benutzerdefnierte Kategorie die Lösung gebracht.
Es wurde also in Report erstellt, der Objekte zeigt, die unter Buchhaltung bei "Eingekauft bei" die Objekt-ID des aktuellen Objektes haben.
Eine benutzerdefinierte Kategorie mit diesem Report als einzige Einstellung wurde nun bei den Kontakten (z.B. Organisationen) hinzugefügt.
Nun kann man bei den Kontakten die neue Kategorie (bei uns heisst sie "gekaufte Produkte") auswählen und man bekommt die gewollte Liste.

Gruß
Armin

Bei Ansicht einer Kategorie wie z.B. E-Mail Adressen, kann man die Seite Drucken oder als CSV laden. Wir würden das gerne auch bei den Gruppen-Mitgliedsschaften (spezielle Kategorie bei Person) haben. Ist das irgendwie möglich diese Liste als PDF/CSV zu laden?

Danke.
Armin

An welcher Stelle ist in Version 25 die Konfig-Option
Login -> Welcome message for login
hin?
Diese kann ich nicht finden.

@LFischer
Unsere Systeme sind in der Regel Standard-Debian.
Beim aktuellen Stable (11 bullseye) ist aber noch php 7.4 enthalten.

Ist damit ein Update von i-doit auf neuere Versionen ausgeschlossen?

Das neue Debian Stable, wenn es dann mal released ist, wird wohl php 8.2 enthalten. Also ist es, zumindest für i-doit, keine gute Idee auf Debian Standard zu setzen?

@Steffen-0
Ja, das geht auf jeden Fall. Es müssen dann die entsprechenen Objekttypen erstellt werden und ggf. einige benutzerdefinierte Kategorien genutzt werden. Es gibt aber auch Möglichkeiten vorhandene Typen zu nutzen, in dem z.B. Felder umbenannt werden.

Wir haben ein separates i-doit in der Personalabteilung als einfache digitale Personalakte im Einsatz. 90% der Objekttypen und Kategorien sind dann selbst für diesen Bedarf angelegt.

Hallo @StephanBuerger ,

also hast du die Bodentanks nicht als eigene Objekte angelegt, sondern als Output direkt am Patchfeld? Das habe ich mal ausprobiert und scheint eine mögliche Lösung, zumindest für diesen Punkt zu sein.

Ich habe auch mal versucht ein "allgemeines" Kabel, wie z.B. "Standard-Patch-Kabel" anzulegen und dieses dann mehrfach für Verbindungen zuzuweisen. Das geht bei manchen Objekten, aber nicht immer. Das Verhalten ist mir dadurch zu unsicher. Es scheint keine klare (dokumentierte) Regel zu geben.

Wenn ich aber die Kabel tatsächlich alle (automatisch) anlegen lasse und diese Kabel dann nach archiviert setze, scheint die Doku trotzdem normal zu sein. Auch über die Visualisierung wird alles gut angezeigt. Somit werden keine Lizenzen gezählt. Da ich keine wirkliche Doku der Kabel brauche und sie nur für die Verbindungen in i-doit benötigt werden, scheint mir das als Lösung auch möglich. Wäre natürlich blöd, wenn durch diese Info hier jetzt in der nächsten i-doit Version archivierte Kabel nicht mehr als Verbindung angzeigt werden

Unsere Dokumentation für Verbindungen von Netzwerkgeräten, Bodentanks, Patchfelder, Switches, etc. soll nun ins i-doit überführt werden.
Bei Tests ist uns klar geworden, daß wohl für jede Verbindung ein "Kabel" angelegt wird.

Für uns macht es kein Sinn für jeden Patchfeld-Port zum Bodentank ein "Kabel" zu haben. Das macht die Doku nicht nur aufwendiger, sondern irgendwie auch unübersichtlicher.
Außerdem führt das zu enorm viel zusätzlichen Objekten (=Lizenzen).

Ist dies wirklich nötig? Gibt es eine andere Variante die Verbindungen zwischen den Geräten und Ports, trotzdem mit Verkabelungsbrowser, zu dokumentieren ohne so viele Kabel (automatisch) zu haben?

Gruß
Armin Schindler

@stefanwinter
Das sollte über die Validierung kein Problem sein.
Schau mal hier: https://kb.i-doit.com/display/de/Validierung+und+Pflichtfelder

Armin

@tlt
Du kannst verschiedene Typen von Feldern anlegen, mit Text bestücken, etc.
Hier ist es beschrieben:
https://kb.i-doit.com/display/de/Benutzerdefinierte+Kategorien

Ich wüsste jetzt nicht was ich dir als Beispiel zeigen könnte.
Oder meinst du was bestimmtes?

Armin

Für solche Informationen, wenn sie nicht durch vorhandene Kategorien abgebildet werden, erstelle ich immer benutzerdefinierte Kategorien.

Ich versuche einen Überblick über alle Rechte von Usern und Gruppen zu bekommen.
Leider sehe ich bisher keine Möglichkeit eine "einfache Liste" zu erstellen.

Bei Usern/Gruppen gibt es nur die "vereinfachte" Darstellung. Da fehlen Details und man müsste das für jeden User, jede Gruppen einzeln aufrufen.

Über Administration und Rechtesystem bekomme ich zwar alle Details (hier stelle ich ja auch alles ein), aber auch hier muss man durch alle Punkte (die einzelnen Rechte-Kategorien, sowie User und Gruppen) einzeln durchgehen.

Unsere Rechte sind eigentlich nur auf Gruppen-Basis vergeben. Somit wäre eine Liste der
Gruppen (die im Rechtesystem eingetragen sind) mit den vergebenen Rechten ideal.

Gibt es eine Möglichkeit eine komplette Liste zu erzeugen?
Die API bietet hier auch keinen Zugriff, oder?

Oder muss ich das direkt aus der DB holen?

Gruß
Armin