@MHaupt
Hallo Markus,

wir Dokumentieren in i-doit unser Berechtigungsmanagement für ein KIS.

Mit benutzerdefinierten Kategorien lässt sich da viel erreichen.
Anfangs hätte uns der Tipp viel Zeit erspart dass solche Kategorien variable Reports beinhalten können.
So kann (vereinfacht gesagt) in den Personen-Objekten eine benutzerdefinierte Berechtigungs-Kategorie erstellt werden worin u.a. Rollen ausgewählt werden können.
Diese Rollen wiederum sollten eigene benutzerdefinierte Objekttypen sein.
In diesem Objekttyp Rolle könnte eine Kategorie "Mitglieder" erstellt werden die einen Variablen Report beinhaltet.
Der Report muss dann z.B. wie folgt aussehen:

Hoffentlich konnte ich etwas helfen.

@StefanP74 Haha wunderbar! Guten Durst bei der Strafe

@StefanP74 Beim Attribut Schlüssel (Report): Im Feld Zusatz muss hier die ID vom Report stehen, nicht der Name. Ansonsten siehts schon richtig aus würde ich sagen.

@StefanP74
Moin, der einzig mir bekannte Weg geht über rückwärtige Kategorien mit variablen Reports.
Ist nicht schön, lässt sich nur von einer Seite editieren.
Klingt bei @chuck tatsächlich nach dem gleichen Thema.

Hatte ich hier mal geschrieben, vlt. gibt's was besseres mittlerweile bzw. eine bessere Anleitung https://community.i-doit.com/topic/4682/rückwärtige-kategorie-erstellen?_=1697556089610

@fabilbng1
Hallo, ich weiß gerade nicht ob es da in der Dokumentation etwas zu gibt - jedoch nutzen wir bereits seit knapp 2 Jahren rückwärtige Kategorien durch Reports.

Beispiel zugeordnete WLAN Bridges an Medizingeräten.

Report:

Feld in der benutzerdefinierten Kategorie:

@lfischer Alles klar, vielen Dank! Dem habe ich nichts hinzuzufügen. Dann kann das Thema geschlossen werden

Habe die Kategorie-Einträge in den ~70 Switchen mit einem Kollegen nun doch manuell gelöscht. Search Index erneuert:

Das einzige was mich wundert, ist dass hier 300.000 Einträge sind, und vorher ~135.000. Aber vielleicht war das ja auch nur der Part bis zum Error

Die Suche scheint wieder schneller zu funktionieren. Die anderen Fragen dürfen Sie natürlich gerne trotzdem beantworten @LFischer

@lfischer Hallo, erstmal vielen Dank für die ausführliche Antwort.

Ja, das hast du richtig gesehen! Habe den Netzwerkimport gestern danach noch einmal manuell ausgeführt. Nach weiterer anpassung des memory_limit Wertes(4G) zeigte sich dieser Suchindex-Count:

