Action Button vor User verstecken, der nicht in Profildokument konfiguriert ist

[mpausch]

Hallo Domino Entwickler,

in einer Datenbank in der Anträge gestellt und genehmigt werden, möchte ich den Button
zur Genehmigung eines Antrages vor Usern verstecken, die nicht im Profildokument als Genehmiger konfiguriert sind.

Als "Aktion verbergen, wenn Formel wahr ist" habe ich folgendes
eingetragen:

Code

!@IsMember(@V3UserName;@GetProfileField("pdoc";"Genehmiger"))

Das Feld "Genehmiger" ist vom Typ "Namen" und es sind Mehrfachwerte zugelassen.

Leider funktioniert das nicht so, wie ich mir das vorgestellt habe.
Was habe ich falsch gemacht?

Schon mal vielen Dank im Voraus.

[ascabg]

Hallo,

Ich frage mal so.

Was liefert denn @V3UserName zurueck und was steht im entsprechenden Feld des Profile-Dokumentes?

Und was ich auch noch erwaehnen moechte, und was hier im Forum auch schon oft erwaehnt wurde, ist,
wenn ein Name aus dem Feld des Profiles geloescht wird, kann der betreffende Benutzer dennoch
Dokumente genehmigen, obwohl er ja kein "Genehmiger" mehr ist. (Cache-Problematik)


Andreas

[mpausch]

Hallo,

@V3UserName liefert: Max Mustermann/ADM/DE/COMPANY
und im Genehmiger-Feld steht im Moment 1 Eintrag: Max Mustermann/ADM/DE/COMPANY

Die Werte im Genehmiger-Feld werden per Adressdialogfeld ausgewählt.

[koehlerbv]

Warum nimmst Du V3Username?
Und in Genehmiger steht mit Sicherheit auch was anderes, nämlich CN=OMax Mustermann/OU=ACME/OU=DE/O=Company.

Statt @IsMember kannst Du auch den Permutationsoperator verwenden:
!(@Username *= @GetDocField (...))

HTH,
Bernhard

[mpausch]

ich nehme V3UserName weil's laut Doku den Usernamen ohne die ganzen Identifier (CN, OU, etc....) zurückliefert.
Und in Genehmiger steht der Name auch ohne die Identifier (zumindest werden mir die Werte ohne jeweilige Identifier angezeigt)

[ascabg]

Hallo,

Wo wird der Name ohne die Certifier angezeigt?

Schau Dir doch einmal den Inhalt des Feldes ueber die Dokumenteneigenschaften an.
Steht auch hier der Name ohne drin?

Und wenn Du wirklich sicher sein willst, warum baust Du nicht noch ein @Name([...]; ...) mit ein?


Andreas

[Tode]

Wenn im Profildokument ein NAMENS- FELD ist, dann SIEHST Du zwar den Kanonischen Namen, gespeichert wird aber IMMER der volle hierarchische.

Deshalb im fall von Namens- Vergleichen IMMER ein @Name( [Abbreviate] ; ... ) oder @Name( [Canonicalize] ; ... ) um beide Seiten machen...

[mpausch]

@ascabg/Tode:

danke für die Hinweise. Wieder was dazugelernt.

in meiner Hide-Formel steht nun:

Code

!@IsMember(@UserName;@GetProfileField("pdoc";"Genehmiger"))

Jetzt funktioniert das Ausblenden der Schaltfläche.

[Tode]

Nein, Du hast NIX dazu gelernt.
Die Formel funktionier JETZT IM MOMENT (auch wenn das sicherlich die sicherste aller Möglichkeiten ist, weil Notes Namen intern immer Hierarchisch speichert)...
Aber Du kannst nicht garantieren, dass in Deinem doc immer der hierarchische Name steht (so lange das Feld nur übers frontend befüllt wird, ist das normalerweise schon so, aber was, wenn mal irgendein Agent das Feld korrigiert o.ä.)

So ist es im Normalfall sicher:

Code

!@IsMember(@UserName;@Name( [Canonical] ; @GetProfileField("pdoc";"Genehmiger") ) )

[koehlerbv]

Aber Du kannst nicht garantieren, dass in Deinem doc immer der hierarchische Name steht (so lange das Feld nur übers frontend befüllt wird, ist das normalerweise schon so, aber was, wenn mal irgendein Agent das Feld korrigiert o.ä.)

