Catalog UI Policies and Catalog Client Scripts that are set to 'Applies on Requested Items' or 'Applies on Catalog Tasks' can fail.

This happens when a write-role has been specified on the variable and viewing the record while logged in as (impersonating) an user that fails on that role check.

Note: While the issue presents itself, scripts such as g_form.setDisplay() do not successfully execute and no errors are thrown in the browser console

Reproduced in demonightlycalgary.

See steps to reproduce

Steps to Reproduce


1. Select a base system (out of box) catalog item to demonstrate.
1a. Navigate to Self-Service > Service Catalog or Service Catalog > Catalog.
1b. Select Hardware.
1c. Select Sales Laptop.

2. Personalize the Additional software requirements variable and give it a name (for example, software_requirements). A name must be specified for the new functionality (Applies on Requested Item/Catalog Task) to work.
2b. Update the Write roles field and add admin.

3. Create a Catalog UI Policy.
3a. Go back to the item (step #1).
3b. Right-click the header and select Personalize UI Policies.
3c. Create a policy such as:

Short Description=hide software requirements
On load=true
Applies on a Catalog Item view=true
Applies on Requested Items=true
Applies on Catalog Tasks=true
- Name: software requirements
- Read only: Leave alone
- Mandatory: Leave alone
- Visible:False

4. Create a request for a Sales Laptop.
4a. Impersonate a non-admin user such as ITIL User.
4b. Follow the steps in step #1 to get to the item and make the request.

5. View the request.
5a. If you are already impersonating ITIL User, navigate to Service Catalog > Items.
5b. Open the item for the request made in step #4.

Expected result:
The Additional software requirements variable should not be visible in the Variable Editor.

Actual result:
Not as expected. The variable is visible.

6. For it to disappear and the UI Policy to work, modify the variable (step #1 and step #2) and remove the role. Then view the Requested Item (step #5).


Create a UI Macro: question_readonly_textarea with the following contents:

<?xml version="1.0" encoding="utf-8" ?><j:jelly trim="true" xmlns:j="jelly:core" xmlns:g="glide" xmlns:j2="null" xmlns:g2="null"> <j:set var="jvar_textarea_height" value="${gs.getProperty('glide.ui.variable.readonly_textarea_height', -1)}" /> <input type="hidden" id="${jvar_question_name}" name="${jvar_question_name}" value="${jvar_question_value}" class="${jvar_question_widget_class}" /> <tr id="${jvar_question_name}_read_only"> <td> <table class="question_spacer ${jvar_question_table_class}" width="100%"> <g:inline template="simple_label_read_only.xml"/> <tr class="${jvar_row_class}"> <td> $[SP] </td> <td width="100%"> <div id="question_display" style="height: ${jvar_textarea_height}em;overflow-y: auto;"> <g:evaluate jelly="true" var="jvar_ta_value" expression="new GlideStringUtil().newLinesToBreaks(jelly.jvar_question_value)"/> <g:no_escape>${jvar_ta_value}</g:no_escape> </div> </td> </tr> </table> </td> </tr></j:jelly>

NOTE: Customers are responsible for removing the workaround before upgrading.

Related Problem: PRB591565

Seen In

Berlin Patch 3 Hot Fix 1
Calgary Patch 2 Hot Fix 12
Calgary Patch 2 Hot Fix 5
Calgary Patch 3 Hot Fix 1
Calgary Patch 4
Calgary Patch 5

Fixed In


Associated Community Threads

There is no data to report.

Article Information

Last Updated:2016-07-25 12:35:25