Hallo @Michael-Huhn, das scheint schon der korrekte Wert zu sein. Sowohl im UI als auch in der Datenbank. MariaDB [idoit_system]> select * from isys_settings where isys_settings__key = 'api.authenticated-users-only'\G *************************** 1. row *************************** isys_settings__key: api.authenticated-users-only isys_settings__value: 0 isys_settings__isys_mandator__id: 1 1 row in set (0.000 sec) Hast du noch eine Idee?

@UVB_Michael also wenn bei dir das Berschreibungsfeld nicht dargestellt wird: [image: 1751004655219-c40fc289-f034-4ebe-896c-1ed882960a4b-image.png] dann prüf in der Verwaltung die Attribute Einstellungen: [image: 1751004691179-c75fe730-b50b-4c16-9f52-bc2242d7f1de-image.png]

Hi nochmal @StefanP74 du kannst grundsätzlich - egal mit welchen Rechten - nicht von dort aus archivieren oder löschen. Das geht nur über die Listenansicht der Objekte. Alternativ kannst du mittlerweile mit dem Flows Add-on zusätzliche Buttons konfigurieren, die das aus dem Objekt heraus ermöglichen. Liebe Grüße Christian

Hallo @Michael-Huhn , ganz so einfach ist es dann doch nicht. Ja, ich möchte zur Dokumentenerstellung einen Report nutzen, der alle Objekte unterhalb eines physischen Standorts gefiltert auflistet. Dabei möchte ich auch das komplette Objekt haben, da ich nicht nur den Namen, sondern auch weitere Objektinformationen auslesen möchte. Aber mein i-doit-Standort, der als Basis dient hat noch weitere i-doit-Unterstandorte (Räume, Etagen usw.) unterhalb sich die interessant Objekte befinden. Die werden aber nicht in den "Räumlich zugeordneten Objekten" im obersten Standort angezeigt - was so auch korrekt ist. Es müsste so ähnlich sein wie im Screenshot, dann kann der Report ja zu einem variablen Report werden, aber es müsste eben die Eingabe des Feldplatzhalters möglich sein, wenn ich unterhalb von auswähle. Manuell kann ich es in einem SQL-Report dann ja so umsetzen, aber das macht bei der Pflege ja mehr Arbeit. Danke. Mathias

@LFischer Vielen Dank. Ich gebe es so dann weiter. Es sind nämlich extrem anspruchsvolle (Architekten-Risse), die viel anzeigen müssen. Also: PNG

Hallo @LFischer perfekt LG Stefan

Hallo @LFischer das ist eine sehr gute Nachricht LG Stefan

Servus @robbyhuebner Mach ich auch so. Gebäude --> Etage --> Raum --> Arbeitsplatz --> Clients (das ganze Zeug) Der logische Standort des Arbeitsplatzes ist der Mitarbeiter bzw. Gruppen. Warum? Der Arbeitsplatz ändert sich faktisch nie. Bei einem möglichen Umzug zieht der gesamte Arbeitsplatz mit allem drum und dran in zB. einen anderen Raum um. Zu ändern sind dann nur die Netzwerkanschlüsse, welche bei mir im Raum selbst hinterlegt sind. Ändert sich der Mitarbeiter, ändert sich nur der logische Standort. Ich sehe bei mir seit Jahren keinen Nachteil, ganz im Gegenteil. Übersichtlich, logisch und ratz fatz geändert. LG Stefan

Hallo @aziller ich glaube das Problem hierbei ist, dass das "Objekt" als solches nicht aktualisiert wird. Das einzige, was aktualisiert wird sind dessen Kategorie-Daten (z.B. die "Allgemein" Kategorie). Die Option "Speichern" für den Bezug "Objekt" tut tatsächlich nichts und müsste eigentlich entfernt werden... Das habe ich bereits aufgenommen. Probier es besser mit dem Bezug "Kategorie" Viele Grüße Leo

@StefanP74 wir haben einen Bug Report der dieses Titel trägt: "JDisc import can not overwrite category JDisc Device Information and create multi-value entries in a single-value category" Bisher ist dieser nicht gelöst und muss noch bearbeitet werden. Ich verlinke deinen Beitrag hier im Ticket.

... und das erfreute mich ganz besonders

@sargon Das gleiche Problem habe ich auch - es bleibt nur EINE Zuordnung übrig, wenn man aus so einem Template ein neues Objekt anlegt. Das passiert in der Demoinstanz auch. https://demo.i-doit.com/?viewMode=1002&tvMode=1006&objID=5457&catgID=50

Hi, Siehe auch https://kb.i-doit.com/de/benutzerauthentifizierung-und-verwaltung/ldap-verzeichnis/index.html ich habe in der Konfigurationsdatei: disabledUsersBehaviour=disable_login deletedUsersBehaviour=archive Deaktivierte User werden bei uns erst nach X Wochen gelöscht. Damit bleibt Zeit, das Equipment bei diesen Usern zu verwalten. User mit disable_login werden aktuell manuell auf "Außer Betrieb" gestellt. Wir planen aber, dass zu automatisieren. Grüße Leo

@Michael-Huhn Gibt es zu diesem Thema Neuerungen? Ich finde leider auf Anhieb keine Möglichkeiten den automatischen Mail Versand zu konfigurieren.

Moin, der Fehler war auf ein Berechtigungsfehler vom Verzeichnis /etc/ssl zurück zu führen. Ein ldapsearch mit sudo -u www-data brachte den Fehler ans Licht. Gruß Jens

@Michael-Huhn ja so etwas dachte ich mir schon. Deutsche Sprache ist es ja nun auch. Wir lagen ein paar Jährchen zurück... Eig. sollte es verstärkt mit Zammad eingesetzt werden. Denke wir werden dann i-doit entgültig einstampfen. Macht so alles keinen Sinn.

Hallo @aguenther der Bug wurde mit i-doit 32 gelöst. Wenn das Problem auch in späteren Versionen noch besteht müsste unser Support darüber bescheid wissen Könntest du dazu unter https://help.i-doit.com nachfragen? Viele Grüße Leo

Hallo @LFischer vielen Dank für den Tipp mit den Hotfixes. Hotfix "Add support for new JDisc GraphQL Schema (ID-11256)" installiert und die Daten können wieder abgerufen werden. LG Andi

Hi, inzwischen gab es Rückmeldung vom Support. Es gibt wohl aktuell einen Bug (in Version 33 und auch in 34 weil schon in Codefreezphase), das die Default Rechte der Author Gruppe nicht korrekt funktionieren, aber korrekt angezeigt werden. Mit einem einfachen Überspeichern lässt sich das Problem lösen. Damit Thema erledigt.