Workflow Rechte per Skript setzen? Change workflow permissions by script?
Author: matthiasforberg
Publication Date: 1/26/2024 15:57
Hallo,
in einem Workflow soll abhängig von einer Auswahl jeweils eine andere Benutzergruppe die Freigabeanforderung bekommen. Die Auswahl für die Gruppe kann ich bereits per Workflow-Skript auslesen, aber ich finde keine Möglichkeit, die Rechte zu ändern.
Ich hole mir alle Transitions des Workflows und prüfe, ob diese über Freigaberechte geschaltet werden:
if (trans.useStoreElementRights() && trans.getUsedStoreElementRights() == Permission.CAN_RELEASE) {...}Wenn das erfüllt ist, möchte ich die jeweilige, im vorigen Schritt ermittelte Benutzergruppe für diese Transition(s) als "FixedRights" setzen. Aber es gibt keine Setter für die Transition.
Ist das irgenwie möglich oder ist die Workflow-API immer noch read-only (wie in 21652 erwähnt)?
Eine andere Möglichkeit wäre noch, für jede Gruppe eine Weiche in den WF einzubauen, was es aber etwas unübersichtlich macht, da es mehrere Schleifen sind, die geändert werden müssten.
Oder Duplizieren des Workflows für jede Freigabegruppe... auch nicht sehr elegant.
Welche Möglichkeiten habe ich, das zu steuern?
Grüße
Matthias
-----
Hello,
In a workflow, different user groups should receive the release request, depending on a selection at the beginning of the Workflow. I can already read the group selection using a workflow script, but I can't find any way to change the rights on the transitions.
I iterate all transitions of the workflow and check whether they are activated via release rights:
if (trans.useStoreElementRights() && trans.getUsedStoreElementRights() == Permission.CAN_RELEASE) {...}If this is true, I would like to set the particular user group determined in the previous step as "FixedRights" for this transition(s). But there are no setters for the transition.
Is this somehow possible or is the workflow API still read-only (as mentioned in 21652)?
Another possibility would be to install a switch in the WF for each group, but this makes it a bit confusing as there are several loops that would have to be changed.
Or duplicating the workflow for each release group... not very elegant either.
What options do I have to control this?
Greetings
Matthias
-
Author: hoebbel - 7/10/2024 10:31
Hallo Matthias,
da die Anfrage schon ziemlich alt ist und ich nicht weiß, ob das Problem für Dich noch existiert, hier nur ein allgemeiner Hinweis.
Wenn ich es richtig verstehe, geht es doch hier darum, dass abhängig davon, wo ein Workflow ausgeführt wird, andere Rechte für Transitionen gesetzt werden sollen.
Dann wäre in meinen Augen der richtige Weg, die Rechte auf dem entsprechenden Knoten zu setzen (und nicht die Rechte im Workflow selber zu ändern)
Da gibt es dann aber noch eine Falle, in die ich in der Vergangenheit mal gestolpert bin - man muss beim Speichern auch die Vererbung der Workflowrechte brechen, sonst wird nicht gespeichert.
Hier ein einfaches Codebeispiel, um den Weg aufzuzeigen, den ich meine. Das Beispiel ist für deinen Anwendungsfall aber natürlich nicht ausreichend, da Du ja die TransistionPermissions setzen willst und nicht wie im Beispiel die allgemeinen Zugriffsrechte für den Workflow). Ich gehe aber davon aus, dass wenn ich es richtig verstanden habe, das Beispiel ausreichen sollte, um das Problem zu lösen - sofern es überhaupt noch besteht
import de.espirit.firstspirit.access.store.Store; userService = context.getUserService(); pageStoreFolder = context.getElement(); pageStoreFolder.setLock(true, false); workflow = userService.getStore(Store.Type.TEMPLATESTORE, true, false).getWorkflowByName("release"); wfpermission = pageStoreFolder.getCreateWorkflowPermission(workflow); group = context.project.getGroups().get(0); wfpermission.allowGroup(group); pageStoreFolder.setWorkflowPermission(wfpermission); pageStoreFolder.setInheritWorkflowPermission(false); pageStoreFolder.save("Saved Workflow rights", false); pageStoreFolder.setLock(false, false);Viele Grüße
Holger0 -
Author: matthiasforberg - 7/19/2024 9:30
Hallo Holger,
vielen Dank für die Antwort, aber die Freigabeanfrage soll nicht abhängig davon sein, WO eine Seite liegt (dann ist klar, dass die Berechtigungen zu verwenden sind), sondern davon, was ein Redakteur auswählt. Die sollen selbst entscheiden, ob die Prüfung z.B. von der Marketingabteilung oder einem Teamleader oder an die Online-Chefredaktion gehen soll. Und nur diese sollen dann auch benachrichtigt werden. Hier beispielhaft mit Gruppen A, B, C:
Da diese Gruppen ziemlich fest sind, habe ich die jetzt einfach als Weichen in den Workflow eingebaut, d.h. ich habe den Teil, wo die Genehmigung stattfindet verdreifacht. Direkte Freigabe gibt es auch noch, aber nur noch für Admins und Mitglieder der Gruppe A. Alle anderen müssen an eine der Release-Gruppen senden:
In den Transitionen "Trigger check" sind dann fest die jeweiligen Gruppen hinterlegt anstatt "aus dem Objekt über Freigabe". Funktioniert.
Jetzt haben wir nur noch das Problem, dass die User der externen Gruppen (LDAP) keine E-Mails bekommen, aber da werden wir uns mit Mailverteilern behelfen. Anders geht's wohl nicht, da der Workflow die Mailadressen nicht aus dem Keycloak auslesen kann (wurde mir zumindest so gesagt).
Viele Grüße
Matthias0 -
Author: hoebbel - 7/19/2024 9:47
Hallo Matthias,
dass an Mitglieder externer Gruppen keine direkten Mails versendet werden können, ist korrekt. Das Problem hier ist, dass bei der Anmeldung eines Nutzers die [temporäre] Zuordnung zu einer externen Gruppe erfolgt. Die externe Gruppe selber kennt keine Benutzer - und jeder Benutzer kennt nur die externen Gruppen, die für ihn zum Zeitpunkt der letzten Anmeldung gültig waren.
Ändert sich also im externen System etwas, wird diese Änderung erst wirksam, wenn der User sich das nächste Mal bei FirstSpirit anmeldet.Was aber geht ist es, dass externen Gruppen Mailverteilern zugeordnet werden, an die dann automatisch die entsprechenden Emails verschickt werden. Ich nehme an, dass Du das mit deiner Antwort gemeint hast, erwähne es aber sicherheitshalber nochmal
Viele Grüße
Holger0
Please sign in to leave a comment.
Comments
3 comments