HILFE: Zugriffskontrolle im Dokument

[Parker77]

Hallo,

Ich werde noch verrückt...

Der Workflow soll wie folgt aussehen:

Neues Dokument wird vom Benutzer angelegt und gespeichert.
Hat er es erst einmal gespeichert, darf er es die Grunddaten nicht mehr bearbeiten können.

Das Dokument bekommt in einem Statusfeld eine "1" gesetzt (hidden) und erscheint in einer anderen Ansicht.

Über Shared Actions werden die Daten aus dem Dokument genommen, weiterverarbeitet und der in anderen Statusfelder ein Eintrag erzeugt und das Dokument gespeichert. Dies geschieht solange, bis der Workflow abgeschlossen ist.

An die Sache bin ich erstmal mit Leser- und Autoren-Feldern rangegangen. Das Dokument wird erstellt und gespeichert, Status wird gesetzt, im Leserfeld wird der Benutzer eingetragen - alles wunderbar. Im zweiten Schritt rennt mein Agent los kann aber das nächste Statusfeld nicht setzen bzw. das Dokument nicht speichern, weil der Bearbeiter nun kein Autor, sonder im Leserfeld eingetragen ist.

Also gut, dachte ich mir, gehst Du über Subforms an die Sache ran, hat aber auch nicht hingehauen.

Des Rätsels beste Lösung scheint mir ein kontrollierter Abschnitt zu sein, in dem die Grunddaten einträgt und danach nicht mehr verändert. Meine Statusfelder liegen ausserhalb dieses Abschnitts.

Allerdings haut die Formel im Abschnitt

@If(Feld_gesetzt = "0";"";"[Admin]")

nicht hin. Wenn ich nicht in der Rolle [Admin] bin, sondern in der Rolle [Benutzer] kann ich nichts in dem Abschnitt verändern. Notes schliessen und öffnen hab ich auch schon probiert (von wegen Caching).

Geht das, was ich will, überhaupt? Hat mich irgendjemand verstanden? 

Zweckmässig wäre vielleicht einfach auch nur, wenn bei Doppelklick auf das Dokument dieses ohne Abfrage zu speichern geschlossen würde...

Ich weiß nicht, was ich machen soll, das zerrt echt an meinen Nerven... *grrr*

Schonmal Danke für Tips!

Euer Jens.

[koehlerbv]

Ehrlich gesagt: Ich verstehe das Problem (oder dessen Formulierung) nicht.

Kontrollierte Abschnitte und Co. sind keine Sicherheit, sie wirken nur im Frontend. Autoren- und Leserfelder sind dagegen einfach zu handhaben und sicher.

Der Standardablauf ist doch: User A macht seine Angaben und speichert, wenn er im Workflow weitermachen will (über eine Aktion - speichern alleine wäre ja in der Regel nicht so lustig). Dabei wird er aus dem Autorfeld genommen, ein anderer (User B) / andere wird (User B und C und D) / werden eingesetzt. Danach kann User A das Dokument nicht mehr bearbeiten - nur das speichern ging noch.

Sag' mal genaueres.

Bernhard

[y20frank]

nur mal so am Rande: habe das mit den Abschnitten gerade mal im Notes 7beta getestet... irgendwie geht das da z Zt gar nicht. Die ragieren auf keine Rolle oder Formel... 

Auf Autoren und Leser-Felder würde ich auch setzen, wenn es das gesamte Dokument betirfft!
Problem ist nur: wenn ein Teil des Dokumentes von dem einen, und der andere Teil von einem weiteren Personenkreis bearbeitet werden soll... Da müssten schon die Abschnitte herhalten, wenn ich mich nicht irre...

[koehlerbv]

Wenn es sicher sein soll, dann reicht auch dieses Verfahren nicht (für Gruppe A diese Felder, für Gruppe B jene), Frank. Da muss dan eingemachtes 'ran (zum Beispiel: Mailen der Änderungen an die DB zwecks geflissentlicher Bearbeitung).

