Search Functionality Does Not Work When Custom Field Added to Reference Field Drop-Down

[jmiskey]

Note: This was tested in both Rome and Tokyo, and I experienced the exact same behavior in both.

In building our Catalog Items, we want to add an additional Display field to show in the Reference/List Collector drop-down (for User table variables), as we sometimes have duplicate names in that table and need to differentiate them.

If I were to go to the User Table, bring up the Dictionary Entry, and update the attributes to add a pre-defined user field (like "Active"), the attribute looks like this:

the search works fine (as expected), as shown below:

However, if we decide to add a Custom Field to the list of fields shown in the drop-down, the search functionality stops working.  This is what the attribute looks like:

And this is what the search look like: 

Why does the Search functionality stop working if you add a Custom Field?  Is there any way around it?

By the way, if I try to add the attribute right in the Catalog Item variable instead of doing it at the User table dictionary level, it still exhibits the exact same behavior.

And here is the really odd thing.  If I try to apply the same logic to the Caller field on the Incident table, i.e.

It works there, as shown below:

Is there any way to do what I want on my Catalog Item user drop-down fields?

Thanks

[Tony Chatfield1]

Hi, testing in a PDI running glide-sandiego-12-22-2021__patch1-03-02-2022 I am unable to reproduce this issue.
If I create a new true\false field in sys_user 'u_bool' and add this value to the sys_user collection record attribute 'Reference auto completer columns' eg 'email;u_bool' then as long as the form is reloaded after the update the field is visible for both incident 'caller' and a sys_user reference in a record producer.
Also tied a few combinations including a string field test 'email;u_bool;active;u_test' and results were consistent.

The only potential conflict I can see is that if the reference field has 'Reference auto completer columns' attribute set, then this will override the values set at sys_user collection level.

Can you review\clarify the exact steps to reproduce with specific details of the records involved?

[jmiskey]

OK, it appears that we may not be comparing apples-to-apples here, though I do not know how much impact some of these differences make.

1. I am using a brand new Tokyo instance, not San Diego.  Though we had noticed these issues on Rome too, so I would assume that if Tokyo and Rome both have it, that San Diego would too.

2. I create a Catalog Item that is NOT a Record Producer.  I did a Catalog Item that has a RITM workflow attached to it.

I used a brand new instance of Tokyo, so we did not change any system settings or anything like that.  The screen prints I attached shows you all the attributes that are set.  Do yours match mine exactly?

If you can get this to work, can you show me a screen print where you click on the Requested For field, and show how you are able to enter in the first letter of the name (other than "A"), and show the drop-down filtering the user field on names that start with that letter (as shown in the "Incident" screen print in my original post)?

As you can see from my screen prints, it works for the Incident, but not for the Catalog Item.  If you follow along with everything that I posted in my original post, I included all the set-up steps.  I then just created a simple Catalog Item, where I added the "Requested For" field to it, and some random Single Text field (does not matter).  And then just created some dummy workflow on the RITM table.  It doesn't matter if you add any steps to it or not, just apply that to the Catalog Item.  Of course, the behavior of the Requested For of the Catalog Item should not be impacted by the workflow at all, as that all happens before the workflow is invoked.  Then test out the behavior on the Service Portal.

[Tony Chatfield1]

1/ If issue is occurring for you in Rome and Tokyo then it would be a reasonable to assume it is also relevant to San Diego, but that is not always true.....

2/ A catalog item is a type of record producer.

The best way to investigate this type of issue is often to reproduce in an OOB PDI
This is an OOB Catalog item
/com.glideapp.servicecatalog_cat_item_view.do?v=1&sysparm_id=125ce63ce4001410f877ce457cda6b55
that contains a variable 'Business Owner of the Business Application' that references sys_user.

A/ Add custom field to sys_user
B/ Update the sys_user collection record attribute

If I follow steps A/B (as I did in my previous post) then additional fields are visible to me in the record producer 'Business Owner of the Business Application' field.

[Tony Chatfield1]

I would start by validating the behaviour using OOB tables references, to sys_user table, that do not have their own attributes configured; like incident.caller, incident.assigned_to. Then test in a record producer\cat item, ensuring that the variables attributes does not include 'ref_ac_columns'