In bestimmten Anwendungsfällen kann es vorkommen, dass Mitarbeitende (MA) in einem Projekt nur einzelne Dateien sehen und/oder bearbeiten dürfen, der Rest soll für sie unsichtbar bleiben. Gleichzeitig möchte die projektverantwortliche Person jederzeit einen Überblick haben, welchem MA sie an welcher Datei welche Rechte gegeben hat.
Der erste Gedanke ist ziemlich einfach umzusetzen: Es wird eine Rolle definiert, die ohne Rechte im Projekt ist, z.B. „GAST“. Das heißt bei der Produkttypendefinition wird der Rolle keine Beteiligungsart zugewiesen oder eine Beteiligungsart ohne jedes Standardrecht. Nun wird der/die MA im Projekt mit der Rolle „GAST“ aufgenommen und dann (rekursiv) einem Ordner oder einer Datei zugewiesen. Dort erhält er/sie die notwendigen Rechte:
Das hat allerdings zwei nicht zu unterschätzende Nachteile:
• Wie bekommt man eine Übersicht, welchem MA man bei welchen Dateien welche Rechte gegeben hat (und sind diese wirklich noch notwendig)?
• Es sind besondere Rechte notwendig: In der Dialogbox „Eigenschaften des Benutzers“ auf dem Register „Projekt“ im unteren Abschnitt „Rechte“ das Recht „Produkt-Rechte“ ändern setzen:
Welche Anforderungen sollen erfüllt und umgesetzt werden?
1. Es können für einzelne Dateien (Optional auch für Ordner rekursiv) für einen oder mehrere MA Lese- oder Schreibrechte vergeben oder wieder entzogen werden.
2. In einer Sicht muss sichtbar sein, für welche Dateien Rechte eingerichtet wurden.
3. Optional soll ein Recht mit der Freigabe der Datei wieder entzogen werden.
Kompliziert? Nein, mit ein wenig Konfiguration ist das fix gebaut. Was benötigt man dafür bzw. welche Schritte sind dafür notwendig?
1. Definition von Eigenschaften
a. Eigenschaft Typ „Mitarbeiter“ mit K = 1* für Leserechtvergabe
b. Eigenschaft Typ „Mitarbeiter“ mit K = 1* für Schreibrechtvergabe
c. Boolesche Eigenschaft als Optionsschalter, wenn Rechte nach Produkt-Freigabe entzogen werden sollen.
2. Anpassungen Zustandsautomat:
a. Unsichtbare Übergänge, die von den noch zu definierenden Formularen beim Schließen angesprochen werden: Dabei sollen die Rechte für die Standardrollen erhalten bleiben, dann werden alle weiteren Rechte erst gelöscht und für die Mitarbeiter aus den oben genannten Eigenschaften gesetzt.
b. Ergänzung des Freigabe-Übergangs: Wenn für das Dokument der Boolesche Übergang wahr ist, werden alle Rechte für die oben genannten Mitarbeiter-Eigenschaften gelöscht.
c. Übergang für Ordner: Kopieren der Eigenschaften vom Typ Mitarbeiter und die Boolesche Eigenschaft an die Kinder und dann Benachrichtigung an alle Kinder, analog zum einzelnen Übergang.
3. Aufbau von 2 Formularen („Vergabe Leserecht“ bzw. „Vergabe Schreibrecht“)
Jeweils mit Booleschem Schalter und Speichern mit Aktion. Wird in den Referenzfeldern für die einzuteilenden MA eine Sicht hinterlegt, die nur MA mit der Rolle GAST zeigt, können nicht versehentlich MA eingeteilt werden, die ohnehin höhere Rechte haben.
Die Umsetzung in in-STEP BLUE
Schritt 1: Definition der Eigenschaften
Wie im Kapitel davor gefordert, werden zwei Eigenschaften vom Typ Mitarbeiter benötigt und eine Eigenschaft vom Typ Boolescher Wert. Für dieses Beispiel wurden folgende drei Werte definiert:
Dabei ist es wichtig, dass die Gruppe (hier: 01A_DATEIRECHTE) dem MA mit der Rolle „GAST“ nur Leserechte an den Eigenschaften einräumt (Sonst könnte sich ein findiger MA selber aus Leserechten Schreibrechte machen).
Schritt 2: Anpassung des Zustandsautomaten
Schritt 2.1: Anpassung der Rechte
Hierfür ist nur ein Übergang notwendig: „Gastrechte vergeben (automatisch)“
Hinweis: Übergänge, die nicht sichtbar sind und z.B. über andere Übergänge oder von einem Formular aus ausgelöst werden, bekommen bei mir immer den Zusatz „(automatisch)“.
1. Zuerst werden alle (alten) Rechte gelöscht. Das ist notwendig, falls ein bestehender MA aus der Liste gelöscht wird, weil ihm die Rechte entzogen werden sollen.
2. Zuteilung der Leserechte an alle MA, die in der Eigenschaft „Leserecht“ stehen.
3. Zuteilung der Schreibechte an alle MA, die in der Eigenschaft „Schreibrecht“ stehen.
Je nach eigener Konfiguration kann hier noch etwas Finetuning notwendig sein. Gibt es noch eine Standardrolle „LESEBERECHTIGT“ und hat man diesen MA auch temporäre Schreibrechte gegeben, würden diese bisher hier nicht entfernt werden. In diesem Fall muss als erster Eintrag ergänzt werden:
Hinweis: Durch geschickte Einschränkung der Auswahl der MA im Formular auf die Rolle „GAST“ kann darauf verzichtet werden, siehe weiter unten.
Im einfachen Fall erfolgt das Löschen der gesetzten Rechte durch Aufruf des Dialogs und Herauslöschen der eingeteilten MA. Mit Rückgabe des Formulars werden alle Rechte gelöscht und dann wieder für die verbliebenen MA in den Eigenschaften gesetzt.
Schritt 2.2: Zustandsübergang entzieht Rechte
Für den Fall, dass z.B. bei einem Zustandsübergang („Freigeben“) die Rechte entzogen werden sollen, wird ein weiteres Ereignis definiert, das für einen Übergang benötigt wird.
Dieser Übergang wird nun z.B. beim Erreichen eines Zustandes aufgerufen:
Wird nun eine Datei freigegeben, benachrichtigt der Zustandsautomat sich selbst. Dabei prüft der aufgerufene Übergang „Gastrechte entziehen (automatisch)“, ob die Boolesche Eigenschaft EndWithRelease = TRUE ist. In diesem Fall werden alle Rechte gelöscht und die Eigenschaften vom Typ Mitarbeiter geleert.
Schritt 3: Gestaltung des Formulars:
Das Formular besteht aus zwei References und einer Checkbox:
Die beiden Referenz-Felder werden mit den Eigenschaften „Schreibrecht“ bzw. „Leserecht“ belegt. Dabei wird zur Auswahl möglicher MA eine Sicht hinterlegt, die nur MA mit der Rolle „GAST“ zeigt. Je nach Anforderung sind hier ggf. Anpassungen vorzusehen.
Sollen auch MA, die im Projekt als Standard Leserechte haben (Rolle: „LESEBERECHTIGT“) auch im Einzelfall Schreibrechte bekommen, muss der Filter entsprechend angepasst werden. In diesem Fall muss auch der Zustandsautomat für die Formularrückgabe-Aktion angepasst werden.
Zuerst müssen der Rolle „GAST“ alle Rechte entzogen werden, dann werden für die Rolle „LESEBERECHTIGT“ die Rechte „Schreiben“, „Löschen“ und „Endgültig Löschen“ entzogen. Anschließend werden wieder die Rechte für die beiden Referenzeigenschaften gesetzt. Allgemeiner kann man den Ablauf so formulieren: Erst alle veränderbaren Rechte entziehen, dann Standard-Rechte (für Rollen) wiederherstellen und Rechte nach Formular setzen.
Bonus-Frage: Geht das auch vom Ordner aus rekursiv?
Bei meinen Konfigurationen haben Ordner immer einen eigenen Produkttyp und somit auch einen eigenen Zustandsautomaten (ZA). Deshalb kann in diesem Fall das Formular den gleichen Übergang ansprechen, der aber hier Daten an die Subprodukte kopiert und dann die gleichlautende, oben beschriebene, Benachrichtigung sendet.
Sollte es sich um einen identischen ZA für Ordner und Dokumente gleichermaßen handeln, muss geprüft werden, ob das Produkt über Subprodukte verfügt. In diesem Fall wird die Kopie der Eigenschaften und die Benachrichtigung ausgelöst. Wenn kein Subprodukt vorliegt, wird nur der Übergang für das eine Produkt ausgeführt.
In meinem Test funktioniert es hervorragend! So kann es bleiben! Und doch ist es nicht perfekt.
Anwendungsfall: Im Ordner befinden sich als Beispiel drei Dateien. Die Rechte wurden über das Ordner-Formular verteilt. Die Option EndWithRelease wurde auf TRUE gesetzt. Die erste Datei ist nun freigegeben und die Rechte wurden wieder entzogen.
Nun muss aber eine weitere Datei aufgenommen werden und soll auch identische Rechte erhalten. Verteile ich die Rechte wieder über den Ordner, erhält auch die schon freigegeben Datei, der die Rechte entzogen wurden, wieder die Rechte gesetzt. (obwohl sie laut Zustandsautomat von keiner Rolle geändert werden kann).
Um für diesen Anwendungsfall gewappnet zu sein, ist eine kleine Anpassung notwendig. Meine Lösung sieht dann so aus: Einführung einer weiteren Booleschen Eigenschaft: SetNewRights. Startwert für einzelne Dateien ist diesmal TRUE. Mit der Freigabe einer Datei wird der Wert auf FALSE gesetzt.
Sobald das erste Mal von einem Ordner aus Berechtigungen vergeben wurden, wird der Wert für den Ordner auch auf FALSE gesetzt. Ein erneutes Senden von Rechten prüft nun zuerst, ob der Wert eines Produktes auf TRUE steht. Wenn nicht, wird das Produkt ignoriert.
Soll eine Neuvergabe der Rechte auch auf freigegebene Dateien erzwungen werden, muss über das Ordner-Formular der Wert SetNewRights wieder auf TRUE gesetzt werden. Mit dieser Einstellung wird nun zuerst an alle Subprodukte SetNewRights = TRUE kopiert, dann die anderen drei Werte, um am Ende die Subprodukte zu benachrichtigen („Gastrechte vergeben (automatisch)“).
Schritt 4: Die Sichten
Ziel dieser Konfiguration ist es, dass ein projektverantwortlicher MA jederzeit den Überblick darüber hat, welche MA an welchen Dokumenten welche Rechte besitzen. Standardmäßig sollen für die MA über die Sichten nur die Dokumente sichtbar sein, für die mindestens Leserechte bestehen. Der projektverantwortliche MA muss jedoch eine zusätzliche Listen- oder Ordneransicht aller Dokumente mit den Spalten Leseberechtigt („Lese-Recht”) und Schreibberechtigt („Schreib-Recht“) erhalten.
Das Ziel dieser Konfiguration ist es, dem projektverantwortlichen MA stets einen klaren Überblick zu ermöglichen, welche MA an welchen Dokumenten welche Zugriffsrechte haben.
Weitere Ideen zur Konfiguration
Um die Konfiguration nun nahezu perfekt zu machen, muss auch auf geänderte Eigenschaften reagiert werden können. Wenn also z.B. eine berechtigte Person die Spalte „Lese-Recht“ editiert, ohne das Formular zu benutzen, muss ebenfalls der Zustandsübergang „Gastrechte vergeben (automatisch)“ ausgelöst werden. Alternativ sind die Spalten so zu konfigurieren, dass sie nicht editiert werden können.
Fazit
Diese Konfiguration ist auf Grund einer Anforderung eines Projektmanagers entstanden, der in einem Dauerprojekt Rechte vergibt und wieder entzieht und sehen wollte, welche Dateien welche Benutzerrechte zusätzlich bekommen haben.
Vielleicht ist dieser Usecase auch für Sie interessant und diese Umsetzung hilfreich. Wenn Sie Fragen bezüglich der Toolfunktionen von in-STEP Blue haben, hilft Ihnen der Support von microTOOL gerne weiter.