Abschätzen muss man aber immer, wie hoch das Sciherheitsbedürfnis tatsächlich ist. Ausserdem kann jede Änderung des Dokuments protokollieren - häufig reicht das ja schon gegen situativ unwahrscheinlichen Missbrauch. Es führen also wie gewohnt viele Wege nach Rom.

Bernhard

[-Michael-]

Hi,

Allerdings haut die Formel im Abschnitt

@If(Feld_gesetzt = "0";"";"[Admin]")

nicht hin.

Schau Dir dazu mal die Technote #179788 an, ich hatte das erst gestern.

Auszug:

2. Controlled Access Section
Here are the steps for hiding a RTF using a Controlled Access section:

1. Open the form in Domino Designer. Highlight the RTF and any other paragraphs you want to hide along with it.
2. From the menu select Create, Section, Controlled Access.
3. Use the Form Section properties box to set the section properties as shown below. In this example, you are hiding the RTF if DocStatus = "Draft".

    * Set the section to be collapsed in all modes for non-editors. When the section is collapsed, nothing inside it is visible.
    * Set it to be expanded in all modes for editors. If modal sensitivity is needed (for example, if the field should be hidden only in edit mode) this can be accomplished using the modal expand/collapse settings. This example hides the RTF based on the DocStatus only, regardless of mode.
    * Set the section access formula to 'Computed for Display', and write a formula that returns @UserName or "" if you want the RTF to not be hidden. To hide the RTF, the formula should return a nonexistent name (for example, "-nobody-"). Since the formula is 'Computed for Display', it is recalculated for each different user when they open the document. If you want to hide based on group or role membership, your formula can just name the group(s) or role(s). For example, "[WFEditors]" is the formula you'd use to hide the section from everyone except members of the WFEditors role.
    * In the hide properties of the section, check/select boxes to hide the section always. The section hide properties actually affect only the section header line. The contents of the section are visible if the section is expanded, even if the header line is hidden. With the header hidden, the user can't open or close the section manually, so their editor/non-editor status will determine whether they can see the contents. Note: Be aware of that under specific conditions section contents may not be present as expected. For more information refer to the document, "RenderToRTItem and Simple Action "Send Mail Message" Render Sections Differently than Forwarding" (#1085322).

In den Screenshots siehst Du auch eine Beispielformel.

Sicher ist das ganze nicht, da hat Bernhard vollkommen recht. Wenn das also nicht reicht, würde ich mit Feldverschlüsselung arbeiten, die eh bei Notes standardmäßig dabei ist.

Ciao,
Michael

[Parker77]

Ehrlich gesagt: Ich verstehe das Problem (oder dessen Formulierung) nicht.

Kontrollierte Abschnitte und Co. sind keine Sicherheit, sie wirken nur im Frontend. Autoren- und Leserfelder sind dagegen einfach zu handhaben und sicher.

Der Standardablauf ist doch: User A macht seine Angaben und speichert, wenn er im Workflow weitermachen will (über eine Aktion - speichern alleine wäre ja in der Regel nicht so lustig). Dabei wird er aus dem Autorfeld genommen, ein anderer (User B) / andere wird (User B und C und D) / werden eingesetzt. Danach kann User A das Dokument nicht mehr bearbeiten - nur das speichern ging noch.

Sag' mal genaueres.

Bernhard

Guten Morgen

Erstmal Danke, dass Ihr Euch die Mühe macht, meinen Mist überhaupt zu verstehen....

@Bernhard:
Ja, üblicherweise ist der von Dir beschriebene Vorgang so wie Du ihn schilderst.

Ich versuch es mal einfacher zu erklären.

