The approval process

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

• 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".
  

  "Helpdesk" approval is disabled by default

  .

• 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".

.

• 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".

.

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".

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.

idm.sec.core.wf.role.approval.{priority}={wf}

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

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".

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

• 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".

.

• 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".

.

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.

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 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.

Authorization 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.