Domino 9 und frühere Versionen > Entwicklung

ACL Workaround

(1/3) > >>

TMC:
Ich habe hier eine DB in R5, bei der haben alle User Editor-Rechte - dies soll auch so aus anderen Gründen nicht geändert werden (dies zu erklären würde jetzt wohl zu weit führen).

Anyway, in dieser DB erzeuge ich eine neue Maske. Ich möchte es nur Usern, die die Rolle [ABC] haben, gestatten, die Dokumente mit dieser Maske (also FIELD = "MASKE ABC") zu bearbeiten.
Lesen darf jeder, somit fallen Leserfelder aus.

Klar, jetzt könnte ich in den Events 'PostOpen' und 'Querymodechange' entsprechend die Rolle abfragen und dann den Edit-Modus verbieten oder nicht.

Dies erscheint mir etwas umständlich. Gibt es da noch eine einfachere Möglichkeit, Usern, die eigentlich DB-global Rechte für das Ändern von Dokumenten haben, nicht die Möglichkeit zu geben, Doks mit Maske XYZ zu ändern?
Oder bleibt mir hier nur ein 'PostOpen' und 'Querymodechange' übrig?

Im Prinzip fehlt mir ein Feld vom Typ "Editor" (nicht: Autor). Aber dies ist ja (verständlicherweise) gegen jede Logik der ACL.

Glombi:
In so einem Fall verwende ich immer kontrollierte Abschnitte. Die ziehe ich dann über alle Felder der Maske.
Man muss aber bedenken, dass die Dokumente von außen geändert werden können. Aber das ist ja auch mit dem Verbieten des Bearbeitenmodus so.
Und die wenigsten User wissen, wie man so ein Dokument manipuliert.

Andreas

Glombi:
Was auch noch ginge, wären 2 Masken und dann mit Maskenformeln in den Ansichten zu arbeiten.
Eine Maske hat nur berechnete Felder und diese Maske wird dann in den Ansichtsformeln für die Maskenformel herangezogen, falls der User nicht die Rolle hat.
Das ist aber wesentlich aufwändiger als einen Abschnitt zu erstellen. Es bietet sich aber an, wenn man bestimmte Infos gar nicht oder anders anzeigen will.

TMC:
Danke für Deine Tipps/Erfahrungen, Andreas.

Hmm, mal zusammenfassend haben wir schonmal 3 Alternativen
a) Sperrung der Rollen über QuerySave und PostOpen
b) kontrollierte Abschnitte
c) mit 2 Masken arbeiten

Zwischenfazit für mich:
Da ist es wohl hier am einfachsten und schnellsten umzusetzen, wenn man mit QuerySave und PostOpen agiert.

QuerySave / PostOpen kann imho einen Nachteil haben, wenn man dort schon umfangreiche andere Codes platziert hat. Aber bei sauber strukturierten Codes sollte dies kein Problem darstellen, diese Abfragen zu integrieren.
100% traue ich aber QuerySave / PostOpen aber nicht. Man muss da wirklich strikt auch das uidoc auf Nothing setzen. Wehe es ist noch ein anderes Dok im Fokus, dann kann ein User u.U. doch in den Edit-Modus wechseln.

koehlerbv:

--- Zitat ---100% traue ich aber QuerySave / PostOpen aber nicht. Man muss da wirklich strikt auch das uidoc auf Nothing setzen. Wehe es ist noch ein anderes Dok im Fokus, dann kann ein User u.U. doch in den Edit-Modus wechseln
--- Ende Zitat ---
Äh, QueryModeChange und PostOpen, oder ? Und damit sollte es keine Probleme geben. Focuswechsel - was soll da passieren ? Die Events wirken auf das betreffende Dokument, egal, was der User zwischendurch treibt.

Ich habe noch eine weitere Variante im Angebot (auch wenn ich zusätzlich mit den Events oder Teilmasken deale, jedoch nicht mir kontrollierten Abschnitten - ist mir zu suspekt oder zu aufwändig):
Doppelte Felder. Eines zum Editieren, eines Computed For Display. Dazu ein Computed For Display Field, welches dir Rolle(n) auswertet und eine Einstellung trifft für die Hide-whens: Darf User oder darf User nicht.

Es kommt hier immer auf den Zusammenhang und dem damit verbundenen Aufwand an.

Bernhard

Navigation

[0] Themen-Index

[#] Nächste Seite