Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
devel:documentation:roles:dev:universal_requests [2018/10/24 12:20] tomiskar |
devel:documentation:roles:dev:universal_requests [2021/03/09 11:12] husniko [Workflow process for roles] |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Agenda of universal requests ====== | ||
+ | {{tag> | ||
+ | |||
+ | ===== How it works? ===== | ||
+ | When the approval mode is turned on, it is not possible to edit the object over the standard **REST** interface (for example ' | ||
+ | |||
+ | |||
+ | < | ||
+ | |||
+ | From a **UI** perspective, | ||
+ | **An object can only be edited after you have moved to a specific request URL**. | ||
+ | |||
+ | |||
+ | < | ||
+ | |||
+ | Example of a URL role and the same role edit role within the request: | ||
+ | |||
+ | * **/ | ||
+ | * **/ | ||
+ | |||
+ | ==== Creation of a request ==== | ||
+ | |||
+ | If you want to go to the above mentioned URLs, **you will first need to create the request**. This can be generated by calling the **method on the REST request interface of the object**. This is a **POST** method where a single entry is the **object for which we want to create a request**. This input object may not exist in the database (for a situation where we want to create a new object within the request). | ||
+ | |||
+ | **Example** creating a **request** for a new **role**: | ||
+ | |||
+ | < | ||
+ | curl ' | ||
+ | </ | ||
+ | |||
+ | |||
+ | ==== Creation of request items ==== | ||
+ | |||
+ | If we already have a request, we can start making individual **changes**. As described above, individual **REST** request calls are " | ||
+ | |||
+ | Additionally, | ||
+ | |||
+ | < | ||
+ | |||
+ | |||
+ | ===== How to enable the possibility of requesting a specific object? ===== | ||
+ | <note important> | ||
+ | |||
+ | Requesting mode can be enabled for every supported object by property in the application configuration: | ||
+ | |||
+ | < | ||
+ | idm.pub.core.request.< | ||
+ | </ | ||
+ | , where **< | ||
+ | |||
+ | <note tip>For example **approving for role** (IdmRoleDto) can be enable by this property: | ||
+ | |||
+ | < | ||
+ | idm.pub.core.request.idm-role.enabled=true | ||
+ | </ | ||
+ | |||
+ | |||
+ | ===== Supported requestable objects ===== | ||
+ | All supported objects must implemented interface `eu.bcvsolutions.idm.core.api.domain.Requestable`. | ||
+ | * IdmRoleDto - **Roles** | ||
+ | * IdmRoleCompositionDto - **Business roles** | ||
+ | * IdmRoleGuaranteeDto - **Guarantee defined by identity** | ||
+ | * IdmRoleGuaranteeRoleDto - **Guarantee defined by other role** | ||
+ | * IdmAuthorizationPolicyDto - **Premissions** | ||
+ | * IdmRoleCatalogueRoleDto - **Relations on the catalogue** | ||
+ | * SysRoleSystemDto - **Linking the system to a role** | ||
+ | * SysRoleSystemAttributeDto - **Overloaded system attribute** (on the role) | ||
+ | * IdmFormValueDto - **Extended attributes** | ||
+ | |||
+ | |||
+ | ===== Workflow processes ===== | ||
+ | Each requestable type of object may have its own approval process. | ||
+ | The approval process can be defined in the application configuration: | ||
+ | |||
+ | < | ||
+ | |||
+ | **Example for IdmRole**: | ||
+ | |||
+ | < | ||
+ | |||
+ | <note tip>If none workflow process is defined, then ' | ||
+ | |||
+ | ==== Workflow process for roles ==== | ||
+ | The basic approval process where changes on the role are approved by the guarantors of the role in request. If there are no guarantors or a new role, then those who have the role defined in the variable ' | ||
+ | |||
+ | < | ||
+ | |||
+ | {{: | ||
+ | |||
+ | ==== Workflow process for business roles ==== | ||
+ | If the request contains a item with **business role** change (**IdmRoloComposition**), | ||
+ | This process aims to verify whether the guarantors of the target role agree with the change. This means that if we put **B** role to role **A**, guarantor of the role B must agree with this assignment. The same applies to the removal of the relation. **If the target role has no guarantors**, | ||
+ | |||
+ | {{: | ||
+ | |||
+ | |||
+ | ==== Configurable role guarantor type for role change request ==== | ||
+ | {{tag> | ||
+ | By default a role is approved by any guarantor defined for that role. **If you need to restrict approval to only guarantors with a specific type**, then you can use the configuration item **idm.sec.core.request.idm-role.approval.guarantee-type**, | ||
+ | |||
+ | If the value is not defined or item does **not exist**, then **all guarantors are used for approval**, regardless of what type they have defined. The described behavior is the same for guarantors defined by **identity** or **role**. | ||
+ | |||
+ | <note tip>**By default**, this configuration item (**idm.sec.core.request.idm-role.approval.guarantee-type**) is empty. This means that approval will be run with all guarantors (regardless of their type).</ | ||
+ | ===== Limitations ===== | ||
+ | <note warning> | ||
+ | <note warning> | ||