Manchmal ist es nötig Elemente in Service-Formularen, Previews oder Dialogen, abhängig von einer Benutzerrolle, Elemente dynamisch ein- oder auszublenden, bzw. diese mit einem Schreibschutz zu versehen. Aber wie ist es in Formularen eigentlich möglich herauszufinden, ob ein Benutzer Mitglied einer bestimmten Rolle ist?
Ganz einfach, mit dem Layout Designer & einer eigenen Datenquelle. Lass uns keine Zeit verlieren & direkt anfangen!
1. Feststellen, ob aktueller Benutzer Mitglied einer Rolle ist
Als Beispiel prüfen wir hier mal, ob der angemeldete Benutzer in der Administration-Rolle ist.
1.1 Auf ID oder Name prüfen
Zuerst müssen wir uns entscheiden, ob wir gegen ID der Rolle oder den Namen prüfen wollen. Beides hat vor und Nachteile, aber ehrlich gesagt ist es einfach eine sch**ß Idee, gegen Namen zu prüfen. Von daher suche ich mir hier erst mal die ID der zu prüfenden Rolle über die Dev-Tools raus, weil ich zu faul für das SQL-Management-Studio bin 😉
So, nun wissen wir, dass die Administrationsrolle die ID ‚a5d7b682-b211-4d94-a96d-8c57eedafdea‘ & die Expression-Objekt-ID (EOID) ’77d0396f-79b1-45fe-921c-f43eaf3b1845′ hat.
Ich empfehle dir, die EOID zu nehmen, da diese ja über alle Tabellen für dieses Objekt gleich ist.
1.2 Das ASQL Filterstatement
Nun müssen wir uns ein ASQL-Filterstatement zusammenbauen. Ich baue das natürlich nicht jedes Mal wirklich neu, sondern tausche die ID der Rolle aus 😉
[Expression-ObjectID] = '77d0396f-79b1-45fe-921c-f43eaf3b1845' and Members.ID = IDDesZuPrüfendenBenutzersDie ID des zu prüfenden Users ziehen wir uns später dynamisch im Formular (CurrentUser).
Statement im QueryAnalyzer
Falls du dich des Öfteren fragst, wie gewisse Felder in Dialogen eigentlich in der Datenbank heißen, siehst du hier, wie du Datenbank-Feldnamen über die UUX herausfinden kannst.
2. Dialog / Preview / Formular anpassen
Als Beispiel blenden wir hier einfach in der Preview von Personen das Beschäftigungsverhältnis für Nicht-Admins aus.
Das ganze funktioniert aber in jeder Preview und in jedem Dialog, auch in deinen eigenen Service-Formularen, Asset-Dialogen, etc.
2.1 Layout-Designer öffnen
Zuerst müssen wir die Preview im Layout-Designer öffnen.
2.2 Datenquelle hinzufügen
Nun fügen wir uns eine neue Datenquelle hinzu.
Mit dieser Datenquelle fragen wir im nächsten Schritt ab, ob der aktuelle Benutzer Mitglied der Rolle ist.
2.3 Filter einsetzen
Gut, nun haben wir eine Datenquelle in der Preview, die alle Benutzerrollen abfragen kann.
Um den Filter zu setzen, arbeiten wir mit der roten $filter Eigenschaft an der Datenquelle.
Diese Variable muss den Filter String von oben zurückgeben & den CurrentUser dynamisch einfüllen. Das Ganze machen wir im erweiterten Modus der $filter-Eigenschaft mit JavaScript String Concatenation:
return "[Expression-ObjectID] = 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX' and Members.ID = '" + currentUser.$value + "'";Video zum Hinzufügen des Filters
2.4 Boolesche Prüf-Variable erstellen
Klasse! Nun haben wir eine Datenquelle, die uns einen Treffer zurückliefert, sollte der Benutzer in der Rolle „Administration“ sein. Nun müssen wir nur prüfen, ob die Datenquelle mindestens ein Ergebnis zurückliefert und falls ja, eine (neue) Kontext-Variable auf True oder Flase setzen.
Da wir ja in unserem Beispiel ein Feld verstecken wollen, wenn der User kein Admin ist, muss der Wert unserer Booleschen Variable also True sein, wenn der Nutzer Admin ist. (Denn Sichtbarkeit = Ja, wenn Nutzer = Admin)
if (totalCount.$value && totalCount.$value > 0){
return true;
}
return false;Somit hat unsere Variable den Wert True, wenn die Datenquelle mindestens einen Treffer hat und der aktuelle Benutzer somit Mitglied der Admin-Rolle ist. Wenn nicht, ist die Varible False.
Falls du keine Booleschen Variablen magst, schau mal wie du Powershell-Arrays im Matrix42 Workflow Studio verwenden kannst 😉
2.5 Sichtbarkeit-Eigenschaft mit Attribut verknüpfen
Nun müssen wir diese Variable noch mit der Sichtbarkeit vom Feld Beschäftigungsverhältnis verknüpfen und das war’s auch schon.
Fertig
Geschafft! Nun ist das Feld dynamisch eingeblendet und die Preview sieht für Nicht-Admins so aus:
Lass uns gerne dein Feedback da, wir würden uns sehr freuen!
Vielleicht könnte mir jemand erklären, wie sich das mit den Anführungszeichen, Hochkommata und „+“ Zeichen verhält.
Da tue ich mich immer etwa schwer. Was bedeuten die einzelnen Zeichen in
‚“ + currentuser.$value + „‚“ ?
warum geht nicht einfach ein currentUser.$value?
Da würde er doch auch die ID zurück geben
Vermutung:
Die beiden einfachen Hochkommata, damit der Wert auch als Wert erkannt wird?
Warum noch die 3 Anführungszeichen?
Hey Andreas,
also das Problem mit diesen Hochkommas ist, dass ja am Ende des Tages, oder eher Skipts, ein ASQL-Filter zurückgegeben werden muss. Da in CurrentUser.$value nur die Id steht (XXXXXX-XXXX-XXXX-XXXXXXXX), ASQL aber die ID in Hochkomma (‚) benötigt, müssen wir diese eben über das JS davor und danach hinzufügen.
Somit sieht also das erzeugte Filter-Statement genau so aus wie hier.
Ich hoffe, das hilft und verwirrt nicht noch mehr 😉
Hilft. Danke für die Erklärung 🙂
BTW. Mega Seite. Hilft mir als Admin sehr und ich lerne richtig gute Feinheiten!!
Hi Andreas,
vielen Dank für dein Lob! Freut mich zu hören, dass es den armen Matrix42 Admins da draußen weiterhilft.
Ich kann nur sagen, es werden noch viele interessante Artikel zum Thema Matrix42 Service Management kommen. Da ist bestimmt noch viel für dich & deine Umgebung mit dabei.
Beste Grüße & danke für dein Kommentar!
Der Tipp mit dem Herausfinden der ID’s über die Dev Tools ist Gold Wert.
Danke dafür
Gerne doch! Schön, dass es geholfen hat 🙂
Ich habe gerade einen Knoten im Kopf. Wenn ich nur eine Custom_Datendefinition hinzufügen muss, habe ich kein Problem. Jetzt habe ich aber einen anderen Fall:
Ich habe in der SPSSecurityClassRole ein boolsches Attribut hinzugefügt.
(Ist diese Rolle eine IT Rolle, oder nicht)
Jetzt möchte ich die Sichtbarkeit so filtern, dass wenn der CurrentUser in einer non-IT Rolle ist, bestimmte Felder nicht sehen darf.
Ich filtere also in der zugefügten Custom_SPSActivityClassBase auf das aktuelle Ticket
Damit habe ich dann das aktuelle Ticket.
Nun kommt mein Problem.
Um auf die richtige ID der RecipientRole zu kommen (Ich brauche ja die ID der SPSSecurityClassRole, da dort mein bool Wert ist)
muss ich ja ausgehend von der ActivityClassBase (Die entsprechende RecipientRole ID) über die SPSScRoleClassBase gehen, um auf die richtige ID zu kommen (Matching hier: UsedInTypeSPSSecurityTypeRole)
Da habe ich gerade Fragezeichen.
Muss ich jetzt noch beide Datenquellen SPSSecurityClassRole und SPSScRoleClassBase hinzufügen?
Muss ich dann nochmals die $filter anpacken?
Wie sieht es bei den Filtern dann aus?
Muss ich dann z.B. im SPSScRoleClassBase Filter das Matching filtern?
So etwa!?
Wobei die recipientRole die Variable aus der ActivityClassBase wäre?
Oder bin ich auf dem Holzweg?
Hi Andreas,
dein Knoten im Kopf hat sich nun auf mich übertragen 😀
Also, was ich verstanden habe: Du hast in den Rollen ein Custom-Attribut ergänzt. Wenn ein User in einer Rolle mit diesem ist, soll was passieren.
Meine Frage ist nun, welcher User? Der angemeldete User (CurrentUser) oder der Verantwortliche eines Tickets (Recipient)?
Hi Simon,
dafür hat sich über das WE mein Knoten wieder gelöst.
Ja, es geht um den Current User.
Da muss ich ja gar nicht über mehrere Datenquellen.
Da gehe ich ja genauso im Filter über:
Hatte ne Blockade…..Alles gut.
Ich möchte dieses Beispiel wieder nutzen, für einen neuen Fall.
Jetzt möchte ich eine bestimmte Kategorie auswählen lassen, je nachdem in welcher Rolle sich der User befindet. Es handelt sich hier um Keyuser und es geht um insgesamt 4 verschiedene Rollen. Ich habe jetzt versucht 4 mal die Sicherheitsrolle als Source hinzuzufügen, jeweils den Filter mit der entsprechenden ID erstellt und jeweils einen Context mit totalCount…..angelegt.
Im Layout, in der Kategorie habe ich dann folgendes hinterlegt
if(Context1.$value == 1){ return "0b48035c-cfe3-eb11-2db8-005056acfbb9"; } if(Context.$value == 1){ return "7929f667-cfe3-eb11-2db8-005056acfbb9"; } return $value;Leider klappt das so nicht. Beim ersten User mit der ersten Sicherheitsrolle wird die richtige Kategorie gezogen. Bei User 2 mit Sicherheitsrolle 2 wird nicht die angegebene Kategorie, sondern die globale default Kategorie gezogen.
Gibt es einen besseren Weg vom CurrentUser die Sicherheitsrolle auszulesen und das in der Kategorie zu verarbeiten?
Hi Andreas 🙂
Entschuldige erstmal die späte Freischaltung, da hat was mit den Push-Nachrichten (an mich) nicht geklappt.
Zu deinem Thema: Ich würde das vom Funktionsaufbau her ähnlich machen, nur würde ich die Variablen noch auf falsy prüfen, also beispielsweise:
if(Context1.$value && Context1.$value == 1){Siehst du den in den Dev-Tools (F12 im Chrome), als der Konsole genauer gesagt, irgendwelche roten Fehlermeldungen?