Lately, I've been writing about some pesky issues in Service Catalog, particularly with variables and UI policies. My most recent blog post was about an error that appeared after a new variable or UI policy was added to an existing catalog item with outstanding requests. In this blog post, I'd like to give you some more information about a Service Catalog issue where catalog UI policies and catalog client scripts can fail when a write role is specified on the variable.
For a little context, remember that the Service Catalog is an important part of many ServiceNow implementations. The Service Catalog gives users a menu of product and service options, such as ordering a laptop or requesting software installation. Variables allow you to offer choices when users order catalog items, such as selecting a phone color. UI policies enable you to dynamically change information on a form, such as hiding some questions on a form based on user responses.
Clashing variable role, catalog UI policies, and catalog client scripts
In certain patches of Eureka, Fuji, Geneva, and Helsinki, users are experiencing an issue where catalog UI policies and catalog client scripts fail when a write role is specified on the variable and the user views the record as a user that fails the role check (for example, ITIL user). This happens with catalog UI policies and catalog client scripts set to one or both of the following:
- Applies on Catalog Tasks
- Applies on Requested Items
In the example below, the Disable type and details fields catalog UI policy (applied to the Packaging and Shipping catalog item) has both settings selected:
Symptoms of this issue include (but are not limited to):
- catalog client scripts not working
- reference picker dialogs not opening
You can verify the issue if you check the JavaScript console and see a script error:
js_includes_catalog.jsx:132
Uncaught TypeError: container.getAttribute is not a function
We have seen the issue occurring on the sc_task and sc_req_item forms running a catalog client script that sets a filter on a list collector type variable. When the admin write role on the list collector variable was removed, the form was correct and the error did not appear.
For the most current information about versions in which this issue has been seen and has been fixed, view the known error article associated with the problem: KB0594575: Catalog UI policies are not applying to variables in a RITM / Catalog Task variable edito.... You can subscribe to the known error article and be automatically notified when there are changes (such as the addition of new "fixed in" versions) by clicking the Subscribe button in the upper right corner of the article.
Upgrade or use an onLoad Catalog Client Script
Upgrading to one of the versions where the issue is fixed is your best bet, but if you cannot upgrade at this time, we have a workaround. Follow the steps below to create an onLoad catalog client script that applies only to RITM and Catalog Task.
- Navigate to Service Catalog > Catalog Policies > Catalog Client Scripts.
- Click New.
- In Type, select onLoad.
- Select the Applies on Requested Items option.
- Select the Applies on Catalog Tasks option.
- In Script, add the appropriate code:
Use this script with Geneva Patch 4 and earlier versions:
var isAdmin = g_user.hasRole('admin');
if (!isAdmin)
{
$j('div[id^=label_ni\\.VE]').parent().attr('name', 'checkbox_container');
}
Use this script with Geneva Patch 5, Geneva Patch 6, and Geneva Patch 7:
var isAdmin = g_user.hasRole('admin');
if (!isAdmin)
{
$j('[name=checkbox_container_label]').filter(function() {
return this.parentNode.parentNode.parentNode.parentNode.parentNode.parentNode.getAttribute('name') != 'checkbox_container';
}).removeAttr('name');
}
For more information about creating catalog client scripts, including details about each field, see Create a catalog client script in the product documentation.
Additional information
General information about Service Catalog variables and UI policies is available in the product documentation:
1 Comment
