ACL und "Write Public Documents"

[Semeaphoros]

Wenn man der wunderbaren Aufstellung von Matthias über die ACL folgt (ACL  Uebersicht, dann sollte jemand mit Reader-Access und Write Public Documents gesetzt zwar Dokumente mit Public-Masken erstellen können, nicht jedoch bearbeiten. Wir haben das eben unter 6.5 ausproiert und bei uns konnte ein solcher User sowohl seine eigenen Public-Dokumente editieren, wie auch die Public-Dokumente von anderen Usern, und dies selbst dann, wenn ein entsprechendes Autoren-Feld im Dokument drin ist. Kann das jemand bestätigen? Wenn ja fehlt beim Reader noch ein Kreuz mit Anmwerkung 2 und der Hinweis, dass  bei Public-Dokumenten autorenfelder nicht wirksam sind.

[Glombi]

Hi Jens,
leider kann ich es momentan nur unter R5 testen. Dort verhält sich die Sache so:
Ein User mit Reader Access und Write Public Documents darf jedes Dokument, welches er lesen kann, in den Bearbeitenmodus setzen und dort Änderungen vornehmen. Beim Speichern kommt aber die Meldung "Sie sind zur Dürchführung dieser Operation nicht berechtigt".
Das ist unabhängig davon, ob der User im Autorenfeld steht oder nicht.

Wenn das in R6 anders ist, wäre das ein Käfer.

Andreas

[Semeaphoros]

Hast Du das Feld $PublicAccess mit einem Wert von "1" drin? Ohne das kann man die Dokumente nicht abspeichern, auch keine neuen. Mit dem Feld gehts dann dummerweise überall.

[Glombi]

Mit $PublicAccess wird die ACL offenbar völlig ausgehebelt! Egal mit welcher Zugriffsebene - selbst -Kein Zugriff- -, sofern "Öffentliche Dokumente schreiben" aktiv ist, darf der User alles bearbeiten, ändern und speichern!
Ist wohl ein Feature.

Das Feld muss also vom Programmierer mit Bedacht gesetzt werden!

Die BP sollten wir entsprechend ergänzen.

Andreas

[koehlerbv]

Das ist ein Feature, Andreas. Damit kann man ja bestimmte Dokumente zum Zugriff freigeben, auch wenn der User sonst keine weiteren Rechte in der DB hat.
Musterbeispiel ist die Kalender-Delegerierung im Mail File.

Ciao,
Bernhard

[Semeaphoros]

Ok, dann sehe ich das mal als "erledigt" an und die Sache geht andernorts weiter.

[TMC]

Ich muss das Thema nochmal aufgreifen:

Eine Datenbank. "Available to Public Access users" ist in den Maskeneigenschaften NICHT gesetzt.
Lokaler Test (konsist. ACL): User mit Reader-Rechten und gesetztem "Write public documents" in der ACL darf doch tatsächlich ein neues Dokument erstellen via [ComposeDoc] @Command. Cache.dsk entfernt, etc., Client neu gestartet hab ich gemacht.

Bug oder Feature? Client = 6.5.3 EN.

Hintergrund meiner Frage: ich möchte eine Suchmaske auch für reine Leser bereitstellen (um dann die Eingaben via db.Search weiterzuverarbeiten), ich denke da müsste ich hierzu
a) in der Suchmaske "Available to Public Access users" setzen
b) in der ACL "Write public documents" für die Leser setzen

Aber der oben geschilderte Nebeneffekt sollte doch nicht sein, oder?

Matthias

[Semeaphoros]

Erstellen UND Speichern oder nur Erstellen?

[TMC]

Gute Frage 

Speichern is nicht: "You are not authorized to perform that operation".

Ist "Write public documents" deaktiviert, so kommt dieselbe Fehlermeldung bereits beim [Compose] @Command, also Erstellen.

Sollte meines Erachtens immer schon beim Erstellen kommen, auch wenn "Write public documents" aktiviert ist, aber "Available to Public Access users" in den Maskeneigenschaften nicht gesetzt ist. Gut, den Button/die Aktion kann man über Hide-When ausblenden (sollte man eigentlich eh), und sicherheitskritisch ist es so sicherlich nicht.

[koehlerbv]

Das ist ein Feature, würde ich sagen, Matthias.

Für solche Dinge verwende ich in der Regel ProfileDocs (mit den entsprechenden Berechtigungen, die dann ggf. - wie in Deinem Fall - auch nicht abgespeichert werden). So baut jeder immer nur "sein" Dokument auf und müllt die UNC nicht mir mit gelöschten Docs zu.

