Leserfelder und Autorenfelder -> wer hat Lesezugriff?

[Andreas Bauer]

Hallo,

ich habe die Suche bemührt und auch den Best Practices Artikel zu ACL-Zugriff gelesen, bin aber nicht weitergekommen.

Ich habe hier eine DB: Prinzipiell sollen per Default alle User Doks lesen dürfen und nur der Dok-Ersteller sein eigenes Dok ändern.
Nun möchte ich aber optional "Weitere Autoren" zulassen, und außerdem optional den Lesezugriff einschränken.

Gedacht hab ich mir folgendes:
 - Alle User bekommen in der ACL Autorenrechte
 - 1 Feld, berechnet beim Anlegen, "CreatedBy", Typ: Autor, Formel: @Username
 - 1 Feld, berechnet beim Anlegen, "ReadAll", Typ: Leser, Formel: "[ReadAll]"
 - 1 Feld, Radiobutton, "LesenEinschraenken" ja|1 /nein|0
 - 1 Feld, editierbar, "Leser", Typ: Leser (wird verborgen, wenn LesenEinschraenken = "0")

Klappt das so überhaupt?

Bsp.: Ein User erstellt ein Dokument, setzt den Radiobutton auf "LesenEinschraenken = NEIN", und speichert das Dokument.
Nun gibt es im Dokument ja das Lesefeld "ReadAll" (Inhalt: [ReadAll]). Ich will aber, dass nun alle Autoren Lesezugriff auf das Dokument haben. Nur wenn ich den Radiobutton auf LesenEinschraenken = JA setze, sollen die Lesefelder ziehen.

Ich hoffe, mich verständlich ausgedrückt zu haben.

Gruß,
Andreas

[Glombi]

Das Lesefeld würde ich standardmäßig leer lassen.
Die Rolle [ReadAll] nur dann hinzufügen, falls der Lesezugriff eingeschränkt werden soll.

Dazu machst Du ein Feld
InputReaders - Bearbeitbar, Mehrfachwerte, Typ Namen

und ein Feld
Readers - Berechnet, Mehrfachwerte, Typ Leser mit der Formel
@If(InputReaders != "";InputReaders : "[ReadAll]";"")

Noch was: Wenn ein User im Autorenfeld steht, darf er das Dokument AUCH lesen, insb. auch dann, wenn er nicht im Leserfeld steht.

Andreas

[Andreas Bauer]

Vielen Dank, Andreas.

Ich denke nun hab ich das Prinzip verstanden und werde es so (bzw. so ähnlich) umsetzen.

Kann man grundsätzlich sagen: "wenn ein Leserfeld zwar vorhanden, aber leer ist, dann wird es ignoriert im Hinblick auf den Lesezugriff" ?
Ich denke ja, zumindest so hab ich das jetzt verstanden.

Noch einen schönen Abend.

Andreas

[koehlerbv]

So ist es, und Authors überstimmt Readers.

Bernhard

[Glombi]

Genau, wenn ein Lesefeld leer ist, wird es ignoriert.

Wenn es ein Lesefeld gibt, das nicht leer ist, dürfen folgende User das Dokument lesen:
- die namentlich bzw. durch Wildcard-, Rollen- oder Gruppenzugehörigkeit im Lesefeld stehen
- die namentlich bzw. durch Wildcard-, Rollen- oder Gruppenzugehörigkeit in einem Autorfeld stehen

Ich hoffe, Du hast jetzt den endgültigen Durchblick  

Bei Autoren: Das Bearbeitenrecht gilt nur für User mit der ACL Ebene Autor. Das Leserecht gilt für alle (>= Leser).

Andreas

[Andreas Bauer]

Prima, den Durchblick habe ich nun  

Muchas gracias.

Andreas

[Bruce Willis]

...wenn ein Lesefeld leer ist, wird es ignoriert.

Wenn es ein Lesefeld gibt, das nicht leer ist, dürfen folgende User das Dokument lesen:
- die namentlich bzw. durch Wildcard-, Rollen- oder Gruppenzugehörigkeit im Lesefeld stehen
- die namentlich bzw. durch Wildcard-, Rollen- oder Gruppenzugehörigkeit in einem Autorfeld stehen

Bei Autoren: Das Bearbeitenrecht gilt nur für User mit der ACL Ebene Autor. Das Leserecht gilt für alle (>= Leser).

"Ignoriert" bedeutet aber nicht, dass alle User, die auf die DB zugreifen dürfen, dann auch alle Doks lesen dürfen, wo ein leeres Lesefeld vorhanden ist.

Oder? 

[koehlerbv]

Ein leeres Leserfeld ist kein wirksames Leserfeld. Vulgo: Leserfeld = "" -> jeder kann lesen, der in der ACL mindestens Leser ist.

Bernhard

[Bruce Willis]

Ein leeres Leserfeld ist kein wirksames Leserfeld. Vulgo: Leserfeld = "" -> jeder kann lesen, der in der ACL mindestens Leser ist.

Auch dann, wenn im Dok noch ein zweites Lesefeld gibt, das nicht leer ist?..

Gruß
Leo

