Troubleshooting the Script Include called by Reference Qualifier on multi-table field

carram
Tera Expert

Hi, devs!

 

Very novice programmer and ServiceNow administrator here. We make use of CSM and FSM, which come with the tables sn_customerservice_case, wm_order, and wm_task that are child to Task. I'm trying to set up an advanced reference qualifier on the field "assignment_group" that determines which of these child tables the field is being accessed on and only shows the appropriate groups for each form (Case, Work Order, and Work Order Task).

 

I've written a script include (image1.png) with guidance from the wonderful SN Guru blog's article on this topic, and made the appropriate changes to the "assignment_group" dictionary entry (image2.png). I'll provide the related groups I'm trying to divy up between forms in image3.png

 

The result? All groups return when accessing the "assignment_group" field from all child forms (C, WO, WOT) (image4.png). It's like my queries aren't set up right or something... I'm at a loss. Is there anything you all are seeing that I'm doing wrong here?

 

Thank you so much.

1 ACCEPTED SOLUTION

James Chun
Kilo Patron

Hey @carram ,

 

First, make sure that your reference qualifier is not being overridden in the child tables (i.e. Case, Work Order, and Work Order Task). You can check it by looking at the related list named 'Dictionary Overrides' under the 'Assignment Group' dictionary record (image2.png). From the list, ensure that your child tables do not have the 'Override reference qualifier' column set to true.

 

Next, your script is almost there, just need to pass the 'current' object to the script. In your function, update the 'taskRefQual' function to take a parameter. i.e.

 

taskRefQual:function (current)

 

Lastly, in your 'Reference qual', update it to be something like:

 

javascript: new ReferenceQualifierUtil().taskRefQual(current);

 

 

That should do the job, let me know how it goes. Thanks!

View solution in original post

3 REPLIES 3

James Chun
Kilo Patron

Hey @carram ,

 

First, make sure that your reference qualifier is not being overridden in the child tables (i.e. Case, Work Order, and Work Order Task). You can check it by looking at the related list named 'Dictionary Overrides' under the 'Assignment Group' dictionary record (image2.png). From the list, ensure that your child tables do not have the 'Override reference qualifier' column set to true.

 

Next, your script is almost there, just need to pass the 'current' object to the script. In your function, update the 'taskRefQual' function to take a parameter. i.e.

 

taskRefQual:function (current)

 

Lastly, in your 'Reference qual', update it to be something like:

 

javascript: new ReferenceQualifierUtil().taskRefQual(current);

 

 

That should do the job, let me know how it goes. Thanks!

Thanks, James,

 

Oh wow, I didn't even know about dictionary overrides, that's pretty sweet! Would it be better then to run my reference qual as an override on the child table? I imagine it'd be better to keep Task dictionary entries as close to out-of-box as possible. 

 

The main reason I ask is because I don't know how the other child tables not listed in my switch statement in image1.png would be impacted. If it makes more sense to parse out my conditions as a dictionary override on each child, I'll do it that way!

 

Thank you so much,

C

Hey @carram ,

 

No worries and great question by the way.

Frankly, either option will be acceptable here. If there is an OOTB override, it won't use your script anyway. So you can modify your script to reflect it and deactivate the override.

But the OOTB ref qualifier condition is 'type=itil AND active=true', so you may want to add it as the default condition in your script.

 

The benefit of defining qualifier at the parent (Task) level is that you can define all the qualifiers in a single place (i.e. your script include). But you may run into a few more conflicts during an upgrade and some admins/developers are more used to using the override functionality. (I think)

 

So in terms of the 'functionality', either option will be ok. But in terms of maintainability, you have the pros and cons. Sorry if it's not a clear answer but hope it helps.

 

Thanks!