Role request policies allow extended configuration to determine if role assignment request is submitted to a validation or not. There are 3 types of workflow strategy available when configuring a role request policy:
-
None: the assignment operation will be performed without approbation.
-
Fixed: This strategy allows to define a workflow for all assignment of a role
-
Example: When Bob request role E the same workflow 1 should always be triggered.
-
-
Mapped: This strategy allows to define different workflows depending on an attribute of the requester, the beneficiary, the role, or the publication.
-
Example: When John request role G for himself, workflow 2 should be triggered if John has a CDI contract type and workflow 3 should always be triggered in other cases.
-
-
Script: This strategy allows to define the workflow that will be used with a groovy script.
-
Example: When Andrea request role B or C which are of the same type:
-
For Role B
-
Workflow 4 should be triggered if the beneficiary has a CDI contract type
-
Workflow 5 should always be triggered in other cases.
-
-
For Role C
-
Workflow 6 should be triggered if the beneficiary has a CDD contract type
-
No workflow should be triggered in other cases.
-
-
-
There is a workflow strategy for each action on role assignment (creation, update, deletion). Thus, depending on needs, we could configure:
-
A fixed workflow strategy to define a unique workflow to be triggered when adding role J to an identity
-
A mapped workflow strategy to trigger a workflow 1 when updating role J assignment of an identity in some condition and workflow 2 in other condition
-
No workflow when revoking role J assignment of an identity