Workaround für "@UserNamesList "?

[botschi]

Hallo,

ich habe mir schon oft gewünscht eine Formel oder eine Funktion zu kennen, die mir zu einem Namen das gleiche Ergebnis liefert, wie @UserNamesList.

Kennt jemand eine Funktion oder einen Workaround für die Formel?

Danke für Hinweise!

Matthias

[m3]

ich habe mir schon oft gewünscht eine Formel oder eine Funktion zu kennen, die mir zu einem Namen das gleiche Ergebnis liefert, wie @UserNamesList.

@UserNamesKist IST doch eine Formel-Function. Ich versteh Dich nicht. 

[botschi]

Mein Ziel ist es, nicht für den aktuellen Bearbeiter die Rollen, Verteiler usw zu ermitteln, sondern für einen Namen.

Mit @UserNamesList kann ich nur für den aktuellen Benutzer was ermitteln.
Das "@UserNamesList(Bearbeiter_aus_Feld_XYZ)" geht nicht.

Deswegen wollte ich etwas für Script haben oder eine Formel wenn es die gibt, die mir für irgendeine Person die Rollen usw liefert, wie @UserNamesList für den aktuellen Bearbeiter.
@UserRoles ist genau so ein Fall. Wirklich ne tolle Formel, aber leider nur für den aktuellen Bearbeiter und nicht für jemanden, den ich per Paramter übergebe.

Matthias

[Axel]

Versuch's doch mal mit Evaluate.

varResult = Evaluate("@UserNamesList")


Axel

[botschi]

Ich möchte ja nicht meine Rollen, sondern die des Eröffners aus dem Feld "Eröffner".
Und
varResult = Evaluate("@UserNamesList; ERÖFFNER")
funktioniert nicht...

Hintergrund:
Wenn der Eröffner in der Gruppe "XYZ" ist, dann mach was.
Wenn der Eröffner die Rollen [A], oder [C] hat, mach auch was.

Wie soll ich das machen?

[klaussal]

Geht das evtl. hiermit ?

roles = notesDatabase.QueryAccessRoles( name$ )

[Axel]

So wie du UserNamesList einsetzen willst geht das nicht. UserNamesList liefert Infos auch nur über den aktuellen Benutzer.

Auszug aus der Hilfe:

In einer Datenbank auf dem Server oder einer lokale Datenbank mit der Eigenschaft "Konsistente ACL über alle Repliken dieser Datenbank erzwingen" gibt @UserNamesList eine Textliste zurück, die folgende Informationen über den aktuellen Benutzer enthält:

Axel

[koehlerbv]

Auf diesen Fakt aus der DesignerHelp hat Matthias aber schon hingewiesen:

Deswegen wollte ich etwas für Script haben oder eine Formel wenn es die gibt, die mir für irgendeine Person die Rollen usw liefert, wie @UserNamesList für den aktuellen Bearbeiter.

Mit Klaus' Vorschlag sollte man am bequemsten vorankommen. Was die Gruppenzugehörigkeit angeht, so bieten sich mehrere Wege an: Wenn das Recht lt. ACL schon Indiz genug ist, dann die Methode QueryAccess. Ansonsten muss man den aufwändigeren Weg nüber ACL und Domino Directory gehen.

Bernhard

[botschi]

Das meine ich ja. Das geht mit @UserNamesList eben nicht und das finde ich sehr schade.
Kennt denn jemand einen Workaround?
Jetzt haben wir es glaube ich 

Und Das hier
roles = notesDatabase.QueryAccessRoles( name$ )
geht nur, wenn die Person in der ACL steht. Wenn der User in einer Gruppe ist, hat man damit auch verloren... 

[Axel]

Ihr hab ja so recht. 

Das kommt davon, wenn man mehrere Sachen gleichzeitig macht.


Axel

[Tode]

@botschi: Wie soll man Dir helfen, wenn Du die Hilfe nicht annimmst?

Auszug aus der Designer- Hilfe zum Befehl QueryAccessRoles:

Usage
If the name you specify is listed explicitly in the ACL, then QueryAccessRoles returns the roles for that ACL entry and does not check groups.
If the name you specify is not listed explicitly in the ACL, QueryAccess checks to see if the name is a member of a group in the primary address book where the program is running: on a workstation the Personal Address Book; on a server the Domino Directory.

HTH
Tode

[koehlerbv]

A-Bär: Es gibt massive EInschränkungen, die den Einsatz häufig verbieten:
- User A hat keine Rolle B, ist aber zusätzlich Mitglied der Gruppe X, die diese Rolle hat
- Sowie der Code auf einer Workstation ausgeführt hat, bleibt das Domino Directory unberücksichtigt.

Bernhard

[botschi]

Das denke ich eben auch, dass QueryAccessRoles "gefährlich" ist.
Ihr habt sicher mehr Erfahrung und schon genügend Fallen umfahren, deshalb glaube ich es Euch ja wenn ihr sagt, "nimm QueryAccessRoles".
Es muss mir aber auch erlaubt sein darauf hinzuweisen, dass ich schon schlechte Erfahrungen mit QueryAccessRoles gemacht habe und es deshalb nicht mehr nutze...

Ich denke sogar, dass es eine Frechheit ist, dass es diese "gefährliche halbfertige-Methode" noch gibt. Aber das ist ansichtssache und muss hier nicht weiter behandelt werden.

Wenn man im Vorwege so ein Konzept erstellt hat, dass man die Rollen des Eröffners nicht braucht, ist ja alles gut. Leider gibt es halt manchmal Dinge, die sich ändern...

Matthias