and more in a single search tool across platforms. Read the announcement here. |
on 08/29/2023 01:59 AM
The user registration/creation forms in EIC are driven through User dynamic attributes defined in Global Configuration à Identity Lifecycle à Register User Form. Various types of dynamic attributes can be defined to take inputs from logged in user to create users in EIC. Logged in user’s information can be used to determine values in dynamic attributes as well. EIC also facilitates Validation conditions using Groovy in the dynamic attributes.
Define user registration dynamic attributes:
We can define cascading dynamic attributes or dynamic attributes having parent child relationship – for example when the user selects a specific department, we can have the child attribute show only the managers/sponsors belonging to that department, or job descriptions related to that department, etc.
Query: select distinct departmentname as ID from users where userkey=$loggedInUser.id and departmentname is not null union select distinct departmentname as ID from users where departmentname is not null and exists (select userkey from user_savroles where ROLEKEY=1 and USERKEY=$loggedInUser.id)
Default query: select distinct departmentname as ID from users where userkey=$loggedInUser.id
Query: select distinct m.username as ID, m.displayname as inlinedescription from users u join users m on u.manager=m.userkey where m.departmentname=$departmentname
Query: select distinct jobcodedesc as ID from users where departmentname=$departmentname
a. When the department name is selected as Administration, the managers list shows the following users
b. When the department name is selected as Finance, the managers list shows the following users
c. When the department name is selected as Administration, the job code descriptions list shows the following values
d. When the department name is selected as Finance, the job code descriptions list shows the following values
The Action String in a dynamic attribute can be utilized to show/hide child dynamic attributes based on parent dynamic attribute values. One must mention all the possible values in the parent dynamic attribute in the action string and should define unique action for each value as to whether to show or hide the child dynamic attribute.
The format of an Action String is in the following format –
HIDE###emailaddress###Employee___SHOW###emailaddress###Contractor___SHOW###emailaddress###Visitor
Suppose we have a parent dynamic attribute of type Single Select SQL which has the following values in the drop-down – Employee, Contractor and Visitor. There is another dynamic attribute called as emailaddress which is of type String and is required for Contractor or Visitor type of users only and is not required to be filled in for Employees.
The above Action String must be defined in the parent attribute and “What action to perform when Parent attribute changes?” in the parent attribute must be set to Mapping. Then while creating the user through the form, when an end user selects “Employee” in the parent drop down, then emailaddress child dynamic attribute gets hidden. Whereas when the end user selects Contractor or Visitor in the parent dropdown, then emailaddress is shown to the user.
Query: select 'Employee' as ID, 'Create Employee' as inlinedescription union select 'Contractor' as ID, 'Create Contractor' as inlinedescription union select 'Visitor' as ID, 'Create Visitor' as inlinedescription
Default value or query: select 'Please select form type' as ID
Action String: HIDE###firstname###Please select form type___HIDE###middlename###Please select form type___HIDE###lastname###Please select form type___HIDE###generateusername###Please select form type___HIDE###username###Please select form type___HIDE###departmentname###Please select form type___HIDE###manager###Please select form type___HIDE###jobcodedesc###Please select form type___HIDE###location###Please select form type___HIDE###employeeid###Please select form type___HIDE###emailaddress###Please select form type___SHOW###firstname###Employee___SHOW###middlename###Employee___SHOW###lastname###Employee___SHOW###generateusername###Employee___SHOW###username###Employee___SHOW###departmentname###Employee___SHOW###manager###Employee___SHOW###jobcodedesc###Employee___SHOW###location###Employee___SHOW###employeeid###Employee___HIDE###emailaddress###Employee___SHOW###firstname###Contractor___SHOW###middlename###Contractor___SHOW###lastname###Contractor___SHOW###generateusername###Contractor___SHOW###username###Contractor___SHOW###departmentname###Contractor___SHOW###manager###Contractor___SHOW###jobcodedesc###Contractor___SHOW###location###Contractor___HIDE###employeeid###Contractor___SHOW###emailaddress###Contractor___SHOW###firstname###Visitor___SHOW###middlename###Visitor___SHOW###lastname###Visitor___SHOW###generateusername###Visitor___SHOW###username###Visitor___SHOW###departmentname###Visitor___SHOW###manager###Visitor___HIDE###jobcodedesc###Visitor___SHOW###location###Visitor___HIDE###employeeid###Visitor___SHOW###emailaddress###Visitor___HIDE###userid###Please select form type___HIDE###userid###Employee___HIDE###userid###Contractor___HIDE###userid###Visitor___HIDE###TestAttribute###Please select form type___SHOW###TestAttribute###Employee___SHOW###TestAttribute###Contractor___SHOW###TestAttribute###Visitor___HIDE###modificationnote###Please select form type___HIDE###modificationnote###Employee___HIDE###modificationnote###Contractor___HIDE###modificationnote###Visitor___
Notes:
Please note that every other attribute other than Form Type is hidden because the current value in the parent attribute is ‘Please select form type’
The available values in the form type are Contractor, Employee and VisitoWhen Contractor is selected in the dropdown
a. When Employee is selected in the dropdown – Email address gets hidden
b. When Visitor is selected from the dropdown – Job description gets hidden and Email address shows up
We can use a SQL type of dynamic attribute to access the string given as input for first and last name of the user. Since we need to trigger an update in the username dynamic attribute to calculate the value of the username, we need an extra attribute which will trigger a refresh action on the username dynamic attribute. Please find below the example on how to achieve this.
Query: select 'Yes' as ID union select 'No' as ID
Validation Condition: ${generateusername.equals('Yes')}
Query: SELECT lower(concat(${firstname},'.',${lastname}, if(count(username)=0,'',convert(count(username),UNSIGNED)))) as ID FROM users WHERE username like concat(${firstname},'.',${lastname},'%') HAVING ID IS NOT NULL and 'Yes'=${generateusername} and ${firstname}!='' and ${lastname}!='' and ${createformtype} != 'Visitor' union all select ${emailaddress} as ID from dual HAVING ID IS NOT NULL and 'Yes'=${generateusername} and ${createformtype} = 'Visitor' and ${emailaddress} != '' LIMIT 1;
Notes:
a. When the Form type is Employee, the username is created from first and last name
b. When the Form type is Visitor, the username is picked up from the email address field
We can use the logged in user’s context to derive values in user dynamic attributes. This generally comes handy when we want to control the values in the drop down or when we want to control which attributes are to be shown/hidden for which type of end users, etc.
Example – When a sponsor/manager is creating another user, they will be creating a contractor or employee user in their own department or cost centre or location. Hence, we can restrict the department or cost centre or location dropdown values on basis of attributes of the logged in user. Like a user from Finance department would be creating users who will be working in Finance department and will not be part of Administration team or any other.
Query: select distinct departmentname as ID from users where userkey=$loggedInUser.id and departmentname is not null union select distinct departmentname as ID from users where departmentname is not null and exists (select userkey from user_savroles where ROLEKEY=1 and USERKEY=$loggedInUser.id)
Default value/query: select distinct departmentname as ID from users where userkey=$loggedInUser.id
Notes:
a. The logged in user is an administrator and has access to ROLE_ADMIN SAV Role
b. The logged in user is a normal end user having basic access, hence the user can create users only in their respective department
@nimitdave Tried to use this for one of my use cases to update the displayname with the help of firstname and lastname but it's not working.
I opened an idea forum post. This workaround is ridiculous.
Allow dynamic calculation during "Create User | Saviynt Ideas Portal