Ref Qualifier of List field pointing to sys_choice only applies on form view

[Janel2]

Short Version:

I have a List field on cmdb_hardware_product_model called Location Type.   It looks at sys_choice for the values and has a few simple reference qualifiers on the dictionary.   It has to be a List because something may have multiple location types.   This field works exactly as intended from a form view.   If I try to use Location Type as a piece of criteria from a list view, I see ALL options on sys_choice.   Like my reference qualifiers on the dictionary just decided to stop working.

Any idea why they wouldn't apply to a list view, but work fine in the form view?

Long Version:

I have a field on cmdb_hardware_product_model called Location Type (u_location_type) which is used as a filter condition on incidents to only show pieces of hardware as selections that match the same type of location that the incident is opened under.

For example; I open an incident, put in a location, that location has a location type associated to it (District Office, Shipping Center, Service Center, etc.).   The location type options on cmn_location live on sys_choice.   Now I need to pick a hardware model that is having the issue.   I limit my selection of available units to match the location type.   E.G. If site == Service Center, then only show hardware models that also contain the type of Service Center.   Fairly straight forward, right?

The field on cmdb_hardware_product_model is very simple; it is a List type field looking at sys_choice with a couple of reference qualifiers on it, which are the same as my Location Type found on cmn_location.

Type: List

Column Label: Location Type

Column Name: u_location Type

Reference: Choice [sys_choice]

Reference qual conditions;

        table is cmn_location

        element is u_location_type

        inactive is false

It has to be a List field because a single hardware model may reside in multiple location types.   On my hardware model, it works just fine.   The reference qualifiers work just fine and my list from sys_choice is filtered as expected.   On incident I had to use a script include for the filter so I can drill out the location types and come back with sys_id's (and country).   As it stands right now, this is also working correctly on incident.   Hooray, right?

Here's the kicker.   When I try to use my Location Type on Hardware Model as a filter criteria from a list view, the reference qualifiers no longer get applied and instead I see ALL options from sys_choice.

Has anyone seen this before?   Any idea why the reference qualifiers on the dictionary only work on the form view and not in the list view?

[She Sull]

Hi, Janel. The reference qualifier only applies to the field on the form. To apply the filter to the list view you can update the module condition (among other options such as list views). Give that a try, hope it helps.

Reference qualifiers

Create a module

[Janel2 · Accepted solution]

Is it just the nature of the List field type that doesn't apply the reference qualifier?   Choice field types do apply the filters correctly on other tables from a list view.

It isn't coming from an application module.   It is just the filter criteria on the list view.   Users have the option on whether to filter by location type, but with 29,000+ results (with duplicate values) it is essentially worthless unless they know the table and element to add as additional filters within the selection/search window.

I wrote a query business rule on sys_choice that does a little verification against the originating table, but there isn't a way to apply that as a condition so it ended up as an IF statement in the script.   I rather this BR *not* run every time sys_choice is being queried.   I would rather think I would not need a query BR at all!

Here is the script incase anyone is wondering:

Query, Before

Condition: gs.getSession().isInteractive()

var action = gs.action.getGlideURI().getMap().get('sysparm_target');

if(action.indexOf('cmdb_hardware_product_model.u_location_type.') == 0){
current.addQuery('name', 'cmn_location');
current.addQuery('element', 'u_location_type');
}

[Janel2]

ServiceNow got back to me.   They said this is normal behavior and to use the query BR as a work around...   Sadly also were not able to provide any information about how to add a condition by table.

They opened an enhancement request for applying the dictionary reference qualifier to filter criteria, so we'll see what comes of that who knows when.

[Janel]

That original solution didn't end up working and we turned it off.  It was throwing errors if you added a filter that wasn't a glide_list, but still looked at sys_choice.

Today we ran into another case for looking into this and I believe I have come up with a decent solution and I figured I'd share it.  I can't be the only person wishing glide_lists pointing at sys_choice could be filtered on a list view!

This only works for the reference list pop-up from a list view.  It does not work if just typing in the box.

Name: Limit glide_list options in List View

Table: Choice [sys_choice]

When: Before

Query: True

Condition:

gs.getSession().isInteractive() && gs.action.getGlideURI().getMap().get('sysparm_nameofstack') == 'reflist'

This is where we went wrong before.  This will make sure it is a legit user making the action and that we are looking at a reference list. 

Script:

(function executeRule(current, previous /*null when async*/) {
	var action = RP.getParameterValue('sysparm_target'); //Since we are on the list and interactive, we can use RP!
	//var action = gs.action.getGlideURI().getMap().get('sysparm_target'); //If RP throws errors, flip to this one.

	
	/* Check the URI for the table/field (element) we want to add queries to.
 	* The popup shows the URI. Look for "sysparm_target=" and copy the table and element name through the period.
 	* The sys_id at the end seems random, so don't include that.*/
	if(action != null && action.indexOf('kb_knowledge.u_brands.') == 0){
		current.addQuery('name', 'kb_knowledge');
		current.addQuery('element', 'u_brand_list');
		current.addQuery('inactive', false);
	}
	
})(current, previous);

So in this case I was looking to filter down my "Location Brands" glide_list to kb_knowledge.u_brands.  All this does is check if the sysparm_target exists and gather its value.  Then if it matches my knowledge table, add those extra queries in there.  Then repeat for any other tables/fields as needed.