Sichtbarkeit von Outline-Einträgen von Benutzer festlegen lassen

[thomas_k]

Hallo zusammen, ich benötige wieder mal eure Hilfe!

Ich muss folgende Anforderung bearbeiten:
Ein Eintrag in einer Outline soll nur für bestimmte Personen, Gruppen bzw. Rollen sichtbar sein.
Diese Personen, Gruppen... sollen aber nicht von mir im Designer festgelegt werden, sondern soll ein bestimmter Benutzer bestimmen und ändern können.
Meine Idee hierzu wäre eine einfache Maske mit einem Feld zu erstellen. In diesem Feld wählt der bestimmte Benutzer dann alle Personen... aus welche den Eintrag in der Outline sehen dürfen.
Kann ich dann beim Outline-Eintrag mithilfe der Formelsprache auf dieses eine Feld zugreifen, um somit die Sichtbarkeit zu regeln? Wenn ja, wie?
Oder gibt's zu dieser Anforderung vielleicht andere, bessere Lösungswege?

Vielen Dank schon mal im Voraus!

[koehlerbv]

Ja, sowas kannst Du machen, in dem Du die Outline in eine Maske einbettest, die das Feld mit den Zugriffsinformationen ausliest und bereitstellt.

Aber: Was willst Du damit erreichen? Was willst Du damit ggf. unsichtbar machen? Ein Outline Entry ist ja nicht der einzige Weg, wie man an Elemente einer Datenbank heran kommt. Alles lässt sich so also nicht verbergen (wenn auch manches).

Bernhard

[Tode]

Also grundsätzlich würde ich eine Rolle erstellen, die Du einer Gruppe in der ACL zuweist. Jetzt gibst Du der berechtigten Person das Recht, die Gruppe zu bearbeiten geben... wie Bernhard schon sagt: security ist das nicht, aber manchmal will man ja nur übersichtlichkeit und gar nicht „echte“ Sicherheit.

Ach so: der Hidewhen geht dann auf @IsNotMember( „[Rolle]“; @UserNamesList)

[Peter Klett]

Um nah an Deinem Vorschlag zu bleiben, ein Dokument zu erstellen, in dem die Zugriffsberechtigten eingetragen werden, hilft Dir vielleicht diese Formel, die sinngemäß so bei uns produktiv eingesetzt wird.

Code

_tmp := @DbColumn (""; @DbName; "vorgaben"; 1);
_tmp2 := @If (@IsError (_tmp); ""; @DbLookup (""; @DbName; "vorgaben"; _tmp [1]; "Berechtigte"));
_tmp3 := @If (@IsError (_tmp2); ""; _tmp2);
!@Username = _tmp3

oder wie Torsten schreibt

@IsNotMember (@Username; _tmp3)

_tmp holt sich aus einer Ansicht "vorgaben" die Schlüssel der Vorgabendokumente (es könnte z.B. nur eines in der Ansicht stehen)
_tmp2 liest sich den Inhalt des Feldes "Berechtigte" aus dem ersten Vorgabendokument
_tmp3 ist das fehlerbereinigte Ergebnis von _tmp2

Das ist nur eine mögliche Variante. In der Ansicht könnten auch die UniversalIDs stehen, dann könnte man mit @GetDocField arbeiten. Oder das Vorgabendokument hat einen festen Schlüssel, dann spart man sich das @DBColumn. Oder man nimmt ein Profildokument dafür, oder , oder ...

[ronka]

Würde in den Formel
!@Username = _tmp3

in

!@Username *= _tmp3

Damit mehrfach werten kontrolliert werden anstatt einzelnwerten.

[Peter Klett]

@Username ist aber kein Mehrfachwert, *= nutzt man, um zwei Mehrfachwerte miteinander zu vergleichen (schadet aber auch nichts, wenn es sich um einen einfachen Wert handelt, dann vergisst man es nicht)

Folgendes habe ich gerade getestet

Einfachwert gegen Mehrfachwert, kein Unterschied
"b" = "a" : "b" : "c"   -> @True     "b" *= "a" : "b" : "c"   -> @True
"b" = "d" : "e" : "f"   -> @False     "b" *= "d" : "e" : "f"   -> @False

auch umgekehrt kein Unterschied
"a" : "b" : "c" = "b"   -> @True     "a" : "b" : "c" *= "b"   -> @True
"d" : "e" : "f" = "b"   -> @False     "d" : "e" : "f" *= "b"   -> @False

Mehrfachwerte gegeneinander
"a" : "b" = "a" : "b" : "c"   -> @True     "a" : "b" *= "a" : "b" : "c"   -> @True
"a" : "b" = "d" : "e" : "f"   -> @False     "a" : "b" *= "d" : "e" : "f"   -> @False
"b" : "e" = "a" : "b" : "c"   -> @False     "b" : "e" *= "a" : "b" : "c"   -> @True
"b" : "e" = "d" : "e" : "f"   -> @True     "b" : "e" *= "d" : "e" : "f"   -> @True

Die rote Zeile gibt ein m.E. falsches Ergebnis, bei Mehrfachwerten auf beiden Seiten sollte man unbedingt *= verwenden.

[ronka]

Zur Information *= ist einen Listen vergleichsoperator.

Wenn ein Element vor den vergleicher gleich ist an ein Element danach ist das Ergebnis True.

In der Formel sprache ist ALLES eine Liste, auch ein einzelnes element ist einen Liste, deshalb kann mann a auch als a[0] ansprechen.

In Lotusscript ist das anders.