User A mach Eingaben und speichert. Das Dokument selbst wird von demselben User per Actions weiterverarbeitet, in meinem Fall sollen die inhaltlichen Daten auf einen Grossrechner überspielt werden.
Jedoch darf derselbe User, die gemachten Eingaben in Schritt 1 nicht mehr verändern dürfen, trotzdem aber die Daten gegen den Grossrechner schicken - und dann je nach Erfolg bzw. Misserfolg der Übertragung ein Statusfeld im Dokument einsetzen und speichern.

@Michael:
Yep, schon gelesen, Danke:) Allerdings ist das ausblenden für bestimmte User hier leider keine Annehmbare Lösung. Aber wenn wie Bernhard sagt, sections keine Sicherheit im eigentlichen Sinne bieten fällt das wohl sowieso flach...

@All:
Wobei Sicherheit hier garnicht mal so die Anforderung ist. Man will halt nur verhindern, dass der User die Daten nachträglich verändert und so Verwirrung gestiftet wird. Änderungen mitprotokollieren klar... Aber wenn ich immer mitschreibe, welcher Felder und Werte verändert worden sind, wird ja alleine die History riesig, da es sich bis auf meine o.e. Statusfelder um das gesamte Dokument handelt.

Seltsam, seltsam.... Aber so steht es im Pflichtenheft geschrieben....

Jens.

[koehlerbv]

Erstmal Danke, dass Ihr Euch die Mühe macht, meinen Mist überhaupt zu verstehen....

Jens, als Mist würde ich das nicht betrachten - das ist schon ein wirkliches Problem, das es zu lösen gilt.

Wenn "Sicherheit nicht die Rolle" spielt (will heissen: Ihr erwartet keine kriminellen Hacker, die Dokumente über Agents - ggf. auch aus einer anderen DB heraus - im BackEnd verändern) und Ihr "nur" vermeiden wollt, dass der unbedarfte Anwender nicht versehentlich Daten ändert, die er nicht mehr ändern sollte, dann gibt es dazu (mindestens) zwei Standardverfahren:
1. Die betroffenen nichtänderbaren Felder stehen in Teilmasken. Einmal editierbar, einmal nur als cfd (computed for display). Je nach Status / Berechtigung des Anwenders bindest Du mal die eine, mal die andere als berechnete Teilmaske ein.

2. Du führst in Deiner Maske die betroffenen Felder doppelt (dies kann unter Umständen die performantere Lösung sein) - einmal editierbar, einmal cfd. Über hide-whens zeigst Du nun mal das eine, mal das andere Feld an.

Der kontrollierte Abschnitt sollte aber eigentlich auch funktionieren, aber da habe ich schlicht Dein eigentliches Problem nicht verstanden.

Bernhard

[Parker77]

Hi Bernhard

wäre sicherlich auch toll das Projekt umzusetzen, wenn der Projektverantworliche nicht ein "Möchte-Gern-Programmierer" wäre, der ein VBA Buch gelesen hat - und mir alle Nasen lang über die Schulter schaut und mir sagt, wieso ich das nicht so mache, oder so.....

Der kontrollierte Abschnitt hat bei mir irgendwie nicht gezogen, hatte zwei Rollen angelegt und in der Abschnittsformel gesagt, dass der Ersteller meine Felder anlegen darf, danach aber nicht mehr ändern. Das wollte ich über die Formel erreichen:
@If(Feld_gesetzt = "0";"";"[Admin]")

Aber entweder hab ich bei meinen Rollen was falsch gemacht, oder beim ID-Wechseln, oder oder oder.

Ich hab jetzt Deinen Rat beherzigt und einfach die Felder doppelt geführt (editierbar bzw. cfd und dann ausgeblendet über die hide-when Formel). Klappt ganz gut *Juhu*
Da hätte ich auch selbst drauf kommen können. Mal sehen was mein VBA'ler dazu sagt....

BTW: Nichts gegen VB,VBA - das mache ich auch...

Bernhard, falls Du mal nach Frankfurt kommen solltest: Einfach rechtzeitig melden, ein Bier oder Kaffee geht auf meine Rechnung!