Etwas Off-Topic: Sowas verwende ich auch, wenn ich RTFs einmalig darstellen muss (zum Beispiel zur farbigen Darstellung von Dokumenten, die einen Speicher- oder Replizierkonflikt darstellen. Gespeichert werden muss das wegen RTF ja (vor allem immer, wenn es <R6-kompatibel sein muss). So gibt es aber eben nur ein Dokument pro User (was per definitionem nicht speicherbar ist und was vor jeder Verwendung "aufgeräumt" wird).

Bernhard

[TMC]

Das ist ein Feature, würde ich sagen, Matthias.

Kannst Du das bitte begründen? Danke.

Für solche Dinge verwende ich in der Regel ProfileDocs (mit den entsprechenden Berechtigungen, die dann ggf. - wie in Deinem Fall - auch nicht abgespeichert werden). So baut jeder immer nur "sein" Dokument auf und müllt die UNC nicht mir mit gelöschten Docs zu.

Ist eine Standard-Suchmaske, d.h. die Einträge werden natürlich nicht gespeichert, wozu auch, wäre mehr als lästig, ist User ja anderweitig auch nicht gewöhnt (Google oder sonstige (Web)formulare, etc.). Höchstens ein Aufzeichnen der zuletzt eingegebenen Begriffe wäre nett, wie man das anderweitig kennt, wo dann unterhaln den Suchfeldern die letzten Begriffe erscheinen....
Somit sehe ich keinen Grund, hier was zu speichern, oder Profildoks zu verwenden.

Als Mini-Bug sehe ich, dass in der o.g. Konstellation keine Fehlermeldung beim Erstellen des Doks kommt, sondern erst beim Versuch des Speicherns. Nicht intuitiv für User, außerdem fatal, falls ein User umfangreiche Infos eingepflegt hat, und dann beim Speichern kommt "Ätsch, du darfst doch nicht".

[koehlerbv]

Kannst Du das bitte begründen? Danke.

Komischer Tonfall ... Aber trotzdem gerne: Solange das Dokument erstellt wird und noch nicht "hart" gespeichert wird, hat der User die Berechtigung - er tut ja noch nichts unerlaubtes. Beim Speichern mit einem Level unterhalb "Despositor" im Backend wird er dann aber als Nicht-Berechtigter identifiziert.
Feature in diesem Zusammenhang also: Für den Zweck der Datenübergabe rein auf Basis "in memory" bekommst Du die Erlaubnis, wenn es ernst wird, natürlich nicht mehr. Das dies (mit dem Speicherversuch un der dann folgenden Fehlermeldung) erst gar nicht erst auftreten kann, hast Du als Programmierer dabei ja vollkommen in der Hand. Unter dem Strich passiert ja gleiches, wenn Du Autor bist, aber das gepspeicherte Dokument Dich in keinem Autor-Feld aufführt - da kommst Du dann eben nie wieder heran. Wie gesagt: Gleiches Prinzip.

Was die ProfileDocs angeht, habe ich dies ausdrücklich mit "OffTopic" versehen. Das also bitte jetzt nicht wieder kaputtinterpretieren ...

Bernhard

[Semeaphoros]

Sehe ich als schlecht dokumentiert an. Das Verhalten kann für Wegwerfdokumente ja durchaus nützlich sein und wenn man das Verhalten kennt, lässt sich das mit programmatischen Mitteln wie von Euch beiden beschrieben regeln.

[TMC]

Hi Bernhard,

Zu "Tonfall"

Kannst Du das bitte begründen? Danke.

Komischer Tonfall ...

Tonfall gibt es doch nur im gesprochenen; wie auch immer: es kam eine Aussage ohne Begründung, und diese wollte ich damit anfragen. Bin aber gerne für einen Hinweis dankbar, wie ich zukünftig solch eine Frage mit einem anderen "Tonfall" stellen darf.

Zu "Bug oder Feature"
Es gibt 2 Konstellationen, ich fasse nochmal zusammen:

1.) "Available to Public Access users" in den Maskeneigenschaften NICHT gesetzt, "Write public documents" in ACL IST gesetzt.
--> Fehlermeldung erst beim Speichern des Dokuments

2.) "Available to Public Access users" in den Maskeneigenschaften NICHT gesetzt, "Write public documents" in ACL IST NICHT gesetzt.
--> Fehlermeldung bereits beim Öffnen des Dokuments

Meines Erachtens sollte das einheitlich sein (am besten bereits beim Öffnen), da letztendlich dieselbe Situation vorliegt: User hat Leserrechte und darf lt. ACL keine Dokumente *erstellen* - also *creating* (und natürlich auch nicht speichern - mein Fehler dass ich das nicht prüfte).
Letztendlich möchte ich aber nicht mehr weiter darauf eingehen, wir haben mit ganz anderen Bugs zu kämpfen, dies hier ist schon fast ein "Kosmetik-Bug", und nicht wirklich relevant, somit in der Priorisierung ganz am Ende anzusiedeln.

Zu "Profildokumente"

Was die ProfileDocs angeht, habe ich dies ausdrücklich mit "OffTopic" versehen. Das also bitte jetzt nicht wieder kaputtinterpretieren ...

Warum kaputtinterpretieren, OffTopic hattest Du doch nach der ersten Erwähnung der Profil-Doks eingeleitet:

Das ist ein Feature, würde ich sagen, Matthias.

Für solche Dinge verwende ich in der Regel ProfileDocs
(...)
Etwas Off-Topic: (...)

Daher hab ich natürlich angenommen, dass Du das auf meine Fragestellung beziehst.


Grüße,
Matthias

[koehlerbv]

Hallo Matthias,

es gibt noch einen dritten Fall: Die Maske kommt beim Erstellen gar nicht ins Spiel, da das Dokument im Backend erzeugt wurde. Erst nach dem Erstellen und den "Präliminarien" wird es wie NotesUIWorkspace.EditDocument ins FrontEnd geholt.

Ich sehe es so wie Du: Der Programmierer hat es unterm Strich komplett selber in der Hand, und das Verhalten von Notes würde ich hier keinesfalls als Bug einstufen, ehestens so wie Jens es beschrieb: "Schlecht dokumentiert". Aber auch hier habe ich eigentlich noch meine Zweifel: Wer auf der Ebene programmiert, hat eigentlich schon alle Infos (oder sollte sie haben), die dieses Verhalten erklärt.

Bernhard

[Semeaphoros]

Habs nochmal durchgelesen, bin mir nicht wirklich sicher, ob man das sprachlich-logisch unter einen Hut bringen kann. Tragisch ist es gewiss nicht, da, wie Bernhard sagt, der Programmeur auf dieser Stufe wohl genug Erfahrung haben sollte, es zu beherrschen. Trotzdem wären ein paar Worte mehr in der Doku sicher nicht schlecht ....