Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
devel:documentation:roles:adm:role_assignment [2019/07/23 08:43]
svandav [Running state] 		devel:documentation:roles:adm:role_assignment [2020/02/17 20:27] (current)
husniko [Role deletion]
Line 90: Line 90:
  
 ====== System state ====== ====== System state ======
 +
 +{{tag>system state request}}
  
 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**. 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**.
Line 98: Line 100:
  
 ==== Running state ==== ==== Running state ====
 +{{tag>virtual}}
  
 Some of the provisioning operations is not completed. Some of the provisioning operations is not completed.
Line 104: Line 107:
  
 {{ :devel:documentation:roles:adm:request-inprogress.png?800 |}} {{ :devel:documentation:roles:adm:request-inprogress.png?800 |}}
 +
 +**Second** situation when could be request in running state is if role assign **the virtual system**.
 +
 +If the request assign or changes an account on the virtual system, then the virtual system creates a request by default, pending implementation by the appropriate implementer. Our request to change roles will be in a running state until all possible requests on virtual systems are resolved. The purpose of this wait is to ensure that the final notification of the completion of the request is sent after the real implementation of the requirements on the systems representing the virtual systems.
 +
 +In this situation has system state **RUNNING** orange color and show message: **Some requests on this vritual systems [Name of vritual systems] are not resloved!**.
 +
 +{{ :devel:documentation:roles:adm:request-inprogress-on-vs.png?800 |}}
 +
 +If the request contains **pending virtual system requests**, the 'status on the systems' will be set to executed only if all virtual system requests will be **resolved**. This means that they will either be successfully approved or will be rejected by implementer. If the virtual system request is rejected, the status on the request item will be set to **CANCELED**.
 +
 +{{ :devel:documentation:roles:adm:request-detail-canceled-on-vs.png?800 |}}
  
 ==== Failed state ==== ==== Failed state ====
  
-Some of the provisioning operations failed.+Some of the **provisioning operations failed**.
  
-This is typically a situation where the connector throw an exception. If you click on the status, you will see information on which systems have failed.+This is typically a situation where the connector throw an exception. If you click on the status, you will see information on **which systems have failed**. 
 + 
 +If the request contains an error, the status on the systems will be set to executed only if all errors are resolved. This means that they will either be successfully executed (for example by retry mechanism) or will be canceled. If the operation is canceled, the status on the request item will also be set to **CANCELED**.
  
 {{ :devel:documentation:roles:adm:request-failed.png?800 |}} {{ :devel:documentation:roles:adm:request-failed.png?800 |}}
 +
 +=== Detail of failed request ===
 +
 +On the detail of a request that has provisioning errors, the **roles that connect the system to which the error occurred are marked with a specific error**.
 +
 +If one role assigns more than one system and an error occurs on both, **error for only one system will be displayed**.
 +
 +If the entire request contains only one provisioning error, the log of that error is displayed on the request detail (**Error log from a systems**).
  
 {{ :devel:documentation:roles:adm:request-failed-detail.png?800 |}} {{ :devel:documentation:roles:adm:request-failed-detail.png?800 |}}
  
-In the provisioning operations agenda, all operations that were created under a given request have a link to that request (key icon).+==== Blocked state ==== 
 + 
 +Some of the **provisioning operations were blocked**. 
 + 
 +This is typically a situation where some system has blocked write operations. The behavior in this case is very similar to the case when the provisioning operation is in the error. If you click on the status, you will see information **which systems are blocked**. 
 + 
 +If the request contains a blocked operations, the status on the systems will be set to executed only if all blocked operations will be resolved. This means that they will either be successfully executed or will be canceled. If the operation is canceled, the status on the request item will also be set to **CANCELED**. 
 + 
 +{{ :devel:documentation:roles:adm:request-blocked.png?800 |}} 
 + 
 +==== Not executed state ==== 
 +This state is **very similar to the case when the provisioning operation is blocked**. Occures where system is seta to **read only** mode. 
 + 
 +===== Role deletion ===== 
 +Role is allowed to be deleted only if it is not assigned to any identity. This requirement is checked during prevalidation process and user is informed about this. Another provided information pertains to the number of role request concepts from which a reference to the deleted role needs to be removed. This additional information is for user useful because deletion of even single role which was previously assigned to many (assume hundreds) identities may take long time. This warning is currently displayed if number of request concepts to modify exceeds 100 items. Images below are only for illustration and don't take this into account. 
 + 
 + 
 +{{ :devel:documentation:roles:adm:delete_role_prevalidation.png?400 |}} 
 + 
 +Results of actions connected with the process of role removal are still possible to see in **Audit** tab. We can see here that role deletion was accompanied with role removal from 4 role request concepts. 
 +  
 +{{ :devel:documentation:roles:adm:delete_role_audit_summary.png?1000 |}} 
 + 
 + 
 +===== Link to request ===== 
 + 
 +**In the provisioning operations agenda**, all operations that were created under a given request have a link to that request (**key icon**).
  
 {{ :devel:documentation:roles:adm:provisioning-operation-key.png?800 |}} {{ :devel:documentation:roles:adm:provisioning-operation-key.png?800 |}}
 +
 +**Similarly in the agenda of virtual system's requests**, all requests that were created under a given role request have a link to that request (**key icon**).
 +
 +{{ :devel:documentation:roles:adm:request-on-vs-key.png?800 |}}
  
  
 ===== Notification ===== ===== Notification =====
 +**These notifications are sent when the application is fully completed.**
 +
 +<note>Notifications are controlled by same rules (**configuration properties**) as notifications sending after end of approval process ([[tutorial:adm:role_change_notification_configuration|read more]]).</note>
 +
 +<note important>Completion is considered a state where the request has the request set "**Status in IdM**" to "**EXECUTED**" and the "**Status on systems**" is "**EXECUTED**" or **empty** (the status can be empty if the request does not change any role that would assigned a system).</note>
 +
 +**Two notifications** are sent, one to the author of the request and the other to whom the request changes permissions. The notification contains a list of all directly changed roles (ie does not include business roles). Roles are displayed in three tables according to the type of operation they performed with the role (assignment, modification, deletion).
 +
 +The notification also contains a column "**Problems on systems**". This column is filled only if there is a **problem** on the system that assigns the role. Typically, this column may contain a value of "**Canceled**" to indicate that the **provisioning operation** has been canceled or the request has been **rejected on the virtual system**.
 +
 +
 +<note tip>The notification includes a ** link ** to the detail of the relevant IdM role change request.</note> 
 +
 +{{ :devel:documentation:roles:adm:request-system-state-notification.png |}}
 +
 +**Name of email templates**:
 +  * ``changeIdentityRoleImplementer``
 +  * ``changeIdentityRole``
 +
 +<note>The same templates (but different topics) are used and sent when the approval process is successfully completed. They contain the same data, the difference is only at the moment of submission (immediately after approval in IdM) and in the column "Problems on systems" is not filled.</note>
 +
 +<note warning>**Beware**, these templates have been redesigned in version **9.7.0** and must be **manually updated** in all environments after upgrading to this version.</note>
 +
 +**Name of topics**:
 +  * ``core:roleRequestRealizedApplicant``
 +  * ``core:roleRequestRealizedImplementer``
 +
 +<note warning>**Beware**, these topics are **disabled be default**! If you want to use this notification, you have to **enable these topics first**!</note>
 +
  
-{{ :devel:documentation:roles:adm:notification-without-problem.png?600 |}} 
  
  
  • by svandav