====== The approval process ======

If the request-permission-change-without-approval mode is not used, process "approve-identity-change-permissions" will be started.

====Approval by the helpdesk department====

  * The approving task will be assigned to all users with role **Helpdesk**.
  * The role can be changed in the application configuration "**idm.sec.core.wf.approval.helpdesk.role**", the default setting is **Helpdesk**.
  * The approval round can be enabled or disabled in the application configuration under key "**idm.sec.core.wf.approval.helpdesk.enabled**".
  
<note important>"Helpdesk" approval is disabled by default</note>.

====Approval by the manager====

 * The approving task will be assigned to all users evaluated as the managers of the applicant. The manager is defined based on the industrial relations of the applicant.
  * The approval round can be enabled or disabled in the application configuration under key "**idm.sec.core.wf.approval.manager.enabled**". 

<note important>Approval by the manager is disabled by default</note>.

====Approval by the user administration department====

  * The approving task will be assigned to all users with role **Usermanager**.
  * The role can be changed in the application configuration "**idm.sec.core.wf.approval.usermanager.role**", the default setting is **Usermanager**.
  * The approval round can be enabled or disabled in the application configuration under key "**idm.sec.core.wf.approval.usermanager.enabled**".

<note important>Approval by the user administration department is disabled by default.</note>.

====Execution of approving subprocesses====

Every constituent role being requested (change or assignment) can be approved separately. Due to that, a separate subprocess is always run for every role.

If the role is evaluated as not requiring approval, default process "**change-role-without-approve**" is run. This process only generates the name (it is saved in the history of workflow processes) and changes the state of the role concept to "**APPROVED**".


===Setting of the approval process to a role===
The approval process (for assigning or changing an assigned role) is set to the role by setting the relevant priority. The role's priority can have values (0,1,2,3,4), where every priority can be assigned a different approval process.

The specific priority assignment and the type of approval process is defined in the application configuration.

<code>
idm.sec.core.wf.role.approval.{priority}={wf}
</code>

,where {priority} is the **priority number** and {wf} is the key of the process workflow.


<note important>There is only one process approving removal of assigned roles for the whole application (all priorities). Again, it can be defined in the application configuration under key "**idm.sec.core.wf.role.approval.remove**". The default process is "**approve-remove-role-by-manager**" </note>

<note tip>To make removing of a role approved, it is necessary that the role item "**Approve role removal**" is ticked.</note>

**The default setting of priorities and approval processes is as follows**:

  * **No priority (0)**:
No approval takes place. The process "**change-role-without-approve**" is run (see above).

  * **Trivial priority (1)**:
Approval by the manager of the applicant "**approve-role-by-manager**".

  * **Low priority (2)**:
Approval by the guarantee of the role "**approve-role-by-guarantee**".

<note tip>This process supports approving for change automatic role.</note>

 * **High priority (3)**:
Approval by the role guarantee and by the security department "**approve-role-by-guarantee-security**".

<note tip>This process supports approving for change automatic role.</note>


====Approval by the security department====

  * The approving task will be assigned to all users with role **Security**.
  * The role can be changed in the application configuration "**idm.sec.core.wf.approval.security.role**", the default setting is **Security**.
  * The approval round can be enabled or disabled in the application configuration under key "**idm.sec.core.wf.approval.security.enabled**".

<note important>Approval by the security department is disabled by default</note>.

====Approval of role incompatibilities====
  * First is checking, if exists in the current request some incompatibilities of roles. Incompatibilities are searched only for new added roles (not disapproved) in the request. If no incompatibilites are found, then is this user task skipped.
  * The approving task will be assigned to all users with role **Incompatibility**.
  * The role can be changed in the application configuration "**idm.sec.core.wf.approval.incompatibility.role**", the default setting is **Incompatibility**.
  * The approval round can be enabled or disabled in the application configuration under key "**idm.sec.core.wf.approval.incompatibility.enabled**".

<note important>Approval of role incompatibilities is enabled by default</note>.

====Automatic skipping of approval processes====
Automatic skipping of approval processes is performed if the request **realizator** (the one who really submitted it) is the same user as the **currently logged-in** user and, at the same time, is among the **candidates** who can approve this task. In that case, the task is skipped with the same result as if it was approved manually.

==== Approve, disprove task by task detail ====
To task detail is possible to get from url in notification (email and etd.), after click to url in notofication you will be redirected to task detail. After aprove, disaprove or go back you will be redirected to all your tasks. When is reopened already denied or approved task, user recive information about nonexisting or solved task.


==== Sending notifications ====
Sending notifications is by default enabled just to notify user just about his change of permissions. Sending notifications can be modified with two global boolean variables, which specify sending notifications.

  * '**idm.sec.core.wf.notification.applicant.enabled**' by default is false and it configure sending notifications to user, whose permissions will be modified. But if it is user, who requested change role to his own permissions, he is implementer too. So if this variable is false and the other is true, user is still implementer and will receive notification. But if both are true, user will get just 1 notification.
  * '**idm.sec.core.wf.notification.implementer.enabled**' by default is true and it configure sending notification to user, who made request on behalf another user. For example, when manager request role for employee in his department and wants to know the result.


===== Security =====
Authorization [[authorization#selfrolerequestevaluator|policies]] are implemented fo role requests agenda. Concept role requests are secured by assigned role request internally. Only identity with authority ''ROLEREQUEST_ADMIN'' can read all concepts without filter by role request through the ''IdmConceptRoleRequestController''.