Arbeiten mit Microsoft Dynamics 365: Ribbon – Display & Enables Rules

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.

(Bildquelle: Canva)

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.

Microsoft Dynamics 365 bietet dir durch seine hohe Flexibilität die Möglichkeit, dein Lead- und Kundenmanagement perfekt auf deine individuellen Anforderungen abzustimmen und damit deinen Erfolg auf das nächste Level zu heben.

Als langjähriger Microsoft-Partner mit viel Erfahrung unterstützen wir dich dabei, das volle Potenzial dieser leistungsstarken Plattform auszuschöpfen. Mit unserem engagierten Support und unserer Expertise in der Weiterentwicklung von Microsoft Dynamics 365 sorgen wir dafür, dass du jederzeit optimal aufgestellt bist – für mehr Effizienz, bessere Kundenbindung und nachhaltiges Wachstum.