Domino 9 und frühere Versionen > ND6: Entwicklung

Schreibenden Zugriff einschränken auf bestimmte Felder ...

<< < (2/7) > >>

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.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete