Variable Editor for a Catalog Task Generated from a Record Producer

melosborne · ‎02-24-2017

Hello all,

There have been many requests by my client to have "request" forms created in ServiceNow, but the client is asking that these forms require no approvals and all they want is for one task to be created when a form is submitted.

For the client, I created a Record Producer, linked to the sc_task table, which creates a TASK ticket when the form is submitted. Unfortunately, I have hit a large wall when it comes to hiding/displaying the record producer variables in the variable editor.

These TASK tickets, although generated for the sc_task table, do not have RITM or REQ tickets associated with them, which makes the OOB sc_task Variable Editor formatter ignore all of the variables. In addition, the OOB Variable Editor formatter for Incident Record Producers is not a viable option either as this just pulls in ALL variables, regardless of any Catalog UI Policies in place.

Has anyone else come across this issue and been able to create a formatter that accommodates this type of scenario:

Record Producer, linked to the sc_task table, creates a TASK ticket without an REQ or RITM ticket associated
Certain variables in the form are dependent on the selection of other variables, requiring Catalog UI Policies
sc_task Variable Editor formatter only pulls in variables and applies the Catalog UI Policy if there are REQ or RITM tickets associated
incident Variable Editor formatter pulls in all variables regardless of any Catalog UI Policies

One last note: I have looked into the ServiceNowGuru's article on omitting empty variables from the variable editor, and I was able to get this to work for my case! Unfortunately, I was not able to get the script to take into consideration when the Catalog UI Policies have Catalog Conditions. Soooooo, if anyone knows of a way that I can include a query piece that only brings in the Catalog UI Policy Action if the Catalog UI Policy Condition was met, that would also be incredibly helpful.

Thank you in advanced for any help!

-Mel

Joe McCarty1 · ‎02-25-2017

It seems like a lot of effort just not to create the REQ and RITM like the system is architected to do. Catalog Tasks have variables related to them through the RITM (sc_item_variables_task in conjuction with the request item reference vs question_answer for most other tasks) and so are unique among tasks. As you pointed out, they also have the unique capability to have catalog ui policies applied to them.

The REQ and RITMs don't have to be assigned so no one needs to see them in their queues and they should be pretty easy to exclude from any reporting based on item.

And I'm afraid whatever you try to build will either conflict with what you are doing for proper catalog tasks (i.e. associated with items) or will be fragile for upgrades.

So I guess the question for me is what requirement or business need is driving this atypical use of catalog task?

melosborne · ‎02-27-2017

Hello Joe,

I apologize if what I was initially asking was unclear. I am not trying to link REQ/RITM to this catalog task. I am just creating a Catalog Task off of a record producer and am having trouble getting a variable editor formatter that works fine for catalog tasks with REQ/RITM tickets, to work for once without REQ/RITM tickets.

This is the variable editor that shows or hides variables depending on the catalog ui policies if the catalog task has REQ/RITM tickets:

<?xml version="1.0" encoding="utf-8" ?>

<j:jelly trim="false" xmlns:j="jelly:core" xmlns:g="glide" xmlns:j2="null" xmlns:g2="null">

<j2:if test="$[current.canRead()]">

<g:requires name="scripts/js_includes_catalog.js" includes="true"/>

<g:requires name="styles/${new CatalogCssSelector().getVariableCss()}" includes="true"/>

<g2:evaluate var="jvar_catalog_item">

function eval_cat_item() {

var cat_item = "";

var className = current.getRecordClassName();

if (className == "sc_req_item") {

cat_item = current.cat_item;

} else if (className == "sc_task") {

cat_item = current.request_item.cat_item;

}

return cat_item;

}

eval_cat_item();

</g2:evaluate>

<g2:evaluate var="jvar_cat_sets" jelly="true">

var jvar_cat_sets = "";

var gr = new GlideRecord("io_set_item");

gr.addQuery("sc_cat_item", jelly.jvar_catalog_item);

gr.query();

while (gr.next()) {

if (jvar_cat_sets.length > 0)

jvar_cat_sets += ",";

jvar_cat_sets += gr.variable_set;

}

jvar_cat_sets;

</g2:evaluate>

<j2:if test="$[jvar_catalog_item != '']">

<g2:client_script type="catalog_item" catalogItem="$[jvar_catalog_item]"/>

<g:inline template="catalog_ui_policy.xml" />

<g2:render_component componentName="com.glideapp.questionset.DefaultQuestionEditor"/>

</j2:if>

</j:jelly>

I tried to fiddle with this script, but have been unable to get the variable editor formatter to apply to a catalog task that does not have REQ/RITM tickets associated. What I have done instead of took an article for hiding empty variables from the variable editor from the ServiceNowGuru, and work it a little differently.

I created a new field for the sc_task called u_record_producer that links to the current record producer
I created a business rule that runs on Display with the following script:

(function executeRule(current, previous /*null when async*/) {

//Initialize the scratchpad variable

g_scratchpad.hiddenVars = '';

// Get UI Policies for the record producer that apply to task

var uiPolicy = new GlideRecord('catalog_ui_policy');

uiPolicy.addQuery('applies_sc_task', true);

uiPolicy.addQuery('catalog_item', current.u_record_producer);

uiPolicy.addQuery('client_script', true);

uiPolicy.query();

while (uiPolicy.next()) {

gs.addInfoMessage(uiPolicy.client_script);

var policyName = uiPolicy.sys_id;

var hiddenVars = [];

var gr = new GlideRecord('catalog_ui_policy_action');

gr.addQuery('catalog_item', current.u_record_producer);

gr.addQuery('visible', false);

gr.addQuery('ui_policy', policyName);

gr.query();

while (gr.next()) {

//Add variable names to the emptyVars array

hiddenVars.push(gr.variable.toString());

g_scratchpad.hiddenVars = hiddenVars.join();

}

//Store the result in the scratchpad

}

gs.addInfoMessage(g_scratchpad.hiddenVars);

})(current, previous);

Then I added the following script to an already existing onLoad client script for sc_task:

if (g_scratchpad.hiddenVars != '') {

g_form.addInfoMessage('client script is running for hiding variables');

var hiddenVars = g_scratchpad.hiddenVars.split(',');

for (var i = 0; i < hiddenVars.length; i++) {

g_form.setDisplay('variables.' + hiddenVars[i], false);

}

I was able to get this to show and hide variables appropriately based on the ui catalog policy with one drawback, the script does not take into consideration whether the catalog policy conditions are met or not and just applies ALL catalog policies for that record producer.

I am trying to describe what I am trying to do as clearly as I can… hopefully these additional details help.

- Mel

Goran WitchDoc · ‎02-27-2017

I would say that you go through a lot of trouble that you can skip using the OOB REQ/RITM/TASK way.

skip the record producer, create a catalog item without an approval and create a task in the workflow.

Like Joe says, it's faster to "hide" the req/RITM from those who don't want to see it than to fiddle like this with the fun jelly stuff.

//Göran

melosborne · ‎02-27-2017

Hello Goran,

We are just trying to not have to use workflows with every request form we would possibly ever make. Even if we don't have an approval set up, email notification would still be sent for when the REQ status is changed to Approved in order to make the RITM ticket and the client has expressed on many occasion that they do not want to be bombarded with emails all the time. On top of that, we do have a large number of more complex request forms that had to have workflows, with approvals, so the email notifications can't just be turned on or off.

I was really hoping that there was just a way to get the variable editor on the catalog task to take the ui catalog policies into account from the record producer, without having to hard-code each record producer individually.

-Mel