Differences

This shows you the differences between two versions of the page.

Link to this comparison view

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/23 08:16]
svandav [The approval process]
Line 1: Line 1:
 ===== Changing user permissions ===== ===== Changing user permissions =====
- 
-<note tip>Introduction to the topic - [[../..:role_change|read here]].</note> 
- 
-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 "**Concept**" in the table "**Unfinished requests for permission change**" in the assigned roles tab. Thus they can return to an unfinished concept.</note> <note tip>If the user creates a new request but does not submit it, it will be displayed as "**Concept**" in the table "**Unfinished requests for permission change**" in the assigned roles tab. Thus they can return to an unfinished concept.</note>
  
-{{:navrh:selection_060.png|}}+{{ :devel:documentation:roles:adm:reqeust-table.png?800 |}}
  
  
 <note important>The request can be submitted only when the request is in the "**CONCEPT**", "**DUPLICATED**" or "**EXCEPTION**" states</note> <note important>The request can be submitted only when the request is in the "**CONCEPT**", "**DUPLICATED**" or "**EXCEPTION**" states</note>
  
-{{:navrh:selection_059.png|}} 
 ==== 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.
- 
-{{:navrh:selection_061.png|}} 
  
 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.).
- 
-{{:navrh:selection_067.png|}} 
  
 ==== Integrity on remove contract or role ==== ==== Integrity on remove contract or role ====
Line 83: Line 74:
 <note important>It means if a current process task contains a decision with ID '**disapprove**', then it is used. When a disapproval decision is not found, the standard cancellation of process is called.</note> <note important>It means if a current process task contains a decision with ID '**disapprove**', then it is used. When a disapproval decision is not found, the standard cancellation of process is called.</note>
  
-====== The approval process ======+===== The approval process =====
  
 If the request-permission-change-without-approval mode is not used, process "approve-identity-change-permissions" will be started. If the request-permission-change-without-approval mode is not used, process "approve-identity-change-permissions" will be started.
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, if there is an error on the system, it is good to know this information in **the role request** itself.
 +
 +<note tip>These requirements solve the **system state**. Which represents how the implementation of the request on systems has ended.</note>
 +
 +
  • by husniko