Notifications

645 views

Description

Intermittent issue where customer Submits a form and it gets stuck on Submitting... on Service Portal. This issue has been noticed in very few customer instances and the precise root cause of this issue is still unknown.

The console in developer tools displays a 400 (Bad Request) error when the issue is reproduced. If you expand, the error message is as follows:

"Security constraints prevent ordering of Item"

This message is coming from one of the Scripted REST resources (sys_ws_operation):

1. Submit a Record Producer

2. Buy Item

canView() seems to be failing from the above Scripted REST resources.

Another symptom of this issue can be where customers can see catalog items that they do not have access to and vice versa.


Steps to Reproduce

This issue has not reproduced in Out of box instance.

A common configuration with all the instances facing this issue is at least one scripted User Criteria on the affected catalog item. 

The user critera has GlideSystem objects such as gs.getUsedID, gs.getUser or gs.getSession

Here is an example user criteria that can cause this issue:

var udc=gs.getUser().getRecord().getValue('u_company_code'); //the important part is gs.getUser()
if (udc=="xyz"){
answer = true;
} else {
answer = false;
}

The issue may be due to user criteria changing scope intermittently to sn_sc (Service Catalog Rest API) from Global and making any session object like gs.getUsedID() , gs.getUser() or gs.getSession() undefined.


Workaround

There is only one API that does not work in scope, gs.getUser().getRecord(), which is  expected behaviour.

But why would the sys_user record be necessary for User Criteria?

If the fields available in User Criteria is not sufficient, and customer needs more fields from sys_user table, please extend User Criteria.

https://docs.servicenow.com/bundle/madrid-it-service-management/page/product/service-catalog-management/task/t_ExtendUserCriteria.html

This prevents creating scripted user criteria.

If there are some other tables like hr_profile where the user id is needed, please don't use gs.getUserID() or any Session APIs in Scripted User Criteria.

This breaks the User Criteria evaluation in any diagnostic tools.

There is a magic variable "user_id" which is available That has the user which is used to evaluate the User Criteria. That should be used to query hr_profile.

For Scoped User Criteria customer might hit PRB1353133 which would have a workaround posted in that KE.


Related Problem: PRB1319258

Seen In

Jakarta
Kingston
SR - IRM - Audit Management - New York 2019 Q3
SR - IRM - GRC Profiles - Madrid 2019 Q2
SR - IRM - GRC Workbench - New York 2019 Q3
SR - IRM - PA Premium Integration - New York 2019 Q3
SR - IRM - Policy and Compliance - Madrid 2019 Q2
SR - IRM - Risk Management - New York 2019 Q3
SR - IRM - Vendor Risk Management - Madrid 2019 Q1
SR - ITOM - CMDB CI Class Models - 201908
SR - ITOM - Discovery and Service Mapping - 201908
SR - ITOM - Fundamentals Istanbul Jakarta Kingston r1 - v5.99.6
SR - SecOps - Configuration Compliance - New York 2019 Q3
SR - Security - Integration Framework - Madrid 2019 Q2
SR - Security - Support Common - Madrid 2019 Q2
SR - Security - Support Orchestration - Madrid 2019 Q2
SR - SIR - RecordedFuture Integration - New York 2019 Q3
SR - SIR - Security Incident Response - Madrid 2019 Q2
SR - SIR - Security Incident Response PA Content - New York 2019 Q3
SR - SIR - Splunk Sighting Search Integration - Madrid 2019 Q1
SR - SIR - Store SecOps Setup Assistant - Madrid 2019 Q2
SR - SIR - Store Threat Core - Madrid 2019 Q2
SR - SIR - Store Trusted Security Circles Client - New York 2019 Q3
SR - SIR - Store Trusted Security Circles Client Advanced- Madrid 2019 Q1
SR - SIR - Threat intelligence - New York 2019 Q3
SR - SIR - VirusTotal Integration - New York 2019 Q3
SR - VR - Vulnerability Response - New York 2019 Q3
SR - VR - Vulnerability Response PA Content - Madrid 2019 Q2

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2020-03-23 05:11:09
Published:2020-02-11