Schreibenden Zugriff einschränken auf bestimmte Felder ...

[Thomas Schulte]

Okay vielleicht kann mir ja mal jemand auf die Sprünge helfen.
Das hört sich ja erst einmal einfach an ist aber leider dann doch nicht so trivial.

Das Szenario sieht folgendermaßen aus. Abhängig von Parametern wie Statusfeldern, den Benutzernamen oder Rollen des Benutzers sollen nur bestimmte Felder zur Bearbeitung freigegeben werden. Das sind nicht immer dieselben Felder sondern die können auch unterschiedlich sein.

Ein Ansatz über Zugriffskontrollierte Abschnitte ist illusorisch denn ich kann nicht jedes einzelne Feld in einen solchen Abschnitt stecken.
Ein Eintrag über Leser und Autorenfelder ist zu Grob, denn er umfasst nur das gesamte Dokument und ist ohnehin schon integriert.

Das Problem bei dem ich gedanklich feststecke ist wirklich, wie kann ich auf Feldebene steuern was ein Benutzer a oder b in diesem speziellen Dokument jetzt ändern darf, ohne es hardcoded in der Maske zu hinterlegen.

[koehlerbv]

Wie sicher soll das denn sein ? Wenn ein User prinzipiell Autorenrechte oder höher hat und ggf. nur bestimmte Felder nicht (editierbar) sieht, könnte er sich ja immer noch ein Agentileinchen schreiben ...

Sach ma an 

Bernhard

[Thomas Schulte]

Ach ja, das Blocken über die Isprotected Eigenschaft des Items ist leider keine praktikable Lösung

Ich hab an so etwas ähnliches wie die History Klasse in !!Help!! gedacht, hab da aber das Problem das dann auch Änderungen an Feldern die berechnet sind nicht mehr abgespeichert werden. Die müssen aber geändert werden können.

@Bernhard, damit könnte ich in diesem Fall leben. Das kriegst du sowieso nie sicher hin. Zumindest solange nicht bis IBM das Sicherheitsmodell auf Feldebene implementiert.

[koehlerbv]

