How to Easily Change the Display of OIM User Attributes

Recently a client asked me if it was possible to conditionally display user attributes in OIM.  He was concerned that it would require many new forms to display and modify attributes based on various conditions.  I was happy to tell him that additional forms weren’t necessary, and it could be accomplished in minutes with a few lines of script and a new sandbox.

The desire to change how fields are displayed in OIM is common. Some approaches are well-documented, and some aren’t.  In this post, we’ll walk through examples of both the well-documented and undocumented scenarios of how to use EL Expressions to make the UI more dynamic.  I’ll assume you already have basic knowledge of OIM navigation and UI customization through sandboxes.

Make attributes read-only to anyone but administrators

Making attributes read-only for anyone but an administrator is a common scenario that Zirous implements for most clients.  When user attributes are sourced from a trusted system, it doesn’t make sense for end users to have the ability to edit them.  They’ll just be overwritten the next time an update comes from the trusted system. But, the attribute can’t be made read-only for everyone because, on occasion, a system administrator will need to make a one-off change.  This change satisfies both needs.

Assume First Name and Last Name come from a trusted source.  As described above, they need to be read-only unless the modifying user is a system administrator.  This scenario and the code for implementing it is fairly straightforward and clearly documented in multiple places.

Start by creating a sandbox, navigate to the user modify page, and begin customizing.

 

 

 

 

 

 

 

 

 

 

 

Edit the First Name attribute.  Next to the Read Only checkbox, click the dropdown and choose Expression Builder.

Add an expression that indicates that the user is NOT in the System Administrator admin role, such as: #{oimcontext.currentUser.adminRoles[‘OrclOIMSystemAdministrator’] eq null}.  This will evaluate to TRUE, which will make the attribute read-only.

Once you publish the sandbox,  you’ll see that the attributes are now read-only for non-administrators.

Make attributes read-only based on the value of other fields

This one isn’t as well documented, but it’s valuable and just as easy once you know how to do it.  Often, data in one attribute should control how another attribute is displayed. In the following example, we’ll make the User Login read-only if the Organization is “Zirous”.  Then we’ll make the Telephone Number read only if the User Type is “Employee”. Once again, we’ll want to make sure that System Administrators are allowed to edit the attributes no matter what.

The example below may not work in all scenarios, but often meets basic needs.  Some scenarios may require managed beans to handle state changes correctly. The implementation of managed beans will not be covered in this post.

Following the same steps used above, we’ll add the following EL Expressions to First Name and Telephone Number, respectively.  Note that for an LOV like User Type, the inputValue of the attribute corresponds to the value’s numeric position in the list starting with 0.  So, if the 4th option is “Employee”, the EL Expression should check if inputValue is equal to 3.

EL Expressions:

#{bindings.usr_emp_type__c.inputValue eq ‘3’ and oimcontext.currentUser.adminRoles[‘OrclOIMSystemAdministrator’] eq null}

#{bindings.lov_ds_act_key__c.inputValue eq ‘Zirous’ and oimcontext.currentUser.adminRoles[‘OrclOIMSystemAdministrator’] eq null}

The User Login and Telephone number are now read only.

Final Thoughts

As you can see, this is a powerful and simple way to make the user interface more dynamic.  Minor configuration like this can help make data entry much less error-prone, and it will make it clear to users what they are and are not allowed to do.  Zirous recommends customizations similar to this for all implementations.

In more complex scenarios, a single user attribute such as First Name may be automatically populated from a trusted system for some users but manually entered for others.  The determination of whether it should be read-only or not is based on the user’s source system rather than a particular User Type. Zirous has implemented additional customizations to account for complex scenarios such as this.  

If you have a question related to OIM customizations, contact us to get in contact with me or another Identity expert.