Habe die Kategorie JDISC Custom-Attributes danach wieder aus dem Netzwerk-Import entfernt. Nachdem ich den Netzwerk-Import eben manuell ausgeführt habe, hat sich der Suchindex nicht verändert, so wie es sein soll.
Also 1. Problem(BUG): Beim JDISC-Import der JDISC Custom Attributes werden die 270 Datensätze bei Switchen jedes mal zusätzlich importiert, anstatt nur jeweils die neu gescannten Datensätze! (Bei mir waren nach ein paar Tagen je Switch ~1200 Einträge in der JDISC Custom Attributes Kategorie, welche Standardmäßig natürlich auch für die Suche indiziert wird.

Die Idee mit der Kategorie-Whitelist für den such-index ist sicher eine Idee Wert, aber natürlich nur Pfusch am Werk, bzw. es löst das Problem nur in vorm eines übergeklebten Tape-Klebebands. (Am Rande gesagt als Feature-Feedback wäre eine Blacklist hier in meinem Fall deutlich sinnvoller. Für das manuelle Eintragen habe ich keine Zeit - vielleicht gibts ansonsten eine Möglichkeit alle "aktiven" Kategorie-Bezeichnungen zu exportieren?)

"Dann müsste ich die Daten aus den Switchen nicht rauslöschen" - da möchte ich wiedersprechen. Es sind ja trotzdem VIEL zu viele Kategorieeinträge, (die mit der zeit veralten) - und wenn wir schon beim Thema "weniger Datenmüll" sind, ist es natürlich essentiell wichtig diese Daten wieder zu löschen.
Frage: Gibt es eine Möglichkeit alle Einträge der Kategorie JDISC Custom Attributes zu löschen? Vielleicht auf Datenbank-Ebene? (Beim search-index-Befehl wird auf die Tabelle isys_catg_jdisc_ca_list Bezug genommen)

Freue mich über weitere Hilfe/Antworten.

Vielleicht sind noch ein paar Zahlen interessant:
Kategorie : Einträge
C__CATG__NETWORK_PORT: 50.000
C__CATG__GLOBAL: 80.000
C__CATG__MODEL: 32.000
C__CATG__DRIVE: 52.000
C__CATG__JDISC_CA: 434.000
C__CATG__IDENTIFIER: 27.000

Betroffen sind circa 70 Switche, und ich würde nur ungern jeden einzeln öffnen und die Daten wieder rauslöschen. Trotzdem irgendwie komisch, dass aus 90 Revisionen der Running-Config, Startup-Config und Show-Version circa 1200 Kategorie-Einträge je Switch resultiert. Sieht fast so aus als würden diese täglich importiert werden (nicht nur die neuen)

Hier noch ein Bild aus JDISC:

@lfischer Hallo! Das waren super Tipps, ganz vielen Dank!

Also vorher:

Und nachher:

-> Beim ausführen dauerte der Punkt "JDISC Custom Attributes" Ewigkeiten. Dabei fiel mir ein, dass ich so etwas letztens einfach mal angehakt hatte im jdisc-import-Profil. Nämlich im Netzwerk-Profil:

Bei einem Beispiel-Switch sind in der Kategorie Custom Attributes 1160 Einträge mit ner Menge Text(Running Configs etc) - kein wunder dass es so langsam ist/crashed. Damit habe ich beim setzen des Hakens natürlich nicht gerechnet.

Haben Sie einen Tipp wie ich das wieder bereinigen kann? Einfach den haken entfernen wird ja wahrscheinlich nicht reichen. Kann ich da eine Tabelle leeren in sql?

Vielen Dank schonmal, nun weiß ich zumindest woran es liegt.

@chrisl Moin, ich glaube du bringst da paar Sachen durcheinander.

Das SAP-System dass ihr erstellt habt ist ein Objekttyp, während Software-Assignment eine Kategorie ist.

Wenn SAP-System eine Software ist, sollte diese auch als Application-Objekt angelegt werden. (Dann erscheint diese im Software-Assignment Objekt-Browser).

Vielleicht hilft euch das ja schon

Hallo,

in der Hoffnung dass hier jemand eine Idee hat erläutere ich mal mein Problem:
Die i-doit-jobs Datei wird täglich früh morgens per Cronjob ausgeführt - funktioniert.
Manuell hinzugefügt hatte ich den LDAP-Sync Befehl - funktioniert.

Neuerdings bemerkten wir öfters dass der LDAP-Sync nicht automatisch gelaufen ist.
Nach manuellem ausführen der i-doit-jobs Datei kam beim Befehl search-index beim Punkt "C__CATG__ADDRESS" der Fehler:

Finished reading 13 rows

Start mapping 13 rows to 117 documents for "Anschrift" (C__CATG__ADDRESS)

50 of 117 documents were skipped!

Start inserting documents

Finished inserting documents!


Start inserting documents

Finished inserting documents!

PHP Fatal error:  Allowed memory size of 2147483648 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/src/classes/components/isys_component_database_mysqli.class.php on line 275

Wie in der Fehlermeldung ggf. ersichtlich ist, habe ich durch einen Tipp des i-doit-Supports den Wert memory_limit in der Datei /etc/php/7.3/mods-available/i-doit.ini bereits von 128M auf mittlerweile 2G geändert. (https://kb.i-doit.com/pages/viewpage.action?pageId=10223831#DebianGNU/Linux-PHP).

Nach dieser Änderung konnte ich den search-index-Befehl jedes mal ohne Fehler ausführen - am nächsten Morgen kam aber wieder der gleiche Fehler. Und wenn eine Erhöhung um das 16fache nicht reicht, wirkt es auf mich nach keinem normalen Verhalten. Womöglich besteht dies seit dem 1.17.1 Update - da bin ich mir nicht ganz sicher.

Hat jemand eine Idee woran es liegen könnte, was ich prüfen könnte?
Hatte diesen Fehler vorher nie

System-Infos;
i-doit 1.17.1
Linux Debian VM

@oya-erdayı Falls es noch wichtig ist, hier geht es sicherlich um den Unterschied der Felder Objekt-Browser und Objekt-Beziehung.

@creiss Interessant, dann probiere ich das mal aus mit 365 Tagen oder so.
Vielleicht wird das Feature Feedback ja priorisiert wenn sich mehr Leute melden die sich dies wünschen.

Geschrieben hatte ich dem Support auszugsweise folgendes:
"Momentan habe ich eingestellt dass die Logbuch Einträge archiviert werden, die älter als 90 Tage sind. Mittlerweile wird klar dass dies Einträge archiviert, die durchaus interessant/wichtig sind. Gerade wenn ein Dokumentationsfehler gefunden wird, ist interessant wer dies zB. vor 6 Monaten Eingetragen hat. Und die Wiederherstellungsfunktion scheint auch nicht für einzelne Objekte zu funktionieren

Also beispielsweise habe ich öfters gesehen dass das Logbuch von manchen Objekten nur 2-3 Einträge innerhalb der letzten 90 Tage haben, während andere Objekte ~50 oder noch viel mehr Einträge durch den JDISC-Import haben(zB. tägliche aktualisierung des lokalen Speicherstands)

Würde es hier nicht Sinn machen das Archivieren genauer einstellen zu können?
Anhand folgender Eigenschaften:

1. Von wem kam diese Änderung? (Manuelle Änderungen sind wichtiger als Änderungen durch JDISC)
2. Wie viele Änderungen sind vorhanden? (zB. immer die ältesten löschen so dass maximal 50 je Objekt enthalten sind)
3. In welcher Kategorie wurde etwas geändert? (Habe schon oft gesehen dass jeden Tag der Name des lokalen Datenträgers neu gesetzt wird, diese Info ist somit dupliziert und unnötig)."

@creiss Ja Okay, noch ein guter Tipp. Allerdings geht es uns wiegesagt oft um ältere Einträge, und ich habe die Sorge das i-doit langsam wird/zu viel Speicher benötigt, wenn ich die Archivierung deaktiviere.
Oder haben Sie da andere Erfahrungen gemacht?

@creiss Vielen Dank für den Tipp mit dem Event-Addon, da hatte ich nicht dran gedacht. Klingt in der Tat nach größerem Konfig-Aufwand. Ich denke trotzdem es bei Zeit damit zu versuchen.

Das Problem beim Logbuch ist, dass JDISC dies bei Hardware vollspamt, weshalb ich es auf 90 Tage eingestellt habe. Die nachzuvollziehenden Änderungen liegen teilweise aber ein Jahr oder länger zurück.

Dazu hatte ich dem i-doit Support auch schonmal ein Feature-Feedback erstellt. (Dass der Zeitpunkt des Logbuch Archivierens weiter eingeschränkt werden kann, auf Benutzer-Ebene und ggf. Kategorie Ebene).

Hallo,

mittels einer benutzerdefinierten Multi-Value (Listen-) Kategorie bilden wir zur Übersicht / Nachverfolgung jegliche Berechtigungsänderungen von Mitarbeitern ab(Zu einer Software).

Kürzlich kam dabei die Frage auf, ob hier nicht auch das Erstell- sowie Änderungsdatum NUR FÜR DEN JEWEILIGEN KATEGORIE-EINTRAG eingebunden werden kann, so wie es für ein ganzes Objekt bereits in der Allgemein-Kategorie vorhanden ist:

Dies habe ich beim Support angefragt, was schnell verneint wurde.

Dazu wollte ich in diesem Forum einmal Fragen ob bereits jemand vor diesem Problem stand, wie es gelöst wurde - bzw. ob mir jemand sagen kann wie man es Lösen könnte.

Wenn dies nur mit einer selbst-programmierten Kategorie funktioniert, würde mich interessieren worauf man hier achten sollte - gerade was künftige i-doit Updates angeht. Nicht dass ein einfacher Fehler durch Unwissenheit irgendwann zu wichtigem Datenverlust führt.

Vielen Dank schonmal für jede Hilfe!