Im Teil 2 dieses zweiteiligen Beitrags, wird die Umsetzung innerhalb von Microsoft Flow erläutert. Wie im Teil 1 bereits beschrieben, geht es um die Bearbeitung einer Liste mit GDPR relevanten Systemen in SharePoint Online. Die einzelnen Einträge müssen von verschiedenen Stellen genehmigt werden. Erst wenn alle Stellen genehmigt haben, ändert sich der Status auf „all approved“. Ist dies erfolgt, darf der Eintrag nur noch gelesen und nicht mehr geändert werden können.
Um dies zu erreichen, werden die Berechtigungen auf den jeweiligen Eintrag entsprechend angepasst. Die prinzipielle Vorgehensweise ist dabei wie folgt:
Ein paar Hinweis zum obigen Ablauf:
Die Ermittlung der Rollen Definition ID könnten wir auch weglassen, und die ID einmal ermitteln und hart codiert in den Flow eintragen. Wenn man den Flow allerdings auf eine andere Website übernehmen wollte, müsste man die ID wieder anpassen. Wir sind also durch die Ermittlung der Rollen Definition ID deutlich flexibler.
Um die Berechtigungen auf „nur lesend“ zu setzen, müssen zunächst alle bestehenden Berechtigungen entfernt werden. Dies geht am einfachsten, indem man zuerst die Berechtigungen aus der Bibliothek erbt, und dann die Vererbung wieder unterbricht und dabei die bestehenden Berechtigungen nicht mitkopiert. Deshalb sind im obigen Flussdiagramm jeweils eine Aktion für das Erben, und eine weitere für das Unterbrechen der Berechtigungen aufgeführt.
Notwendige REST API Calls ermitteln
Für die obigen Schritte können die folgenden REST API Aufrufe verwendet werden (siehe auch Teil 1):
Ermitteln der Role Definition ID für Read: _api/web/roledefinitions/GetByName(‚Read‘)/Id
Erben der Berechtigung: _api/web/lists/getByTitle(‚<Listenname>‘)/items(ID)/ ResetRoleInheritance()
Unterbrechen der Berechtigung: _api/web/lists/getByTitle(‚<Listenname>‘)/items(ID)/ breakroleinheritance(copyRoleAssignments=false, clearSubscopes=true)
Setzen der Berechtigung: _api/web/lists/getByTitle(‚<Listenname>‘)/items(ID)/ roleassignments/addroleassignment(principalid= <ID eines Benutzers oder SharePoint Gruppe>,roleDefId=<ReadRoleId>)
Neuen Flow anlegen
Im ersten Schritt legen wir einen neuen Flow aus der SharePoint Liste heraus an:
Dadurch erscheint eine Auflistung mit möglichen Vorlagen (Templates) auf der rechten Seite des Bildschirms. In unserem Fall wählen wir die Vorlage „when an existing list item is modified, complete a custom action“, da user Flow automatisch starten soll, wenn ein Element der Liste geändert wird:
Es wird nun Flow gestartet, und man wird ggf. zum Login aufgefordert. Danach wird noch einmal die Verbindung zu SharePoint Online gemacht, aus welchem heraus man den Flow erstellt hat. Durch Klick auf Continue landet man im Designer von Flow:
Die erste Aktion ist dabei die Triggeraktion auf unsere Liste:
Variablen definieren und setzen
Da wir die Role Definition ID für mehrere Aktionen brauchen, wird hierfür zuerst eine Variable definiert:
Sie wird später gesetzt und verwendet, sofern der korrekte Status des Elementes gesetzt ist.
Zwei weitere Variablen definieren die Site URL und den Namen der Liste. Dadurch kann unser Workflow sehr einfach auch auf andere Sites und Listen angewendet werden:
Bedingung hinzufügen
Nachdem der Flow für ein bestimmtes Element gestartet wurde, wird zuerst geprüft, ob ein das Feld System Status den Wert „all approved“ aufweist. Falls ja, sollen die Berechtigungen neu gesetzt werden. Die Aktion sieht in Flow wie folgt aus:
Role Definition ID für «nur lesend» ermitteln
Für den REST API Aufruf zum Setzen der Berechtigungen, wird die sog. Role Definition ID benötigt. Dahinter steckt die ID der Berechtigungsstufe in SharePoint. Für die Ermittlung dieser ID wird wiederum ein REST API Aufruf verwendet (/_api/web/roledefinitions/GetByName(‚Read‘)/Id). An diesem Aufruf soll nun die Verwendeung der Send an HTTP request to SharePoint demonstriert werden.
Zuerst wird die Aktion hinzugefügt:
Dann werden die Parameter gesetzt:
Titel anpassen: Get Role Definition ID for «Read”
Die URL der Website: Hier wird die zuvor erstellte Variable genutzt
Als Methode verwenden wir einen GET Request
Der URI des REST API Aufrufes: /_api/web/roledefinitions/GetByName(‚Read‘)/Id
Den Header, welchen wir an die REST API mitliefern wollen: accept; application/json;odata=nometadata
Im Flow Designer sieht das Ganze dann folgendermassen aus:
Als Ergebnis dieses Aufrufes der SharePoint REST API bekommen wir ein JSON Datenelement zurück. Wir brauchen allerdings nur die ID der Role Definition. Deshalb extrahieren wir die ID aus dem zurückgelieferten JSON und speichern sie in der zuvor angelegten Variable.
Für das Extrahieren von Daten aus JSON kann die Aktion parse JSON von Flow verwendet werden:
Diese Aktion bekommt als Eingabe die JSON Informationen aus der vorigen Aktion und definiert dazu ein Schema, um dies dann wieder in der nachfolgenden Aktion für den Zugriff zu verwenden. In unserem Fall sieht dies wie folgt aus:
Die Frage ist natürlich nun, wie man die Informationen zum Schema bereitstellen kann. Dies geht am einfachsten, indem man den Workflow ablaufen lässt, und die zurückgelieferten Daten der Aktion Get role definition für «READ» anzeigen lässt. Daraus erzeugt dann die Aktion parse JSON das jeweilige Schema.
Nach dem parsen des JSON Inhaltes kann man dann den Wert an die zuvor angelegte Variable zuweisen. Dies erfolgt mit Hilfe der Aktion Set variable:
Berechtigungen erben und wieder unterbrechen
Wie bereits oben erwähnt folgen nun zwei Schritte (Berechtigungen erben und Berechtigungsvererbung wieder unterbrechen), für die wiederum SharePoint REST API Aufrufe verwendet werden:
Für das Erben der Berechtigungen: _api/web/lists/getByTitle(‚<Listenname>‘)/items(ID)/ResetRoleInheritance()
In diesem Fall verwenden wir allerdings einen POST Request. Ansonsten ist die Vorgehensweise identisch zum obigen REST API Aufruf:
Für den URL der Site und den Namen der Liste verwenden wir die an Anfang definierten Variablen. Die ID des Elementes, welches geändert wurde, liefert Flow in der Variablen ID.
Die zweite Aktion unterbricht das Erben der Berechtigungen, ohne die gesetzten Berechtigungen zu übernehmen (copyRoleAssignments=false):
Berechtigungen setzen
Jetzt sind Vorbereitungen für das eigentliche Setzen der Berechtigungen abgeschlossen. Nun werden die neuen Berechtigungen jeweils für die Besitzer, Mitglieder und Leser Gruppe gesetzt. Dies erfolgt mit Hilfe des SharePoint REST API Aufrufes _api/web/lists/getByTitle(‚<Listenname>‘)/items(ID)/ roleassignments/addroleassignment(principalid=<ID eines Benutzers oder SharePoint Gruppe>,roleDefId=<ReadRoleId>).
Für die SharePoint Gruppe der Besucher sieht dies wie folgt aus:
Hinweis: Auf die Ermittlung der ID (in unserem Beispiel principalid=7) für die SharePoint Gruppe anhand des Namens durch einen API Aufruf wurde verzichtet. Sie kann sehr einfach ermittelt werden, indem man die Gruppe in der Website Einstellungen öffnet und in der URL die ID entnimmt.
Analog sehen die Aktionen für die Mitglieder und die Besitzer der Website aus:
Nachdem der Flow veröffentlicht wurde, ist dieser aktiv und setzt die Berechtigung beim Status «all approved» für alle SharePoint Gruppen auf «read»:
Gesamter Flow im Überblick
Um den Überblick zu behalten, ist nachfolgend der gesamte Flow noch einmal aufgeführt:
Fazit
Wie dieser zweiteilige Beitrag gezeigt hat, lassen sich fehlende Aktionen für die Interaktion mit SharePoint Online aus Flow heraus inzwischen sehr einfach mit der SharePoint REST API und der Nutzung der Aktion Send an Http Request to SharePoint von Flow umsetzen.
Zugegebenermassen erfordert es mehr Arbeit als die Nutzung von fertig bereitgestellten Aktionen. Jedoch ist die REST API von SharePoint inzwischen sehr umfangreich und man muss nicht warten, bis Microsoft eine bestimmte Aktion in Flow bereitstellt. Man baut sie sich einfach selbst.
Damit endet auch der zweite Teil dieses zweiteiligen Beitrages. Gerne dürfen Sie uns natürlich auch jederzeit kontaktieren, um mehr über die Möglichkeiten von Microsoft Flow + SharePoint zu erfahren.