====== Delegation ======
{{tag>delegation}}
The aim of delegations is to transfer approval tasks to another solver. We divide delegations into **automatic** and **manual**.
===== Automatic delegation =====
In automatic delegations, a rule is first created according to which tasks are automatically delegated. A typical example is **the user's departure on holiday**.
In this case, the user creates a delegation, where he selects the validity of the delegation and the delegate (the user to whom the tasks will be moved).
From the moment the created delegation is valid, tasks will be delegated to the delegate.
{{ :devel:documentation:adm:new-delegation.png?600 |}}
==== Delegations on the user detail ====
A new delegation tab has been added to the user detail. Here the user can create a new delegation and above all he sees an overview of all his delegations and also the delegations that delegate to him.
{{ :devel:documentation:adm:use-delegation-tab.png?800 |}}
All types of delegations are displayed here, including manually delegated tasks.
As a **delegator**, a user can select any user to whom he has the **autocomplete right** (he can select it in the selectbox).
==== List of delegated tasks ====
In the detail of the delegation it is possible to see all tasks that have been delegated within the given delegation. Ie. as a user you have an overview of how many tasks have been delegated and in what state they are now.
The state can take the following states:
* **In progress** - The task was delegated and isn't completed yet.
* **Executed** - The task was delegated and completed.
* **Canceled** - The task was delegated and canceled (workflow was deleted).
{{ :devel:documentation:adm:delegation-instances.png?800 |}}
==== Delegation type ====
The type of delegation we chose when creating the rule determines which tasks will be delegated.
**In the product are by default three delegation types:**
* **Default delegation for all tasks** - It will be used for all tasks for which no other delegation is defined (with a more specific type).
* **Tasks approving role assignments by a manager** - This type is used exclusively for tasks that are created as part of a role assignment approval workflow (**approve-role-by-manager**). This type is unique due to the definition of the delegate not only by the user but also by his contract. Thanks to this, we are able to create delegations for each delegator's contract. This will ensure that the resulting delegate will be selected on the basis of the delegator's contract (where the applicant's contract will be subordinate to the delegator's contract).
* **Manual task delegation** - It is created automatically on using the delegate operation over the agenda of assigned tasks. **This type cannot be selected manually by user.**
The relation between a specific type of delegation and a workflow process is realized by modifying the definition of workflow, where it is possible to add code of the type of delegation, according to which we want the tasks of the process to be delegated. If the workflow process does not contain any delegation type or there is no delegation definition for it, then delegations are searched for the default delegation type (**Default delegation for all tasks**).
For example workflow process **approve-role-by-manager** contains this delegation type:
approve-role-by-manager-delegation-type
The default delegation type delegates all **approval tasks**.
===== Manual delegation =====
{{tag>manual delegation}}
**Manual** delegation allows a user to **reassign** his tasks to **someone else**. Are available as a **bulk operation** on the **agenda of assigned tasks**.
{{ :devel:documentation:adm:reassing-bulk-action.png?600 |}}
Manual delegation can also be used in the **administrator mode**, where the user has the right to see all unresolved tasks, all users. In this mode, it must be clearly defined who is the **delegator** for the selected tasks.
To do this, the administrator can use a **filter**, where he selects only one user whose tasks he wants to delegate. If this filter is used, the delegator will be pre-filled according to it after starting the bulk operation. The second option is to select the delegator manually.
Here it is important to remember that only those selected tasks will be reassign, where one of their solvers is the **chosen delegator**.
{{ :devel:documentation:adm:tasks-all.png?800 |}}
Manual delegations **use the standard delegation** agenda. This means that if the bulk operation reassign a task, a delegation definition will be created corresponding to this reassing. This new definition will contain a delegator and a delegate, depending on the settings of the bulk operation. Next, a link will be created between the definition and the task being reassigned.
The purpose of creating a definition and link to a task is to provide a history and **provide a clear overview of tasks that have been delegated to users** and that they have delegated.
{{ :devel:documentation:adm:tasks-my.png?800 |}}
Within each task delegation, a **notification** is sent to the task delegate, which informs him of the new task.
This notification is sent to the **topic**: `core:delegationInstanceCreatedToDelegate`.
{{ :devel:documentation:adm:reassing-notification.png?800 |}}
If the user has the right to **read the task**, he has the **right to delegate** it.
Tasks can be delegated to any user who can be selected in the select box. In other words, the user can delegate to a user to whom he has the **autocomplete** permission.
===== Authorization policies =====
Default settings of permissions for delegations are defined in the role '**Delegation (delegationRole)**'.
You can see a detailed configuration of evaluators with comments here:
[[https://github.com/bcvsolutions/CzechIdMng/blob/develop/Realization/backend/core/core-impl/src/main/java/eu/bcvsolutions/idm/core/model/event/processor/module/InitDelegationRoleProcessor.java#L106-L202
|InitDelegationRoleProcessor]]
===== Future improvements =====
The manually created delegation definition should be deleted after deleting the last link to the task.
After reassigning the task, also send a notification to the delegator.
===== Limitations =====
By default (in standard process for **change permissions**), the rule is that if the logged-in user is the implementer of the request (the one who submitted it) and at the same time is one of approvers, then this task is **skipped** (approval is assumed). However, **this rule does not apply in the case of delegation** (ie if the delegate is both the approver and the implementer, the task will be created and assigned).
If one approval task is delegated more than once, or for more approvers, then **only the last delegation's business card** is displayed in the task detail.
**Delegation works only on first level**. So if user **A** delegates to user **B**, and at same time user **B** delegates to user **C**, then it doesn't mean that all tasks from **A** are now delegated to user **C**!
===== Main guide =====
* [[..:delegation|]]