Modulrollen? Schwierige Entscheidung

In diesem Artikel wirde es um das Zusammenspiel zwischen Projektrollen und Modulrollen in Mendix Anwendungen gehen. Ein Thema das auf den ersten Blick ziemlich offensichtlich erscheint, aber auch erfahrene Entwickler zur Verzweiflung treiben kann. Aber fangen wir ganz von vorne an.

Was sind Projektrollen und Modulrollen?

Eine Projektrolle ist die Benutzerrolle die einem Benutzer zugewiesen wird. Diese Rolle trägt der Benutzer in der ganzen Anwendung. Modulrollen beziehen sich jedoch nur auf ein einzelnes Modul und sind nicht direkt Benutzern zugewiesen. Ein Benutzer selbst hat also keine, bzw. nur indirekt Modulrollen.

Die Beziehung zwischen Benutzer und der Modulrolle kommt dadurch zustande, dass die Projektrollen Modulrollen zugeordnet werden können. Dadurch bekommt ein Benutzer auch das Recht in einem bestimmten Modul Dinge zu tun, zu lesen, zu schreiben,…

Wäre es nicht einfacher nur Projektrollen zu haben?

Auf den ersten Blick mag es so erscheinen als würde das Zusammenspiel zwischen Modulrolle und Projektrolle der Anwendung unnötige Komplexität hinzufügen. In der Praxis entstehen hierdurch jedoch viele Vorteile. Die größten Vorteile sind sicher, dass man dadurch ein Modul auch in anderen Anwendungen wiederverwenden kann und dass man die Rechteverwaltung innerhalb eines Moduls einfach gestalten kann, selbst wenn sie in der gesamten Anwendung komplex ist. Dies erleichtert die Entwicklung.

Und wo ist jetzt das Problem?

Es gibt ein paar Fallsticke beim Anlegen von Modulrollen die unter Umständen eine Abwägung erfordern. Ich möchte gerne anhand eines (sehr konstruierten) Beispielprojektes darauf eingehen.

Betrachten wir eine Anwendung zur Mitarbeiterverwaltung innerhalb einer Firma. Unsere Anwendung erfasst zahlreiche Informationen zu unseren Mitarbeiten wie Vorname, Nachname, Monatliches Gehalt, Beginn des Arbeitsverhältnisses und einen Zufriedenheitsindex. Auf die Anwendung greifen verschiedene Personen zu die in der Anwendung verschiedene Rollen besitzen. Die wichtigsten sind Accounting, HR und OfficeFun.

Bei Accounting geht es in erster Linie um die Bezahlung der Mitarbeiter. Eine Information die Accounting aus Datenschutzgründen nicht sehen darf ist der Zufriedenheitsindex unserer Mitarbeiter. HR ist die Rolle die sowohl Vertragliches als auch Zufriedenheitswerte einsehen darf. Die OfficeFun Personen dürfen die Zufriedenheit der Mitarbeiter sehen, nicht jedoch auf ihre Gehaltsinformationen zugreifen.

Im wesentlichen haben wir nun also zwei Sichtbarkeiten. Eine davon regelt die Sichtbarkeit der Gehaltsdaten, die andere regelt die Sichtbarkeit des Zufriedenheitsindexes. Aus Modulsicht liegt es also nahe mit zwei Rollen zu arbeiten die nicht direkt im Zusammenhang mit den Projektrollen stehen. Betrachtet man gängige und bekannte Module wird dort oft genau so gearbeitet. Hier zum Beispiel die MxModelReflection:

Hier wird im wesentlichen zwischen dem Administrator des Moduls und allen anderen Benutzern die lesend darauf zugreifen wollen unterschieden. Im Falle der MxModelReflection ist das auch das einzig sinnvolle vorgehen. Es handelt sich um ein Marketplace Modul welches in einer Vielzahl von Anwendungen eingesetzt wird.

Mit dieser Information liegt es, wie bereits erwähnt, nahe, unserem Modul genau zwei Modulrollen zu geben. Das ganze würde dann wie folgt aussehen:

Die Zuordnung zu den Projektrollen würde in unserem Beispiel wie folgt aussehen:

Accounting hat die Modulrolle FinancialView, HR die Modulrollen FinancialView und SatisfactionView und OfficeFund hat lediglich die Modulrolle SatisfactionView.