Ich sehe das nicht so, Torsten: In beiden Items sollte der kanonische Name stehen (sonst ist ja auch nicht garantiert, dass der AdminP ordentlich tut).
Und an dieses Schema hat sich auch der Agent zu halten. Tut er das nicht, dann sieht man gleich, dass da wer Sch****e baut - und bekommt als Gegenleistung auch keinen Namensverhau.

Just my 2cts,
Bernhard

[Tode]

Ja, bernhard, da verfolgen wir wohl zwei unterschiedliche Ansätze:
Ich fange gerne jeden möglichen (und unmöglichen) Fehler schon im Code ab, Auf die Gefahr hin, "schlechte Daten" zu tolerieren,
Du gehst davon aus, dass Daten immer so aussehen, wie sie aussehen müssen, und dass jeder
A) das weiss, was da drin stehen soll und
B) sich dran hält

Ich kenne leider zu viele (Kunden, Admins, Entwickler, bitte adäquates einfüllen), die das eben nicht machen, und sich mal eben ne Schaltfläche, nen Agenten, etc. Bauen um ein Feld zu korrigieren, oder ähnliches. Da ist es schnell passiert (ist session.Username abbreviated oder kanonisch?, ich meinte zweiteres, kann mich aber auch irren, und wenn ich einen namen aus einem bearbeitbaren Feld per strg +c kopiere ist in der zwischenablage auch der abbreviated name)

Ich verstehe und respektiere Deinen Ansatz, aber ich bin -was solche Dinge angeht- ein wenig paranoid... ;-)

[Peter Klett]

1:0 für Tode - grundsätzlich. Allerdings muss man auch den Kontext betrachten.

Hier ist es so, dass nur diejenigen einen Button zur Genehmigung eines Dokumentes angezeigt bekommen, die in einem Profildokument genannt sind. Ist die Abfrage nicht tolerant bzgl. falscher Namensformate, entsteht kein Schaden in der Anwendung. Trägt jemand mittels schlechtem Agenten ein falsches Namensformat in das Profildokument ein, ist der Button eben nicht sichtbar. Da kann ich Bernhards Herangehensweise gutheißen.

Im umgekehrten Fall, wenn z.B. eine Namensliste eine Blacklist darstellt, also alle die, die in der Liste stehen, dürfen den Button nicht sehen, sehe ich Todes Toleranzverständnis als absolute Pflicht.

Ein weiterer Aspekt ist die Frage nach dem "Dummen", der die Intoleranz ausbügeln muss. Liefere ich eine Datenbank und darf dann im Supportfall danach suchen, wo die, die "nichts verändert haben", herumgefummelt haben, und kann das womöglich noch nicht einmal dem Kunden gegenüber abrechnen, sollte ich mir solche Fallstricke nicht einbauen.

Daher: Tode, ich sehe das genauso, wie Du!

[Tode]

Sollte jetzt keine Grundsatzdiskussion werden, zumal ich Bernhard sehr schätze... Und EIGENTLICH sollten ja immer in allen Feldern saubere Werte drin stehen, so wie man das bei der Entwicklung der Anwendung mal gedacht hat, aber dieses Eigentlich hat mir schon so häufig -wie Peter schreibt unbezahlte- Stunden der Fehlersuche beschwert, dass ich da einfach (über)vorsichtig geworden bin und teilweise noch eine Abfrage einbaue in Fällen, wo es gar nicht sein KANN, dass da was falsches steht. Wie gesagt bin ich da etwas paranoid.

Aber wir sollten diese Diskussion -die sehr interessant und anregend ist- eventuell in einem Off- Topic- Thread weiterführen, denn dem Ersteller wurde ja geholfen, und hiermit hat das ja nix mehr zu tun...

[mpausch]

der "Ersteller" freut sich trotzdem über diese Off-Topic-Diskussion, da er in puncto Domino-Entwicklung noch ziemlicher Anfänger ist und deshalb jede Anregung und jeden Tipp gerne aufsaugt :-)

[koehlerbv]

Peter hat schon Recht - die Sache ist im Kontext zu betrachten. Sein Beispiel war da auch exzellent.

Prinzipiell gilt aber: Wer keine saubere Daten in eine Datenbank kippt, kann auch kein sauberes Ergebnis erwarten. Und wildgewordene "Programmierer", die sich mal fix einen datenmanipulierenden Agent schreiben, können ja auch Strings in Zahlenfelder schreiben (und sich dann wundern, dass die Ansicht nicht mehr richtig summiert) oder fett, rot, 16 pt. "Erst morgen!" in ein Datums-Item.
Abbreviated oder gar flache Namen kommen in Autoren- und Leserfeldern auch nicht immer gut ...

Bernhard