Du hast aber doch bei geringem Sicherheitsanspruch noch die Möglichkeit, Felder wahlweise als "Berechnet zur Anzeige" oder "Editierbar" über Hide-whens ein- bzw. auszublenden. Und wenn es wirklich sicher sein soll, speicherst Du das Dokument nicht (weil die Leute keine Autoren (mehr) sind, sondern mailst die Änderungen an die DB, die diese dann verarbeitet.
Möglichkeiten gibt es jedenfalls etliche, auch wenn es natürlich immer Aufwand bedeutet.

Bernhard

[Thomas Schulte]

Stimmt aber weist du was das heist 18 verschiedene Forms auf diese Art abzusichern? Mit den Hide Whens, und dann noch jedes einzelne Hidewhen von einer anderen Bedingung abhängig machen. Das ist der Alptraum von jedem einzelnen Programmierer.

Es muss einen anderen Weg geben.

[koehlerbv]

Irgendwo musst Du die Bedingungen pro Feld aber immer aufmalen - wie auch immer. Bei er einfachsten Variante (getrennte Felder für Ein- und Ausgabe) kannst Du die Bedingungen ja auch zentral formulieren, im Hide-when hast Du dann nur noch eine einzige Abfrage zu stehen.
Aber auch bei aufwändigeren Mechanismen: Irgendwo müssen Deine "wenn - dann's stehen. Oder missverstehen wir uns gerade ?

Bernhard

[Thomas Schulte]

Da hast du recht Bernhard aber ich will einen Weg finden das eben nicht in die Maske reinzuprogrammieren sondern es möglichst simpel über ein Konfigurationsdokument abzudecken.

Vom Ansatz her habe ich zwei grundlegende Probleme.
1. erlaube ich dem Benutzer zu egal was zu ändern und sag ihm vor dem Speichern, So junge du bist aber ein böser Bube, das erlaube ich dir jetzt nicht.
2. Block ich von vorne herein alles ab was nicht in der Liste ist. (Hmm das könnte ich über den entering Event der Felder triggern, so nach dem Motto you are not allowed to change this field Changes will not be saved.) Damit wären die berechneten Felder außen vor denn die kann der Benutzer ja sowieso nicht anspringen. Jedes Feld das er nicht ändern darf meckert ihn an. Und wenn er es trotzdem ändert werden die Änderungen beim speichern über die Klasse wieder rückgängig gemacht. Das schöne ist das könnte im Web auch funktionieren.

Den Gedanken verfolgt ich jetzt mal ein wenig und schau was dabei rauskommt.

[TMC]

Hmm, einerseits jedes Feld voll konfigurierbar, andererseits so wenig Programmieraufwand wie nur möglich.
Ein 3rd Party Framework dafür ist mir dafür nicht bekannt. Ich denke Du musst tatsächlich die hier erwähnten Ansätze (Hide-When etc.) in Erwägung ziehen.

Was es ja auch noch gibt ist die Feld-Property "must have at least editor access", wird aber wohl für eine völlig frei konfigurierbare Maske einen auch nicht wirklich weiterbringen.

Ein Problem solch völlig freier Konfiguration ist ja auch immer:
Derjenige, der solch eine App konfiguriert ist erstmal völlig überfordert. 100 Einstellmöglichkeiten für jedes Feld, er weiß gar nicht was er braucht und was nicht.
Ich würde das irgendwie gliedern, und z.B. nur eine Hand voll "Szenarien" vorgeben. Szenario 1: Felder A, C, D, F editierbar, Szenario 2: Felder A, C, D, G und H editierbar, etc.
Jedes Szenario wird genau im Konfig-Dok beschrieben.
Du als Entwickler brauchst dann nur die Hand voll Szenarien abdecken.

[Axel]

Hi,

ich stand gerade dieser Tage vor der gleichen Problematik. Konnte es gerade noch abwehren, aber ich bin mir nicht sicher, dass es nicht doch nochmal hochkocht.

Meine Überlegung war dann die folgende: Wenn es möglich ist die betreffenden Felder layouttechnisch zusammenzufassen, dann müsste es doch möglich sein, das über Teilmasken abzufackeln. So ganz bis zum Ende habe ich das allerdings noch nicht durchgedacht.


Axel

[cgorni]

Hi,

ich habe leider auch keine neue Idee. Ich habe es bisher ebenfalls mit Hide-When-Formeln implementiert.

ABER: ein kleiner Tipp um die Verwaltung der Formeln nicht zur Hölle werden zu lassen. Nehmen wir mal an ein Feld "Adresse" soll nur bearbeitet werden, wenn der Status "Offen" ist und die Rolle "[EDV]" vergeben ist.

- Erstellen eines verborgenen Feldes "HW_Adresse" (Hide-When Adresse)
- Feld ist "Computed for Display" und Typ ist Zahl
- Formel des Feldes: !(Status = "Offen" & @IsMember("[EDV]"; @UserRoles))

Die Formeln sollten einheitlich formuliert sein. Hier ein Beispiel: "wann ist das Feld sichtbar?" und das dann komplette negieren über "!"

D.h. das Ergebnis des Feldes ist 1 oder 0 bzw. true oder false. In der Hide-When-Formel von "Adresse" kannst du jetzt einfach "HW_Adresse" schreiben. Die Verwaltung der Formeln ist damit in andere Felder ausgelagert. Das hat den Vorteil, das alles an einer Stelle steht und sprechende Namen besitzt.
Arbeit ist es natürlich trotzdem.

My 2 cents.

[Lossa]

Hi,

wenn es möglich ist den Stil der Felder von Notes auf Betriebssystem zu ändern, dann kannst du den Input Enabled Event benutzen steht dort "0" drin, dann ist das Feld grau und nicht editierbar.
Der Vorteil ist:
1. Du hast nicht die doppelte Anzahl an Feldern
2. Du brauchst dich nicht mit hide-when zu ärgern
3. Es funktioniert ohne Änderung im Web

[Axel]

Hi,

wenn es möglich ist den Stil der Felder von Notes auf Betriebssystem zu ändern, dann kannst du den Input Enabled Event benutzen steht dort "0" drin, dann ist das Feld grau und nicht editierbar.
Der Vorteil ist:
1. Du hast nicht die doppelte Anzahl an Feldern
2. Du brauchst dich nicht mit hide-when zu ärgern
3. Es funktioniert ohne Änderung im Web

Yoo, da verlagere ich das Problem aber nur. Der Aufwand bleibt der gleiche. Ich sehe darin keine echte Alternative, die mir echte Vorteile bringt.

Vorteil 1 lasse ich gelten. Bei 2. ärgere ich mich nicht mehr mit Hide-Whens rum, aber dafür mit den Formeln  im Input Enabled - Event. Zu 3. kann ich keine definitive Aussage machen, da mir die Web-Erfahrung fehlt, aber ich denke Hide-Whens funktionieren auch im Web.

Axel

[Lossa]

Hallo,

habe auch nicht gesagt das es einfacher ist, aber wenn du schon pkt 1 zustimmst, dann ist es vieleicht trotzdem einfacher, da du ja bei hide-when formeln aufgrund der Anzahl der Felder vielmehr brauchst.
Anonsten würde ich in einem Profildokument die gesperrten Felder für den User auflisten. Dann als erstes Feld in der Maske ein berrechnet zur Anzeige Feld nehmen, das holt alle gesperrten Feldname aus dem Profil und alle Felder haben im Input Event die Abfrage:
@IsNotMember(@ThisName;Sperrfelder) daraus ergbit sich automatisch True wenn nicht drin damit bearbeitbar, false ist drin damit gesperrt.
Das ganze ist mittels Copy-Paste einfach auf alle Felder übertragbar.

[Axel]

Hi,

so könnte die Sache durchaus etwas einfacher werden. Vor allem, dass mit dem Profildokument ist gar keine so schlechte Idee.

Aber, wie bei Thomas auch, wäre bei mir die Bearbeitbarkeit der einzelnen Felder von bestimmten Stati des Dokumentes abhängig. Also z.B. Feld1 darf bearbeitet werden, wenn das Dokument den Status Offen hat, Feld 1 und 2 dürfen nur im Status "In Bearbeitung" editiert werden usw. Und bei sowas wird's dann wieder aufwändig, weil ich dann fast jeden Event einzeln anpacken muss.

Axel

[Thomas Schulte]

Ok so könnte es funktionieren.

Ich hab ein Feld das Berechnet zur Anzeige ist. In diesem Feld stehen entweder werte drin oder nicht. Stehen keine Werte drin sind alle Felder ansprechbar die nicht anderweitig geschützt sind. Wenn Werte drinstehen (Feldnamen) dann sind diese Feldnamen diejenigen die für den Benutzer aktuell zur Verfügung stehen. Wenn jetzt ein Feld angesprochen wird, dann wird im OnFocus Event überprüft ob dieses Feld in derListe steht steht es in der liste ist alles in Ordnung. Steht es nicht in der Liste dann wird der Benutzer auf das erste Feld in der Liste umgeleitet. Das Ganze mit "gemeinsamen Java Script" und dann sollte das sowohl im Notes Client als auch im Web funktionieren.

So jetzt brauch ich nur noch eine Routine die
Den Inhalt des Feldes in dem die Werte stehen ausliest, vergleicht ob sein Name in diesem Eintrag vorhanden ist und wenn der eigene Name da nicht enthalten ist und Werte in der Liste stehen den Focus auf das Feld setzt das dem ersten Element der Liste entspricht oder noch besser dem Benutzer eine Auswahl der Felder anbietet die er bearbeiten darf und erst nach dieser Auswahl den Focus entsprechend setzt.

Hat da jemand schon mal was in die Richtung geschrieben. Ihr wisst schon klauen ist besser als selber schreiben 

[mrtachles]

Hi,

ich habe sowas schon in einem "Framework" fertig. Du konfigurierst, welche Felder nicht geändert werden sollen, ich merk mir die beim Öffnen im Edit-Mode um schreib ggf. zurück, falls der Anwender was geändert hat.

Gruss
Thomas

[Thomas Schulte]

Funktioniert das im Web und in Notes gleichermaßen?

Wenn ja wäre es interessant das live zu sehen. Es ist ein Ansatz den ich auch schon verfolgt habe, der aber bei mir im Web einiges an Tücken hat.

[mrtachles]

Im Web packe ich das in den WQO und WQS - Agent, also WebQueryOpen und -Save. Diesen Agenten muss man dann in die Web-Maske packen..

Hab ich jetzt noch nicht selbst ausprobiert .. sollte aber nach meinen Erfahrungen mit WQO und WQS auch dort funktionieren.

Gruss
Thomas

[Thomas Schulte]

Okay für Notes läuft das jetzt halbwegs so wie ich mir das vorstelle.
Ein Feld berechnet zur Anzeige mit den Felder die Accessible sind, ein wenig gemeinsamer JavaScript Code im JS-Header der Maske und genau eine Zeile in jedem Feld das überprüft werden soll.
Eines der Problem die ich jetzt noch habe ist das mir der Code im Browser eine Fehlermeldung rausschmeist, von wegen das Feld das verwendet wird um die Feldnamen zu halten hat keine Properties.
Fehler: f.isRestrainedFields.value has no properties. Warum in aller Herren Länder Namen funktioniert das in Notes und im Web nicht?
Ein anderer, das onFocus beim ersten öffnen des Dokumentes nicht richtig zu funktionieren scheint und das wenn man einen TabRückwärts macht er sich auf das erste Feld in der maske positionieren lässt und man da manchmal etwas eingeben kann. Komische Sache das? Bei den Leuten die nur die Maus hin und her Schubsen Funktioniert das nämlich. Scheinbar wird beim OnFocus erst dann getriggert wenn irgendeine Aktion in dem Feld stattfindet.

Ach ja hier ist eine Test Datenbank dazu. Da fehlt jetzt nur noch die Möglichkeit das der Benutzer wenn er beim Klick abgewiesen wird auswählen kann welches Feld er denn gerne anzeigen will und das Ding muss noch im Web lauffähig sein.
Die Form mit der ihr weitertesten könnt ist die ...V3

[flaite]

Für neuere Browser könnte man vermutlich auch javaScript dynamisch in $$HtmlHead per Formelsprache generieren und das readonly property von html-fields ausnutzen.
http://www.cs.tut.fi/~jkorpela/forms/readonly.html