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:role_attributes [2019/01/15 09:24] – [Provisioning of assigned roles] svandavdevel:documentation:role_attributes [2019/04/16 08:07] (current) – svandav
Line 2: Line 2:
  
 ====== Attributes of role ====== ====== Attributes of role ======
-{{tag>role attributes}} +{{tag>role attributes parameters assigned parametrization}}
-===== What are an attributes of role? ===== +
-Role attributes define what additional information can (must) be filled in the user's assigned role. A typical example can be the IP address of a user's end station, which must be filled in in a role assignment request.+
  
-Definitions of which attributes are to be filled for the role are managed on the role detail (role attributes tab). Here, you define not only what attributes to show in the request, but also their default values and validation settings. This definition is part of the role approval (off by default).+===== What are role attributes ===== 
 +**Role attributes determine** what additional information **can (must)** be filled in a user's **assigned role**. A typical example can be the **IP address** of a user's end station, which must be filled in a role assignment request.
  
 +The **definitions of what attributes** are to be filled for the role are managed on the **role detail** (role attributes tab). Here, you define not only what attributes to show in the request, but also their **default values** and **validation settings**. This definition is part of the **role approval** process (off by default).
  
-===== How it works? ===== 
  
 +===== How it works =====
  
-==== Provisioning of assigned roles ====+==== Definition ==== 
 +First, you need to **create the main definition** of all attributes which could be used in role **sub-definition**. The **main form definition** can be created in the **Form definitions** agenda. 
 +<note>Attributes from the **main definition** can be used multiple times in multiple roles.</note> 
 +<note tip>**Main definition** must be created for type **IdmIdentityRole**.</note> 
 +<note important>**Now isn't supported **confidential** and **attachment** attributes!**</note> 
 + 
 +Then, you need to **create sub-definition** of attributes witch should be filled in requesting a role.  
 +Sub-definition can be created on the role detail on the **Role attributes** tab. In sub-definition you can select an attributes only from main definition. So first what you need to do, is select main definition and save it. Then you can create **attribute definition for the role**. 
 + 
 +{{ :devel:documentation:role-attributes-detail.png |}} 
 + 
 +**Attribute definition for the role** define: 
 + 
 +* **Definition of attribute** from the main definition. 
 +* **Overrides the default value**. Default value from attribute in main definition will be prefilled (only on frontend). 
 +* **Overrides the validation settings**. Validation settings from attribute in main definition will be prefilled (only on frontend). 
 + 
 +<note important>**Only** attributes defined in the **sub-definition** will be show on role requesting!</note> 
 + 
 +{{ :devel:documentation:role-attributes-list.png |}} 
 + 
 +==== Using on the role request ==== 
 + 
 +If some requested role **has attributes**, then is rendered form on **role concept detail**: 
 + 
 +{{ :devel:documentation:request-add-detail.png |}} 
 + 
 +<note important>Form with role's attributes is rendered only if **one role is selected**! If are selected more roles on the detail, then user **cannot fill the attribute's values** directly. In this case user can create role-concepts for more roles and then editing the values of attributes for each concept **one by one**. </note> 
 + 
 +**If you add multiple roles** in one request and some from this roles will have **required attribute** (without default value), then will be created concept **not valid**. In this case you will see **warning icon** on the unvalid concept. 
 + 
 +{{ :devel:documentation:concepts-validation-warn.png |}} 
 + 
 +You can **modified existing attribute value** in assigned role. For this case was created new mode for **highlight** changes on detail of role concept: 
 + 
 +{{ :devel:documentation:request-modified-detail.png |}} 
 + 
 +If a **request** that contains **attribute roles** is submitted, a standard **approving process is executes**. If the role with the attributes is approval, then the detail of the concept role, including the attributes, **is displayed in the detail of the approval user task**. 
 + 
 +{{ :devel:documentation:request-task-detail.png |}} 
 + 
 +Upon successful **completion of the request**, the resulting concept role attributes are **copied** to the **assigned role** (**IdmIdentityRole**). Attributes assigned to roles can be displayed on the **identity detail** (**Roles** -> **detail** -> Tab "**Role's attributes**"). 
 + 
 +{{ :devel:documentation:identity-role-attributes-detail.png |}}  
 + 
 +===== Provisioning of assigned roles =====
 For the purpose of provisioning assigned roles, new attributes (**User assigned roles** and **User assigned roles (for this system)**) were created, which can be used in system mapping for provisioning identities. For the purpose of provisioning assigned roles, new attributes (**User assigned roles** and **User assigned roles (for this system)**) were created, which can be used in system mapping for provisioning identities.
 Input of the transformation into the system is a list of valid assigned identity roles. This assignment is represented by the ** AssignedRoleDto ** object, which mirrors the object ** IdmIdentityRoleDto ** and tries to simplify the work with assigned roles in the transform. This simplification is primarily based on the fact that the object contains the entire DTO (role, identityContract, ...) instead of the UUID and mainly contains a **map of all the attributes of the assigned role** (where the key is the attribute code and the value is a list of all attribute values). Input of the transformation into the system is a list of valid assigned identity roles. This assignment is represented by the ** AssignedRoleDto ** object, which mirrors the object ** IdmIdentityRoleDto ** and tries to simplify the work with assigned roles in the transform. This simplification is primarily based on the fact that the object contains the entire DTO (role, identityContract, ...) instead of the UUID and mainly contains a **map of all the attributes of the assigned role** (where the key is the attribute code and the value is a list of all attribute values).
Line 19: Line 64:
  
 <note>Structure of **AssignedRoleDto** is [[https://github.com/bcvsolutions/CzechIdMng/blob/develop/Realization/backend/acc/src/main/java/eu/bcvsolutions/idm/acc/domain/AssignedRoleDto.java|here]].</note> <note>Structure of **AssignedRoleDto** is [[https://github.com/bcvsolutions/CzechIdMng/blob/develop/Realization/backend/acc/src/main/java/eu/bcvsolutions/idm/acc/domain/AssignedRoleDto.java|here]].</note>
 +<note>Input of transformation for attribute ** User assigned roles (for this system) ** will contain only valid assigned user roles assigned this system!</note>
  
 === Example script for print assgined roles to the string: === === Example script for print assgined roles to the string: ===
Line 43: Line 89:
 </code> </code>
  
-====== Read more ====== 
- 
-===== Devel guide ===== 
  
-===== Limitations ===== +===== Admin guide (to be completed)===== 
-<note warning>Enabling of the request mode is controlled only by **IdmRole** now.</note> +  * [[.attributes:adm:attributes|Role attributes]]
-<note warning>Changes in the request preview are highlighted only on tables. Type of changes are not show on the object **details** or on **EAVs**!</note>+
  • by svandav