Override Display Value of fields from different tables that reference the sys_user table?

[TrenaFritsche]

Hello,

 I have posted this same message as a reply to a posting from over a year ago, but thought I should probably present this as a question to the larger group.

I'm wondering about a display value override for specific tables, but dictionary overrides related list doesn't seem to show?  For example, we have the user_name field on the "sys_user" table (which is basically the UserID and not always the name) and have added variables or fields to show the "name" on various forms where we have them referencing the sys_user table.  We cannot change the Display Value on this table because we have so much built (10 years of work) where the User ID and User Name both display.  As we are implementing new products (ie: PPM), these customers are wanting to stay mostly OOB and not change various PPM forms that have sys_user referencing fields that can type the person's name in the field and autocomplete finds it (that feature is configured), but once it is selected, the display value is the User ID and not the name as the PPM customers want it to display. 

In order to give them the field that displays the name, we would have to add a custom field to the form.  I know the reference icon can show the name if they hover over it, but I'm trying to allow this display value override on this table, but I'm guessing it is not available due to it being a foundation type table?  Not sure, but it anyone can help me understand the reasoning or if I'm maybe missing something where it is able to be done, that would be awesome if you can share.

 Thanks in advance for your assistance!

 Trena Fritsche

[Mark Stanger]

Each table has a single display value that shows up in reference fields throughout the system.  While you can customize the autocomplete attributes and behavior for each individual reference field, the display value that shows in the reference field will always be the same for each reference field in the system.  The only exception to this is on extended tables, where an extended table (incident for example) can specify a different display attribute that overrides the one designated on the parent table (like task).

Please mark this answer as correct if I've answered your question.  Thanks!

[Chuck Tomasi]

I concur with Mark. Having more than one display value per table would be terribly confusing. Consider a form with a caller display a user ID and the assigned to field displaying a name. They both reference the same table, but the visual indication is that it's not the same data.

As Mark suggested, you could do this with table extensions. Create a sys_user_name (?) table extended from sys_user and use an override to display whatever field from that extended table. Again, I don't recommend this since you did say you wanted to stick with OOB as close as possible and - again it would be confusing to the user to see the same data displayed multiple ways.

[TrenaFritsche]

Thanks for your replies!  I understand and agree with what you are both saying and we are just having the issue of ITSM configuration that was determined years ago and the User table being configured as having the user_name field as what should display (from an IT Help Desk perspective) and really the User ID and the User Name are truly interchangeable from a visual preference as they both refer to a single person and what a customer wants to see.  The Help Desk wants to see the User ID, but PMO team wants to see the name.  I was just hoping to set an override on the PPM tables.  IT and non-IT users basically look at things differently. 🙂

[Mark Stanger · Accepted solution]

Unfortunately, you can't.  The only thing you could do to potentially work around this issue would be to create a new field on the user table that was a concatenation of the User ID and User Name.  Then you could set that field as the display value for everywhere in the system to show both attributes at the same time as the display value.  That's not that difficult to do and could be done without really impacting the last 10 years of data...as long as you can get your entire org onboard with the idea.