Multi level UI

  • 8 February 2021
  • 0 replies
  • 90 views

Userlevel 4
Badge +2

Goal

Working with a new application can get quite overwhelming for end users. Not only is there a whole new UI for them to figure out, but they could also get overwhelmed with information, options, and functionality that is not yet relevant for their day-to-day tasks. This makes them take longer to get used to the whole UI. Someone who just started at sales and uses the application for the first time, might not immediately need historical data or Business Intelligence to target their first prospects. It is important that these ‘beginner’ employees smooth into using the application with a simplified version of the UI. In a later stadium, these users can then be scaled up to an ‘advanced’ or ‘expert’ level, revealing new objects (e.g., menu items, details, tasks, etc.).

 

 

Solution

To achieve this at this moment we need to define user groups in the Intelligent Application Manager, for each difficulty level (e.g., ‘sales_beginner’, ‘sales_advanced ‘sales_expert’). For each difficulty level group, we need to define which roles (and rights) will be enabled when a user is entered in that difficulty level group.

 

Used domains

 

Elements of proficiency

 

For each user is defined in which difficulty level that user is categorized, this can be managed in the end application. For example as an extra field in the employee/user table.

Minimal user table

Table “usr_grp_usr_local” is used to temporarily store retrieved user groups from IAM

Columns of usr_grp_usr_local table

 

The last step is to create functionality that enables us to call IAM when a user needs to be scaled up or down in a difficulty level. This functionality is triggered when the difficulty level of a user is changed and adds them to the ‘advanced’ group. When a user is scaled down, it's important to make sure that the user is also removed from the ‘advanced’ group, as rights across multiple user groups are combined, and not mutually exclusive.

To facilitate this, a task should be created which in turn calls IAM via indicium to alter the usr_grp_usr table. If this was successful, we also need to display a message to the user to call for a restart of the application.

Implementation

Change_user_grp

The starting task of the process flow is change_user_grp

Task parameters of change_user_grp

Task parameter “base_url” is a task output parameter and should have the URL to indicium as a default value (e.g. http://localhost/indicium/)

To make it easier for the end user we should also add a default procedure for the task:

If @cursor_from_col_id is null --First get the level of the logged in user
begin
select @current_level = u.proficiency
from usr u
where usr_id = dbo.tsf_user() --Logged in user

--Afterwards, check the current_level
if @current_level < 2 --when it's not the highest
begin
--Make the new level, one level more advanced than the current one.
select @new_level = @current_level + 1
end
--else go one level down
else
begin
--Make the new level, one level less advanced than the current one.
select @new_level = @current_level - 1
end
end

In the task code itself, we prepare the URL to retrieve the user groups of the user.

declare @user_id name
--Remove the backslash of the domain out of the username of the current user
select @user_id = replace(dbo.tsf_user(),'\','%5C') --\ is not allowed in the URL
--Create the url to be used to get the usergroups, directly in indicium
select @base_url = concat( @base_url, 'iam/iam/usr_grp_usr?$filter=usr_id eq ' ,'''' + @user_id +'''')

save_user_groups

After the HTTP connector is called, in order to retrieve the existing user groups, the result is temporarily stored in a table.

Parameters of save_user_groups

The JSON result of Indicium is saved in the application:

DECLARE @json api_body
--Delete the exisitng user grp data for the user
delete
from usr_grp_usr_local
where usr_id = dbo.tsf_user()

--Get the value out of indicium
select @json = (select value
from OPENJSON(@api_results)
where [key] = 'value')

--Save the new user_groups for the usr
insert into usr_grp_usr
select *
from OPENJSON(@json)
WITH (
usr_grp_id VARCHAR(200) '$.usr_grp_id'
,usr_id varchar(100) '$.usr_id'
,begin_on datetime2 '$.begin_on'
,end_on datetime2 '$.end_on'
)

get_next_usr_grp

This task prepares the data for the rest calls in order to delete the old user group and create the new one.

Parameters of the get_next_usr_grp task

Api_body , old_group & base_url_delete are task output parameters.

The template of the task prepares everything for Indicium.

declare @user_id   name
, @new_group name
--Remove the backslash of the domain out of the username of the current user
select @user_id = replace(dbo.tsf_user(),'\','%5C') --\ is not allowed in the URL
--Create the url to be used to directly in indicium
select @base_url_delete = concat( @base_url, 'iam/iam/usr_grp_usr(usr_grp_id=')

--Get the current group
select @old_group = (select top 1 usr_grp_id
from usr_grp_usr_local
where usr_id = dbo.tsf_user()
and usr_grp_id like case(@current_level)
when 0 then '%beginner'
when 1 then '%advanced'
when 2 then '%expert'
end
)
--Replace the level of the current group to the new level
select @new_group = replace(@old_group
, case(@current_level) --Replace the current level
when 0 then 'beginner'
when 1 then 'advanced'
when 2 then 'expert'
end --With the new level
, case(@new_level)
when 0 then 'beginner'
when 1 then 'advanced'
when 2 then 'expert'
end
)
--Prepare te url to indicium
select @base_url_delete = @base_url_delete +'''' + @old_group +'''' + ',usr_id=' + '''' + @user_id +'''' +')'
--Prepare the body with the right data
select @api_body = ( SELECT @new_group as usr_grp_id, usr_id, begin_on, end_on
FROM usr_grp_usr_local
where usr_id = dbo.tsf_user()
and usr_grp_id = @old_group FOR JSON AUTO, WITHOUT_ARRAY_WRAPPER )

delete_processed_group

After changing the group in IAM, we need to delete the processed group in our temporary table

Task parameters of delete_processed_group
delete --Delete the old_group in the temp table, otherwise it would be processed again
from usr_grp_usr_local
where usr_grp_id = @old_group --Processed group
and usr_id = dbo.tsf_user() --of the current user

 

Process procedure

After deleting the processed group, we need to check if there are any groups left to process. If this is not the case we can continue with updating the level of the user. For this, we need a process procedure on the delete_processed_group task.

--When there are groups left in the temp table.
if (select 1 from usr_grp_usr_local
where usr_id = dbo.tsf_user()
and (usr_grp_id like '%beginner'
or usr_grp_id like '%advanced'
or usr_grp_id like '%expert') ) > 0
begin --Disable the update user step
set @execute_task_delete_processed_group_execute_task_update_user = 0
end
else --Else disable the get grp step
begin
set @execute_task_delete_processed_group_execute_task_get_next_usr_grp = 0
end

update_user

After all the user groups are updated, the proficiency level of the user is set to the new level

Tasks parameters of update_user
update usr                           --Update the user
set proficiency = @new_level --change his proficiency level to the new level
where usr_id = dbo.tsf_user() --For the current user

 

 

After restarting the application, the changes will take effect and more options are enabled for that user. Just like if the user changed user groups normally.

Idea

The situation as described above however is not the desired situation, as it forces us to directly call the indicium of IAM and it could become problematic to maintain user groups in IAM. Because if we were to follow this path, we need to define three different user groups (one per difficulty level) per actual user group. Lastly, a call to action to restart the application isn’t the nicest thing in the world.


To offer a more formal solution I've created an idea!


0 replies

Be the first to reply!

Reply