Domino 9 und frühere Versionen > ND6: Entwicklung

Zugriffsbeschränkung auf View

(1/3) > >>

jor:
Hallo zusammen,

die Möglichkeit Ansichten über die ACL zu schützen möchte ich hier auslassen, da es mir nicht flexibel genug ist (wechselnde Zugriffsberechtigung für Personen durch TEAM-Wechsel).
Ich stelle mir vor, dass ich im Queryopen der View ein Script hinterlege, das überprüft, ob aktueller User im Viewnamen steht, dann öffnen, wenn nicht wir dnoch ein Profildokument abgefragt, ob dort  der aktuelle Benutzer aufgeführt wird. Funzt auch soweit, aber... leider merkt sich Notes die letzte Ansicht (die Datenbank hat keinen Vorgabe Navi oder so, beim Öffnen der DB, weil zuviele Ansichten vorhanden) die benuzt wurde und nach dem Schliessen wird diese Datenbank nicht mehr geöffnet, da das Script immer noch zieht.
Ich habe auch versucht, bei unberechtigtem Zugriff eine andere Ansicht zu öffnen, geht auch, aber es bleibt immer noch der Reiter stehen, auf dem der Zugriffsversuch durchgeführt wurde, und dieser stört dann, da das Script wieder ausgeführt wird.

Hat jemand von euch sowas umgesetzt, oder kann mir ein Tipp geben?

Axel:

--- Zitat von: jor am 17.03.06 - 07:29:55 ---die Möglichkeit Ansichten über die ACL zu schützen möchte ich hier auslassen, da es mir nicht flexibel genug ist (wechselnde Zugriffsberechtigung für Personen durch TEAM-Wechsel).

--- Ende Zitat ---

Warum?

Ich würde das Ganze über Gruppen abwickeln. Einer Ansicht wird in der Zugriffsbeschränkung diese Gruppe zugewiesen. Nur Mitglieder dieser Gruppe, dürfen auf diese Ansicht zugreifen. Nur so bekommst du die Sache wasserdicht. Alles andere hat irgendwelche Seiteneffekte.


Axel

jor:
Hi Axel,

jep, so wie du es schreibst ist es vollkommen richtig. Die Lösung über Gruppen wollte ich nicht
so gerne umsetzen, weil die einzelnen Teammitglieder öfter wechseln. Dadurch hätten wir, die
Admins und ich ewig die Aufgabe die Gruppen zu pflegen. Ein Schreibzugriff
der User auf das DD möchten wir unter allen Umständen verhindern.

Aber auch nach weiterem Testen sieht es momentan so aus, als wenn wir uns die Gruppenpflege-
mütze aufsetzen müssen.  >:(

Gruß Volker

HH:
Warum die Gruppenpflegermütze selbst aufsetzen. Default im DD ist Autor. Damit kann der Standard-User nur bedingt in seinem Personendokument ändern. Über das Feld Administrators und die Rolle GroupModifier läßt sich steuern wer die Gruppe bearbeiten kann.

Hubert

Driri:
Hi,

evtl. eine Alternative, erfordert aber dann etwas Programmieraufwand :

In der Datenbank werden über Konfigdokumente die Teamzugehörigkeiten administriert. Für jedes Team wird eine Rolle in der ACL angelegt und den zugehörigen Teammitgliedern zugewiesen.

Das kann man über die NotesACL und NotesACLEntry abfackeln.

Problem : Die User müßten als Person in der ACL stehen.

Navigation

[0] Themen-Index

[#] Nächste Seite