Aus der Ebene der Zugriffsrechte ist dadurch alles geklärt und funktioniert wie es soll. Worum geht es jetzt hier also noch?

Stellen wir uns vor es gibt die Anforderung bestimmte Ansichten in das für alle gleiche Dashboard der Anwendung zu integrieren. Accounting soll eine Übersicht erhalten in der alle Mitarbeiter mit ihrem Gehalt aufgelistet sind. OfficeFun soll eine Ähnlich Ansicht erhalten, allerdings mit dem Zufriedenheitsindex. Wir können dies recht einfach lösen indem wir mehrere Ansichten auf der Seite platzieren und über visibility constraints ein- und ausblenden. Hierfür lassen sich die Modulrollen verwenden.

Meldet sich ein Accounting Mitarbeiter an wird folgende Ansicht eingeblendet:

Ein Office Fun Mitarbeiter würde diese Ansicht sehen:

Ein Problem wird sich allerdings ergeben wenn sich jemand von HR an der Anwendung anmeldet. Da HR beiden Modulrollen zugeordnet ist ergibt sich eine duplizierte Ansicht:

Natürlich ist dies ein sehr konstruierter, künstlicher Fall. Aber Probleme genau dieser Art finden sich regelmäßig in sehr vielen Projekten. Wenn die Anwendung schon länger in Entwicklung, oder vielleicht sogar live ist, so ist es schwierig die Rollen nochmal alle umzubauen. Die Sichtbarkeit in den Griff zu bekommen erfordert nun leider sehr viel Aufwand für einen Entwickler (Unterschiedliche Seiten pro Rolle, Helper Objects um die Visibility zu regeln,…).

Was bedeutet das jetzt für meine Anwendungen?

Wenn es darum geht zu entscheiden wie man seine Modulrollen gestaltet sollte man im wesentlichen zwischen zwei Arten von Modulen unterscheiden.

1. Generische Module die inhaltlich wenig bis gar nicht in die Anwendung integriert sind und die vergleichsweise einfach in anderen Anwendungen wiederverwendet werden können.
2. Module die inhaltlich sehr stark in die Anwendung integriert sind und bei denen es eher unwahrscheinlich ist sie in anderen Anwendungen wieder zu verwenden.

Bei ersteren Modulen (Als Beispiele dienen hier in der Regel die Marketplace Module wie MxModelReflection, XLS Report,…) sollte man auf eine Verzahnung zwischen Projektrollen und Modulrollen verzichten um die Wiederverwendbarkeit zu vereinfachen. Im Idealfall haben die Modulrollen keinen direkten Bezug zu den Projektrollen und tragen eher Namen wie Admin, User,…

Im zweiten Fall ist es meist Sinnvoller wenn die Modulrollen den Projektrollen exakt entsprechen. Dadurch lässt es sich vermeiden, dass einer Projektrolle mehrere Modulrollen zugewiesen sind. Hierdurch lassen sich Probleme wie das oben beschriebene leichter vermeiden aber auch die Performance der Anwendung kann davon profitieren. Hat man im Domain Model komplizierte XPATH Constraints, so müssen im Fall von mehreren Modulrollen pro Projektrolle auch alle rollenspezifischen Constraints angewendet werden. Im Falle von einer 1 zu 1 Zuweisung müssen allerdings nur die Constraints einer Rolle ausgewertet werden.

Fazit?!?

Auch wenn es auf den ersten Blick mehr Aufwand bedeuten mag eine Modulrolle pro Projektrolle anzulegen kann sich dies zu einem späteren Zeitpunk bezahlt machen und viele Probleme vermeiden. Insbesondere geänderte Anforderungen lassen sich hierdurch leichter durchführen, aber auch die Performance kann von einem solchen Design profitieren.

Umgekehrt lassen sich „unspezifische“ Module wesentlich einfacher exportieren und wiederverwenden wenn sie so wenig wie möglich (idealerweise gar nicht) mit dem eigentlichen Projekt verbunden sind.

Im Großen und Ganzen also der alte Rat: Erst denken, dann machen! 🤣

Ich hoffe das war für den ein oder anderen interessant. Wie immer freue ich mich über euer Feedback.