Die Schreibrechte sind einfach geklärt, da man explizit angibt, wer welche Mitarbeiterdaten verändern darf¹⁾.

Die Leserechte sind komplizierter. Man kann jemanden über die allgemeine Rechterolle das Leserecht auf alle Mitarbeiterdaten geben. Was, wenn ich Rechte auf Teams oder Klienten habe, und darüber Leserechte auf die dem Team, bzw. dem Klienten zugeordneten Mitarbeiterdaten habe? Im Team und im Klienten kann ich dann zumindest schon mal einige Mitarbeiter sehen, zumindest ihre Namen.

Hier sind wir beim ersten Punkt. Welche Mitarbeiterdaten darf ich im Team und im Klienten von den zugeordneten Mitarbeitern sehen? Es darf sich dabei nicht um schützenswerte Daten der Mitarbeiter handeln, und im Grunde auch nur um Daten, die jemand, der Leserechte auf Mitarbeiterdaten hat, benutzen kann, um die Mitarbeiter in der realen Welt zu identifizieren. Andererseits soll ich über die Daten sehr wohl identifizieren können, um wen es sich in der realen Welt handelt, zumindest bei internen Daten. Wenn auch externe Mitarbeiter zugeordnet werden können, muss man sie u.U. nicht identifizieren können.

Bei Mitarbeitern einer Einrichtung gehen wir somit von internen Daten aus. In dem Fall ist der Name des Mitarbeiters nicht schützenswert, und ich soll die Person über den Namen auch identifizieren können. Wenn ich ein Team Mitglied mit Leserechten auf die Mitarbeiter-Team Zuordnung bin, dann hat das Leserecht nur Sinn, indem mir die Team-Mitarbeiter auch etwas sagen.

Der Mitarbeiter Name als nicht schützenswertes, identifizierendes Merkmal, ist ein wichtiger Aspekt in der Autorisierung von Mitarbeiterdaten. Diese Tatsache sollte u.U. im Zusammenspiel mit anderen Modulen und auch Systemen berücksichtigt werden. Diese Systeme dürfen den Mitarbeiternamen nach eigenem Ermessen nutzen, und auch Leserechte darauf frei vergeben. Es muss darauf geachtet werden, dass Mitarbeiter, die nicht sehen dürfen, wer noch so alles im Mitarbeiter Stamm vorhanden ist, keine Rechte auf die Daten erhält. Wenn aber ein Mitarbeiter einen anderen auswählen können soll - und somit Leserechte erhält - weil er ihn zum Zwecke der Zuordnung benötigt, dann muss dieser Mitarbeiter sehen dürfen, wer noch im Unternehmen tätig ist. Wobei man auch das noch über Organisatorische Strukturen einschränken kann.

Das Team ist dabei bereits eine Organisatorische Struktur, und vielleicht darf der Teamleiter neue Mitarbeiter zuordnen, und somit auch alle Mitarbeiter der Einrichtung sehen dürfen, ein Berater im Team darf aber nur die Mitarbeiter in seinem Team sehen. Er soll aber vielleicht nicht sehen dürfen, wer Bezugsbetreuer der Klienten ist - das ist vielleicht dem Teamleiter vorbehalten²⁾.

Wenn man den Namen des Mitarbeiters als nicht schützenswertes, identifizierendes Merkmal des Mitarbeiters ermittelt hat, und in der Mitarbeiter Liste lediglich den Mitarbeiter Namen anzeigt, kann man in dieser Liste alle Mitarbeiter anzeigen, auf die der angemeldete User Leserechte auf den Namen hat. Dabei handelt es sich um:

• alle Mitarbeiter, wenn man das allgemeine Leserecht auf die Mitarbeiterverwaltung hat,
• alle Mitarbeiter der eigenen Teams in denen man Leserechte auf Mitarbeiterdaten hat,
• alle Betreuer von Klienten für die man Leserechte auf die zugeordneten Betreuer hat,
• alle aktiven Mitarbeiter, sollte man die uneingeschränkten Zuordnungsrechte von Mitarbeitern in Teams haben, bzw. für Klienten.

Technisch ist die Mitarbeiter Liste eine stark typisierte Abfrage³⁾, mit stark typisierten Daten⁴⁾. Das heißt, dass die Erweiterung des Ergebnisses der Liste über die Leserechte auf Teamdaten nicht in dem Sinne gefährlich ist, dass man, sollte man die Eigenschaften erweitern, die in der Liste angezeigt werden, plötzlich über ein Recht, über das man nur den Namen sehen können soll, nun auch andere Mitarbeiterdaten sehen kann. Wenn sich die Liste erweitert, würde sich die Projektion ändern, bzw. man würde eine neue Projektion dafür bauen, und die Autorisierer der Komponenten müssten die neue Projektion und Abfrage neu autorisieren - oder auch nicht.

Alternativ kann man die Mitarbeiter Übersicht unterteilen in “Verwalten”, “Mitarbeiter meiner Teams”, “Betreuer”, usw., wobei jede Liste als Komponente aufgebaut wird und die Daten so detailliert darstellt, wie es in dem Bereich erlaubt ist.

Wenn man nun das Stammblatt eines einzelnen Mitarbeiters aufruft, auf den man über einen der oben genannten Wege Leserechte hat, kann man im Stammblatt auf jeden Fall den Namen des Mitarbeiters sehen. Die weiteren Bereiche werden als Komponenten im Stammblatt aufgebaut. Jemand, der alle Mitarbeiter der eigenen Teams einsehen darf, wird den Mitarbeiter Namen sehen, und einen Reiter⁵⁾ der Teams des Mitarbeiters, wobei hier nur die eigenen Teams des angemeldeten User zu sehen sind⁶⁾. Die Anzahl der sichtbaren Komponenten hängt somit von den Leserechten des Mitarbeiters in den unterschiedlichen Bereichen ab.