Related Tips & Info
Wikis - Page

ID Apps - Searching for users, how to show more than simply full name

Geoffrey Carman
 
4 Likes

If you have used the ID Apps, you will know that there are many locations in the UI where you can search for users and some of them differ very slightly.

However, one of the major issues you may run into is that the display shows only the full name. Which is great, until you have two John Smiths or two Aditya Vikrams.

How do you tell Aditya #1 from Aditya #2?

The good news is that the DAL comes to the rescue.  With the switch to the new user interface that started in IDM 4.02 with the IDM Home, and is now fully the only option as of 4.7.3, IDMProv's old interface is no longer available.

When they made this switch, they wisely did NOT throw away the DAL (Directory Abstraction Layer) instead they integrated into the RESTful services they exposed for the new UI to consume.

This means, that since they are honouring the DAL, we might be able to fix it in the DAL.

My first thought was look in the DAL at the Entities and then User, looking to see if there is anything special about Given Name, Surname, or Full Name attributes that would flag them as being the displayed values. But I was close, but not quite.

Turns out there is a DAL Entity called Full name.  This is special as it has a definition space where you can define the value of what is returned, in a syntax that I THINK is only used in this one place.

So TLDR version, DAL, Entities, Full Name and where it says:

attr.getValue("Given Name") " " attr.getValue("Surname")

   change it to:

attr.getValue("Given Name") " " attr.getValue("Surname") " - " attr.getValue("CN")

And now you get "Geoffrey Carman - geoffc" for me, and possibly "Geoffrey Carman - carmang" for that other slacker. (If you ever run into a location that has two people with the same name as me, it is best to run and hide, the endtimes will be approaching). 

Of course you could chose any other attribute to add in if you so desired.

Note the syntaxt of attr.getValue("attrName") is somewhat odd in the context of ID Apps, since I cannot think of another place where it works that way.  (There is an analouge to this for IDG and it is set in the Configutil.sh GUI in more database langauge style syntax. Don't have an IDG example handy.  But the displayName in IDG is a special attribute, who definition is configured somewhat similarly in configutil.sh).

Now of course, anywhere that uses the DAL entry for the Full Name entity is going to display it this way.  The most obvious is in the upper right corner, where it used to show your full name it will now show full name - cn value.

As far as I can tell so far, no emails go out with a different value, so that does not look like one of the places it uses it.

 

Labels:

Support Tips/Knowledge Docs
Support Tip
Comment List

  • I was wondering if it is possible to have finer control over where the custom "FullName - CN" is displayed. For example only in user search when filling a new request for others.

    I have found a page in the documentation which is describing how to enable localized user names in typeahead fields. This is where I first came across "UIControlRegistry.xml" file.

    I do not think that this page is entirely correct. It states: "However, to use user names with localized name formatting in typeahead fields within the identity applications, you must create one or more custom registry entries.", but usernames were displayed correctly just after making changes to DAL like Alex suggested.

    Of course I tried playing around with the registry too. After resetting changes in DAL and reproducing all the steps in the documentation, nothing happens. There are no changes in user search field - just users full name like in default idapps. Did I do something wrong or is this not supported anymore?

    I am curious, what are the different options you can use in this xml file. For example, can you do something like:  
     

    <prop name="display-exp" type="string">
    <value>FirstName LastName - CN</value>
</prop>

    Where does this file get variable values from? Can anyone tell me more about these settings? I am fairly new to Tomcat and Java web applications.

  •   in reply to Alex McHugh 

    Turns out that one must define all attributes that will be used in this calculated "Full name" in three different DAL entities.

    1. the special "Full name" DAL entity - as part of the ecmascript expression.
    2. the "User" entity, and the attribute(s) that are used in the above ecmascript expression need to be marked as "required" in the access types.
    3. the "User Lookup" entity - here, I believe you need to make sure that "search" access is allowed.

    That fixes the request on behalf of problem.

  •  

    I have sadly discovered an area where this does not work.

    tested with IDM 4.8.7 (lab environment) and IDM 4.8.3 (customer environment)

    1. Implement change as described in article above.
    2. Configure a team for example a standard manager-employee team (it really doesn't seem to matter much how one configures the team, just that the requestor is part of a team)
    3. Log in as a manager, try to request a permission for "Others"
    4. Search for users, note that the Special Full Name - DAL Calculated Attribute logic is triggered, but the display results lack the data from the CN attribute (so just First Name Given name and hyphen is shown)
    5. Navigating to other portions of IDM Apps (like People->Users), show that the logged in user has the correct rights to retrieve other user's CN attribute and properly display the calculated Full Name.
    6. Repeat the same process as a fully privileged user like uaadmin and the calculated Full Name is displayed correctly when one attempts to request a permission for "Others"

    Assuming that this is a case where the backend REST call that retrieves a list of users fails to run the call with the security permissions of the currently logged in user. Anyone else seen this or know how to workaround this issue?

    As Manager:

    As uaadmin

Related
Recommended

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.