P.S. Vulgo im Sinne Pöbel ? 

[koehlerbv]

Dann natürlich nicht: Leser- und auch Autorenfelder arbeiten immer kumulativ.

Bernhard

[Bruce Willis]

Dann natürlich nicht: Leser- und auch Autorenfelder arbeiten immer kumulativ.

Dann hatte natürlich ich Recht.   

[LN4ever]

So lange ich auf einem Server arbeite, ist das Prinzip völlig klar, wobei ich noch zwei Ergänzungen mit auf den Weg gebe:

1. steht in dem bearbeitbaren Leserfeld nur ein Name drin und wird dieser durch den AdminP-Prozeß herausgelöscht (Mitarbeiter verläßt die Firma, Gruppe wird gelöscht), so können alle das Dokument sehen. Daher steuere ich bei einigen kritischen DBs im Setup-Dokument, ob es Dokumente ohne Leser geben darf.

2. man darf nicht vergessen, daß das berechnete Feld alleine innerhalb einer Maske gesetzt wird. Wenn also ein Schlauberger von einer Ansicht das Eigenschaftsfenster eines Dokuments aufmacht und die Leser im Sicherheits-TAB festlegt, wird ein Leserfeld mit dem Namen $READERS eingefügt - und siehe da: Admins und Server können das Dokument nicht mehr sehen.

Daher sieht bei mir das berechnete IMMERLESER-Feld so aus:

ImmerLeserListe:="LocalDomainServers":"[ReadAll]");
@If(@Trim(@Unique(Leser1:Leser2:Leser3:$READERS))="" & @GetProfileFIELD("profil";"Lesersteuerung")!="1";"";ImmerLeserListe)

Jetzt zur eigentlichen Frage:
Ist es so, daß sich der NotesClient den Inhalt der @UserNamesList merkt und cachet ? Nur dann ist es ja möglich, daß ich meine Autor- (und damit auch Leser) Rechte, die mir aufgrund von Gruppen- oder gruppenbezogenen  Rollenmitgliedschaften zustehen, in einer lokalen Replik realisieren kann (dabei ist mir klar, daß Rollen in einer lokalen Replik nur greifen, wenn konsistente ACL eingestellt ist).

Natürlich kann Notes auch davon ausgehen, daß ich mir nur die Dokumente replizieren kann, auf die ich Leserrechte habe - und braucht in einer lokalen Replik dann keine Leserprüfung mehr durchzuführen. Aber das Problem mit gruppengesteuerten Autorrechten wäre damit nicht gelöst.

Die Alternative, die Gruppennamen in das persönliche Adreßbuch aufzunehmen, wäre eine (schlechte) Möglichkeit. Sie würde das Sicherheitskonzept von Notes noch nicht verwässern, denn dann könnte ich mir dort zwar eine Gruppe anlegen und mich eintragen, und damit könnte ich lokal Dokumente bearbeiten, die ich im Serverumfeld nur lesen kann, aber diese Änderungen könnte ich nicht zurückreplizieren.

Weiß jemand, wie es geregelt ist ?

Gruß

Norbert

[koehlerbv]

Zu Deinem Punkt 2: Gute Idee, Norbert. Um saubere Apps zu schreiben, sollte man das wirklichen in allen Apps so machen - gerade in denen, in denen es eigentlich gar keine Items mit IsReader property gibt.

Zu Punkt 1: Leserfelder verwende ich generell nur, wenn sichergestellt ist, dass immer mindestens zwei Rollen im Feld stehen: [Administrator] und [ReadAll] (okay, kann man auf eine Rolle reduzieren, ich will aber zwischen beiden Rollen differenzieren können) - es sei denn, die Administrator-Rolle soll tatsächlich nur ermöglichen, die DB zu administrieren, ohne mit den Inhalten etwas zu tun zu haben.

Wegen der lokalen Repliken: Ist kACL eingestellt, dann wird bei der Anlage einer Replik faktisch ein Schnappschuss der aktuellen Rechte des Replik-anlegenden Users erstellt. Wechselt der User später die Gruppe oder wird ein anderer User in eine zugriffsberechtigte Gruppe aufgenommen und diesem die lokale Replik übergeben, so kollidiert dies mit eben diesem Schnappschuss. Lokale Gruppen helfen da nur bedingt.

Soweit mein Kenntnisstand.

Bernhard

[koehlerbv]

Deinen Nachtrag

P.S. Vulgo im Sinne Pöbel ?
« Letzte Änderung: 25.02.07 - 12:22:32 von Bruce Willis »

habe ich leider erst jetzt per Zufall entdeckt.
Nein, vulgo (von lat. vulgos - das Volk) wird in diesem Zusammenhang verwendet im Sinne von "einfacher gesagt" oder "besser bekannt als". Mit Pöbel hat das gar nichts zu tun, eher als Ankündigung einer einfachen Zusammenfassung mit der Intention, dies bitte auch so ("einfacher" und damit nicht unbedingt allumfassend) zu verstehen.

Hilft das?

Bernhard

[Bruce Willis]

Hilft das?

Klar, Bernhard.
Danke!
 

Gruß
Leo