Deshalb ist der linie mit den Roten inhalt mit den "nur" = zeichen aber nicht falsch. Dort wird einen Liste mit einen Liste verglichen, und die beide Listen sind nicht identisch, das allerdings die zeile drunter ( "b" : "e" = "d" : "e" : "f"   -> @True ) angibt, finde ich erstaunlich, weil eigentlich musste der nach operator auch False anzeigen. Hier dürfte den Teilstring eigentlich kein True zurück geben, wäre meine mathematische denkweise wenigstens.

Trotzdem, im Normalfall schadet der nutzung des *= nichts, ausser mann kontrolliert explizit auf Listen bezogen würde. Dort ist dann auch den Reinfolge noch zuberücksichtigen.

[Tode]

@Peter: Wegen "falsches Ergebnis"... Dazu muss man wissen, wie die Formelsprache intern Listen vergleicht.

Zwei Listen werden intern immer so verglichen:

1. Schritt: Listen gleich lang machen. Wenn beide Listen unterschiedlich viele Elemente haben, dann wird bei der kürzeren Liste das letzte Element so oft wiederholt, bis beide Listen gleich lang sind.

Vergleicht man also "a" mit "b" : "c" : "a", dann wird intern die erste "Liste" auf "a" : "a" : "a" verlängert.

aus "b" : "e" im Vergleich mit "a" : "b" : "c" wird dann also "b" : "e" : "e".

2. Schritt: Beim normalen "="- Operator werden nun die Werte "Zeilenweise" verglichen: Der erste mit dem ersten, der zweite mit dem zweiten, usw. Ergibt sich dabei EIN Match, ist der Vergleich @True:

Im ersten Beispiel also:
"a" = "b"
"a" = "c"
"a" = "a" ---> @True

Im zweiten:
"b" = "a"
"e" = "b"
"e" = "c"

==> Kein Treffer, also @False

Der Permutationsoperator "*=" führt einen Vergleich JEDES Elements der Liste mit JEDEM Element der anderen Liste durch.
Im zweiten Beispiel finden also folgende Vergleiche statt:

"b" = "a"
"b" = "b" --> @True
"b" = "c"
"e" = "a"
"e" = "b"
"e" = "c"

Bei langen Listen bedeutet das eine MENGE Vergleiche...

Das ist übrigens auch der Grund, warum der Vergleich einer Liste mit einem Einzelwert immer @True liefert, wenn der Wert mindestens einmal in der Liste ist.

Diese Art des Vergleiches ist übrigens auch die Ursache, warum

a != b was anderes liefert als !(a = b)... a != b ist bei zwei Listen, bei denen nicht alle Elemente identisch sind, immer @True, während !(a = b) nur dann @True ist, wenn KEINES der Elemente aus a mit b übereinstimmt...

[ronka]

Yep, den listen gleich lang machen ist dabei der Trick.

Jetzt ein wenig off-Topic, aber durchaus auch nutzlich.

Den kann mann auch für das erstellen von einen Präfix oder Suffix sehr schon verwenden.

Strassen := "Lang" : "Kurz" : "mittel";
MitSuffix := Strassen + "weg";
MitPräfix := "Am " +  Strassen;

Liefert dann für MitSuffix "Langweg" : "Kurzweg" : "mittelweg"

mit Präfix "Am Lang" : "Am Kurz" : "Am mittel"

Und bei misschungen Formen dann
Gesamt := ( "Bei " : "Am " ) + Strassen ;

Bringt das "Bei Lang" : "Am Kurz" : "Am mittel"

Ich habe solche "Spielchen" auch real schon eingesetzt für bestimmte kontrollen, z.B. beim @Implode und @Explode sind diesen dingen sehr sinnvoll einsetzbar wenn mann einen spezifischen inhalt irgendwo suchen muss aber nicht durch alle einzelne elementen gehen möchte.

[Peter Klett]

@Torsten: Danke, so tief hatte ich mir da noch nie Gedanken gemacht , ist dann aber logisch.

Enthält ein Vergleichswert nur ein Element, könnte man auf "*" verzichten, sollte man aber nicht, weil man es sonst vergisst (wie ich meistens ...), es sei denn, man will wirklich absolute Gleichheit überprüfen, bei der auch die Reihenfolge relevant ist

[thomas_k]

Danke für die vielen Rückmeldungen und sorry wegen meiner späten Antwort, ich war für längere Zeit nicht mehr im Büro.

Normalerweise erstellen wir hierfür auch eine Rolle, dies wäre am Einfachsten. Jedoch möchte dies der Administrator in diesem Fall nicht, da in dieser Datenbank bereits einige Usergruppen mit verschiedenen Rechten ausgestattet wurden, einige betroffene User in mehreren Usergruppen sind und er durch diese Verschachtelung nicht genau weiß, an welche User er nun welche Rollen verteilen muss. (oder so ähnlich  )

Ich denke nun, man könnte auch die betroffenen User in einem Profildokument auswählen und die User aus einem Feld im Profildokument mit @GetProfileField auslesen. Mithilfe von @Contains kann man dann vergleichen ob @Username in dem Feld im Profildokument vorkommt.
Jetzt wäre es noch praktisch wenn man nicht jeden Benutzer einzeln eingeben muss, sondern eventuell eine Benutzergruppe auswählen kann.
Gibt's einen Befehl in der Formelsprache in der man abfragen kann, ob ein bestimmter Benutzer in einer Benutzergruppe enthalten ist? Ich bin bei einer Suche danach leider nicht fündig geworden 

LG

[Tode]

Vergleiche @Usernameslist mit dem Gruppennamen... gilt immer für den aktuell angemeldeten Benutzer...

[thomas_k]

Danke Torsten, dass ist genau das, was i benötigt habe 

Somit habe ich das nun nach Wunsch des Auftraggebers einbauen können 

Danke an alle für die Hilfe!