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

Janel2 · ‎03-06-2017

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?

Janel2 · ‎03-07-2017

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');

}

View solution in original post

Jyotsna6 · ‎01-24-2020

Hello Janel,

Above BR Script is working correctly but it's creating lots of logs in syslog in our instance.

Can you please suggest on this.

Do we have any solution to stop logs

Janel · ‎01-28-2020

I know what errors you're talking about. The ones about "RP is undefined" or whatever. We ended up turning this off due to the noise and I haven't had a chance to revisit it. Sorry, nothing at the moment.

Jyotsna6 · ‎02-03-2020

Hello Janel

i have used 2nd option i.e.

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

instead of RP.

still it throwing error log like "Root cause of JavaScriptException: java.lang.NullPointerException
: java.lang.NullPointerException:"

can you please suggest

Jyotsna6 · ‎02-06-2020

Hello Janel,

Above BR is working correct but it fetching below while commiting any Update set.Can you please suggest on anything on this.