tawiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Rechte auf Bereiche - Allgemeine Besprechung ======
===== Schreibrechte =====
Schreibrechte sind im Grunde einfach zu klären. Ein Benutzer braucht explizite Schreibrechte auf ein Business Objekt, um es ändern zu können.
===== Leserechte =====
Leserechte sind komplizierter, weil ein Business Objekt von anderen Business Objekten referenziert, bzw. verwendet werden kann. Ein volles Leserecht auf ein Business Objekt mit allen Details hat nur jemand, der ein explizites Leserecht auf das Business Objekt hat, genau wie bei den Schreibrechten. Was von dem Business Objekt darf aber jemand sehen, der es sich aus dem Kontext eines anderen Business Objektes anguckt?
==== Leserechte auf referenzierte Daten eines Business Objektes ====
Angenommen es gibt Mitarbeiter mit allen möglichen Eigenschaften, wie z.B. dem Namen, der Personalnummer, der Gehaltsstufe, einer Organisationsrolle, usw. In der Projektverwaltung kann ein Mitarbeiter einem Projekt als Projektmitarbeiter zugeordnet werden. Es stellen sich nun zwei Fragen:
  - Welche Eigenschaften der zugeordneten Mitarbeiter darf jemand mit Leserechten im Projekt sehen?
  - Welche Mitarbeiter darf jemand mit Schreibrechten im Projekt auswählen, und was darf er zum Zwecke der Auswahl sehen?
Es stellt sich zudem die Frage, //wer// das bestimmt? Bestimmen das die Rechte aus dem //Mitarbeiter Kontext//, oder die aus dem //Projekt Kontext//? Um das zu klären, nehmen wir einfach mal an, dass der Mitarbeiter Kontext von dem Projekt Kontext nichts weiß, der Projekt Kontext aber vom Mitarbeiter Kontext abhängig ist, eben weil man Mitarbeiter einem Projekt zuordnen kann. Nun sollte es klar sein, dass die Rechte im Projekt Kontext bestimmen, was die Antworten auf die Fragen 1. und 2. sind. Der Projektkontext hat dabei die Möglichkeit, eigene Rechte zu definieren, oder aber die Rechte im Mitarbeiter Kontext zu verwenden, da dieser Kontext ja voraus gesetzt wird!

----
Das ist oft der Fall, dass z.B. in diesem Beispiel der Projekt Kontext die Rechte aus dem Mitarbeiter Kontext verwendet, z.B. dass man die Mitarbeiter in Projekten hinzufügen kann, auf die man volle Leserechte im Mitarbeiter Kontext hat. Das führt dazu, dass man glaubt, die Leserechte im Mitarbeiter Kontext bestimmen die Zuordbarkeit von Projektmitarbeitern. Das ist aber nur deshalb so, weil der Projekt Kontext das so bestimmt. Bestimmend bleibt der Projekt Kontext. 
=== Antwort auf Frage 1 ===
Das entscheidet einzig und alleine der Projekt Kontext. Der Mitarbeiter Kontext könnte die Eigenschaften, die an andere Kontexte freigegeben sind, einschränken, z.B. sollen andere Kontexte keine Gehalts relevanten Daten sehen. Aus diesen u.U. eingeschränkten Eigenschaften kann der Projekt Kontext nun die wählen, die für einen Projektleiter mit Leserechten relevant sind.
== Module ==
Wenn die unterschiedlichen Kontexte lediglich Module eines allgemeinen Kontextes sind, gibt es die theoretische Möglichkeit, dass man eine Rückkoppelung vom Projekt Modul zum Mitarbeiter Modul baut. Angenommen jemand hat im Mitarbeiter Modul keine allgemeinen Leserechte auf Mitarbeiterdaten, und wenn er die Mitarbeiter Liste aufruft, ist sie leer. Im Projekt Modul erhält er nun Leserechte auf bestimmte Projekte, in denen er nun bestimmte Eigenschaften von Mitarbeitern sehen darf. Wenn diese Eigenschaften eine Obermenge der Eigenschaften in der Mitarbeiter Liste im Mitarbeiter Modul bilden, dann hat der Anwender im Grunde ja Leserechte auf einige Mitarbeiter in der Mitarbeiter Liste im Mitarbeiter Modul. D.h. ein Autorisierer aus dem Projekt Modul könnte die Mitarbeiter in Projekten des Anwenders der Mitarbeiter Liste im Mitarbeiter Modul hinzufügen, die Rechte im Mitarbeiter Modul im Grunde erweitern.
\\ \\
Das hat aber nur Sinn, wenn es sich um echte //Module// eines gemeinsamen //Kontextes// handelt, oder zumindest einer gemeinsamen //Anwendung//((in diesem Fall könnte ein Modul einen eigenen Kontext darstellen)). Auf jeden Fall müssen die Module die Möglichkeit haben, miteinander zu kommunizieren, speziell muss ein Modul die Autorisierer des anderen verwenden können.
\\ \\
Das klingt erst mal unnötig kompliziert. Aber angenommen, aus dem Mitarbeiter Stammblatt kann man über eine Projekt Komponente den Mitarbeiter weiteren Projekten zuordnen. Es wäre dann doch sinnvoll, dass ein Projektleiter in der Mitarbeiter Liste zumindest die Mitarbeiter sehen kann, die bereits in seinen Projekten sind, um diese auswählen zu können. Anders herum wäre es verwunderlich, wenn er diese Mitarbeiter zwar in seinem Projekt sieht, nicht aber in der Übersichtsliste der Mitarbeiter.
\\ \\
Die Entscheidung ist also((für meine Anwendungen)), das so kompliziert umzusetzen, weil es absolut Sinn hat!
=== Antwort auf Frage 2 ===
Auch dieses kann nur der Projekt Kontext beantworten. Im einfachsten Fall sind es die Mitarbeiter, auf die der Projektleiter im Mitarbeiter Kontext bereits Leserechte hat. Es können aber mehr oder weniger als diese Mitarbeiter sein. Auch die Eigenschaften, die der Projektleiter von den Mitarbeiter zum Zwecke der Auswahl sieht, bestimmt der Projekt Kontext((aus den vom Mitarbeiter Kontext freigegebenen Eigenschaften)).
\\ \\
Es ist einzig und alleine den Anforderungen an die Anwendung und der Fantasie des Entwicklers überlassen, welche Mitarbeiter ein Projektleiter auswählen darf. Vielleicht hat ein Projektleiter ein ganz bestimmtes Pool an Mitarbeitern, aus dem er wählen darf. Vielleicht darf er nur Mitarbeiter aus seiner Organisationseinheit auswählen. Vielleicht darf er alle Mitarbeiter seinen Projekten zuordnen, völlig unabhängig davon, ob er im Mitarbeiter Kontext Leserechte auf die Mitarbeiterdaten hat.
\\ \\
Das ist somit eine Fall-zu-Fall Entscheidung, über die man keine Allgemeine Aussage treffen kann. Wie bei den Leserechten können aber auch die im Projekt Kontext definierten Auswahlrechte auf Mitarbeiterdaten die Leserechte auf Mitarbeiterdaten im Mitarbeiter Kontext erweitern.
tawiki

User Tools

Site Tools

Page Tools
