Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision Next revision Both sides next revision | ||
devel:documentation:roles:adm:role_assignment [2019/02/13 10:02] kotisovam created section moved from devel |
devel:documentation:roles:adm:role_assignment [2019/07/22 13:30] svandav [The approval process] |
||
---|---|---|---|
Line 1: | Line 1: | ||
===== Changing user permissions ===== | ===== Changing user permissions ===== | ||
- | |||
- | <note tip> | ||
- | |||
- | All permission changes must be made via the role request agenda (RoleRequest). | ||
===== Role request agenda ===== | ===== Role request agenda ===== | ||
Line 26: | Line 22: | ||
<note tip>If the user creates a new request but does not submit it, it will be displayed as " | <note tip>If the user creates a new request but does not submit it, it will be displayed as " | ||
- | {{:navrh:selection_060.png|}} | + | {{ :devel:documentation: |
<note important> | <note important> | ||
- | {{: | ||
==== Changing permission without approval ==== | ==== Changing permission without approval ==== | ||
Line 67: | Line 62: | ||
The agenda allows a direct request submission from a list of requests. The agenda also allows **creating a new request**, where the administrator must first choose the user who the request is being created for. | The agenda allows a direct request submission from a list of requests. The agenda also allows **creating a new request**, where the administrator must first choose the user who the request is being created for. | ||
- | |||
- | {{: | ||
In addition, the request detail in this agenda contains (compared to the end user request detail) a possibility of ticking that the request is not to be approved. The request detail also contains a **log**. This log contains all crucial information which occur during the life cycle of the request (errors, duplicates, request cancellation due to integrity, executed operations, etc.). | In addition, the request detail in this agenda contains (compared to the end user request detail) a possibility of ticking that the request is not to be approved. The request detail also contains a **log**. This log contains all crucial information which occur during the life cycle of the request (errors, duplicates, request cancellation due to integrity, executed operations, etc.). | ||
- | |||
- | {{: | ||
==== Integrity on remove contract or role ==== | ==== Integrity on remove contract or role ==== | ||
Line 97: | Line 88: | ||
- **Sending the notification**. | - **Sending the notification**. | ||
- **Realization of the request** - the realization itself is not carried out by the process, but by the service for managing requests for permission change. | - **Realization of the request** - the realization itself is not carried out by the process, but by the service for managing requests for permission change. | ||
+ | |||
+ | ====== System state ====== | ||
+ | |||
+ | The role request has a status item that identifies whether the request has already been executed. The **Executed** state in this case means that the request has been approved and the changes have been executed in IdM. **This state only reflects the state in IdM**. | ||
+ | |||
+ | This status does not cover a situation where some of the assigned roles create an account on a **system**. In this case, it may be important for the user to know the exact time the **account was successfully created**. Alternatively, | ||
+ | |||
+ | <note tip> | ||
+ | |||
+ |