Die „Display Rules“ und „Enable Rules“ in der Ribbon-Bar sind ja schon bekannt. Sie sind auch wirklich sehr flexibel und bieten viele Möglichkeiten, einzelne Buttons in der Ribbon-Bar situationsabhängig anzuzeigen und an- oder auszuschalten. Aber diese Flexibilität birgt auch Risiken. Es gibt viele Wege ans Ziel und ich will nun nicht sagen, dass mein Weg der beste Weg wäre. Ich möchte eher nur ein paar Ideen vorstellen, wie man diese schnell und effektiv abfragen kann und mir schon in einigen Projekten geholfen haben.
Dabei will ich mich auf die Anzeige eines Buttons in Abhängigkeit der Rollen und Rechte des angemeldeten Benutzers konzentrieren. Damit ist gemeint, dass ein Knopf nur dann sichtbar ist, wenn der Benutzer über bestimmte Rechte oder eine gewisse Rolle verfügt.
Alternativ gibt es auch den Blick aus der Sicht des einzelnen Datensatzes. Dabei wird ein Knopf in Abhängigkeit bestimmter Daten, also genauer, Werte in bestimmten Attributen, angezeigt. Das wird mein Kollege Adrian Schäfer genauer vorstellen.
Zur Pflege der entsprechenden Rules benutze ich hier die Ribbon Workbensch 2016 aus der XRM Toolbox. Wir wollen uns ja nicht in den Tiefen des XML verlieren.
Definition der Regeln
Wenn ich nun einen Button abhängig von einer Rechte oder Rollen Situation ausblenden möchte oder ggf. nur inaktiv schalten möchte, so dass der Anwender ihn noch sieht, aber keine Aktion ausgelöst wird, dann muss ich diese so genannten Rules hinterlegen. Um welche Funktion es sich handelt ist für diese Betrachtung irrelevant. Die Regeln können an jedem Button hinterlegt werden.
Display Rules
Die Display Rule hat u.a. (siehe Liste im Bild links) die EntityRule, diese ist aber „nur“ dafür da, eine entsprechende Entität zu identifizieren. Also „wo“ sind wir gerade.
Wichtiger ist für unseren Fall hier die EntityPrivilegeRule! Diese ermöglicht es uns zu entscheiden, ob ein Button angezeigt wird, abhängig von dem Recht auf einer(!) Entität, nicht unbedingt der Entität, auf der wir den Button gerade sehen!
In meinem Fall ist hier also die Regel „true“, wenn der Anwender auf der Entität „Kontakte“ (contact) das unternehmensweite Schreib-Recht hat. Dies könnte also ein „Fachadmin“ sein.
Enable Rules
Die Enable Rule bringt und nun noch eine RecordPrivilegeRule, also die Rechte, bezogen auf genau den im Form angezeigten Datensatz (Record).
Hier habe ich z.B. den Wunsch, dass man den Datensatz zuweisen darf (assgin-Recht). Sonst ist der Button nicht aktiv.
Performance
Jetzt mag der eine oder andere denken, dass diese Überprüfungen doch auch recht einfach mit einer CustomRule gut zu erledigen sind. In einer CustomRule kann man wunderbar ein JavaScript aufrufen und hat dann alle Freiheiten der Welt. Das ist an sich richtig. Nur wie ich in einigen Projekten erleben musste, braucht man dann manches Mal auf „alle Zeit der Welt“. OK, ich übertreibe, aber je nach Komplexität der Überprüfung uns Schritte in diesem Script können da schon deutlich Verzögerungen eintreten.
Also wenn man beispielsweise in einem Skript erst noch schauen möchte, welche Sicherheitsrollen der aktuelle Benutzer hat. Dann müssen weitere Abfragen gegen das CRM durchgeführt werden, die Zeit brauchen. Für den Anwender äußert sich das z.B. in einem anfänglich sichtbaren und dann plötzlich verschwindenden Knopf. Kein schöner Effekt.
Wenn man nun statt dieser Abfragen auf die Sicherheitsrollen ein Recht auf einer Entität abfragen kann, dann geht das ganze schon viel schneller.
Die Idee
Nutzen Sie für diese Rollenüberprüfung doch eine Dummy-Entität?! Was meine ich? Na, es wird einfach eine Entität erstellt, die nie Daten beherbergen soll. Aber es wird einfach je nach Rolle ein Lese-, Schreib- oder Löschrecht vergeben. Dann muss ich nicht schauen, ob ein Anwender diese Rolle hat, sondern nur, ob er z.B. die Dummy-Entität löschen dürfte. Und wenn das nur mein „Fachadmin“ darf, dann bin ich schon fertig und weiß auch, dass er den Button sehen und drücken darf. Voila! 😊
Fallstricke
Was kann einem in diesem Zusammenhang passieren, wenn man die einzelnen Regeln auf den Buttons einsetzt? Hier möchte ich einen Fehler beschreiben, den ich sehr lange suchen musste, da er nicht unmittelbar zu finden ist und auch ein Trace oder die Analyse mit Fiddler nicht direkt zu einem Hinweis geführt hat. Bei mir zumindest leider nicht.
Es geht um Script-Fehler im Java-Script einer CustomRule, also einem Absprung in ein Script in einer Web-Ressource, in dem leider selbst noch ein Fehler steckt. Diese Fehler scheint Dynamics nämlich wunderbar zu unterdrücken. Somit kommt es zu keinem Feedback mit dem Anwender und er weiß nicht, dass was schief gegangen ist. Wenn dann auch noch der Default für die Rule ein false wäre, würde der Button nie wieder am Formular erscheinen.
Weitere interessante Blog-Artikel zum Thema "Arbeiten mit Microsoft Dynamics CRM":
Teilen
Microsoft Dynamics 365 CRM: Buttons ein- und ausblenden mit der Ribbon Workbench
Wie Sie den Berichtsassistenten in Microsoft Dynamics 365 CRM nutzen können.
