Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
devel:documentation:roles:adm:role_assignment [2019/07/23 11:52] svandav [Link to request from a provisioning operations] |
devel:documentation:roles:adm:role_assignment [2020/02/17 20:27] (current) husniko [Role deletion] |
||
---|---|---|---|
Line 90: | Line 90: | ||
====== System state ====== | ====== System state ====== | ||
+ | |||
+ | {{tag> | ||
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 97: | Line 99: | ||
<note tip> | <note tip> | ||
- | ==== Running state ==== {{tag> | + | ==== Running state ==== |
+ | {{tag> | ||
Some of the provisioning operations is not completed. | Some of the provisioning operations is not completed. | ||
Line 105: | Line 108: | ||
{{ : | {{ : | ||
- | **Second** situation when could be request in running state is if role assign **the virtula | + | **Second** situation when could be request in running state is if role assign **the virtual |
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. | 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. | ||
Line 113: | Line 116: | ||
{{ : | {{ : | ||
- | If the request contains **pannding virtula | + | If the request contains **pending virtual |
{{ : | {{ : | ||
Line 149: | Line 152: | ||
==== Not executed state ==== | ==== 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. | 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. | ||
+ | |||
+ | |||
+ | {{ : | ||
+ | |||
+ | 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. | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | |||
===== Link to request ===== | ===== Link to request ===== | ||
Line 161: | Line 176: | ||
===== Notification ===== | ===== Notification ===== | ||
+ | **These notifications are sent when the application is fully completed.** | ||
+ | |||
+ | < | ||
+ | |||
+ | <note important> | ||
+ | |||
+ | **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, | ||
+ | |||
+ | The notification also contains a column " | ||
+ | |||
+ | |||
+ | <note tip>The notification includes a ** link ** to the detail of the relevant IdM role change request.</ | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | **Name of email templates**: | ||
+ | * ``changeIdentityRoleImplementer`` | ||
+ | * ``changeIdentityRole`` | ||
+ | |||
+ | < | ||
+ | |||
+ | <note warning> | ||
+ | |||
+ | **Name of topics**: | ||
+ | * ``core: | ||
+ | * ``core: | ||
+ | |||
+ | <note warning> | ||
+ | |||
- | {{ : | ||