Prüfen ob ein Benutzer namentlich (nicht in Gruppen) in der ACL aufgeführt ist

[sudsaat]

Hallo community,

ich hätte da mal wieder eine kleine Frage. Ist es möglich via @Functions in einer Datenbank zu prüfen, ob ein Benutzer namentlich in der ACL (also nicht als Mitglied einer Gruppe oder über den default-Zugriff) aufgeführt ist?

Ich benötige dieses Feature für eine Hide-When Formel in Ansichten und bräuchte diese Information, um folgende Benutzer zu unterscheiden:
- Standard-Benutzer (Wird über den default-Zugriff gelöst)
- Benutzer mit speziellen Berechtigungen (ist namentlich in der ACL aufgeführt)

Gibt es da eine Lösung? In der Hilfe finde ich nur zu Script ein paar snippets, aber keine Pendant in @Functions?

Vielen Dank im Voraus.

Grüße Thomas

[koehlerbv]

Das ist mit @Functions nicht möglich.

Bernhard

[Peter Klett]

Du vergibst Zugriffsrechte über Default?

Default sollte m.E. immer keinen Zugriff haben. Jeder, der auf den Server zugreifen kann, kann dann auch auf die Datenbank zugreifen, außer, wenn Du ihn explizit in die ACL ohne Zugriff einträgst.

Auch Sonderrechte würde ich generell nicht namentlich vergeben, da pflegst Du Dir einen Wolf, sondern nur über Gruppen. Über das ACL-Konzept würde ich daher noch einmal nachdenken.

Um aufgrund von ACL-Einträgen Verbergeformeln zu steuern, könntest Du Rollen/Funktionen verwenden. Die kannst Du mit @Userroles auf dem Server oder lokal bei konsistenter ACL auslesen.

[sudsaat]

Hallo Bernhard,

ok, das deckt sich leider mit meiner Recherche

Hallo Peter,

ja, der Default erhält sogar "Editoren-Zugriff" in dieser speziellen Datenbank. Ist eine komplexe Steuerung auf Dokumentenebene dahinter, die einen dynamischen Bezug zwischen einer "normalen" Schlüsselliste, der ACL-Rollen und dem Dokument herstellt, daher ist auf Dokumentenebene sicher gestellt, dass keine ungewollten Informationen enigesehen werden können.

Wie du richtig schreibst, erhält jeder der Zugriff auf den Server hat auch Zugriff auf diese Datenbank (das ist so gewollt). Ist wie gesagt ein Spezialfall (generell gebe ich dir recht, dem Default immer "No-Access" zu geben), aber durch die Struktur des Unternehmens und der Masse an Gruppen/Personen ist die Pflege mit dem besagten Zugriffsmodell sogar minimiert und würde im Umkehrschluss einen höheren Pflegeaufwand bedeuten (um das Konzept genauer zu beschreiben, bräuchte ich hier bestimmt 3 Seiten :-)

Aber kurz zusammengefasst (auch zu deiner Anregung die Rollen/Funktionen zu verwenden):
Das Notes-Zugriffsmodell reicht in unserem Falle schlichtweg nicht aus unsere Anforderungen abzudecken, da es keine Hierarchie innerhalb des Rollen-Konzeptes gibt (daher wurde bereits der Bezug zwischen ACL und Schlüsselliste hergestellt). Rollen verwenden wir bereits über 50, aber wie gesagt reicht das Rollenkonzept leider in diesem Falle nicht aus

Zur Lösung werde ich die Buttons von der Ansicht in das Dokument verschieben, dort gibt es einen Mechanismus, um diese Anforderung zu lösen - war nur eine Idee 2 Buttons ebenfalls in Ansichten zur Verfügung zu stellen.

Grüße und Danke für euer Feedback
Thomas

[Peter Klett]

Du weißt, dass man auch in einem geschlossenen Dokument die Inhalte sehen kann (Felderliste)?

Wenn in der Datenbank personenbezogene Daten enthalten sind, möchte ich nicht Euer Datenschutzbeauftragter sein.

Was spricht gegen eine Gruppe "AllUsers" und die bekommt die Rechte? Na ja, anderes Thema ...

Du könntest Dir im QueryOpen der Datenbank per Script die Informationen aus der ACL holen und in ein persönliches Profildokument schreiben, von dort kannst Du sie per Formel auslesen.

[sudsaat]

Hi Peter,

Du weißt, dass man auch in einem geschlossenen Dokument die Inhalte sehen kann (Felderliste)?

Jep, daher sind die Dokumente auch in Ansichten nicht sichtbar. Wie gesagt ist das Konzept sehr komplex, vereinfacht wird erst einmal unterschieden:
- Welche Ansichten sind für Benutzer sichtbar
- Welche Dokumente sind für Benutzer sichtbar
- Welche Felder sind für Benutzer sichtbar/pflegbar

..dahinter hängen dann Prozesse die mit einem ERP-System kommunizieren wie Teilfreigabe, Mehrfachfreigaben, Rückfragen etc. die sich auf die obige Sichtbarkeit auswirken (wie gesagt, nur vereinfacht beschrieben)

Die Datenbank wurde bereits geprüft und ist in einem Konzern der weltweit agiert im Einsatz (da gelten leider noch ganz andere Restriktionen als lediglich der Datenschutz, das geht es auch um Signaturen und Signaturprüfungen innerhalb der Konzern-Kommunikation die extern durchgeführt werden, etc. etc. ist ein riesen Rattenschwanz). Aber kurzum, das Sicherheits-Konzept macht mir keine Sorgen

Die Idee mit dem persönlichen Profildokument gefällt mir, die existieren bereits in der DB um anderen Anforderungen zu erfüllen. Werde es mir mal anschauen, vielenk Dank.

Grüße Thomas