Using GlideSystem objects such as gs.getUser(), gs.getUserID(), gs.getSession() in User Criteria does not work consistently. Form gets stuck on Submitting... on Service Portal. Users can see catalog items that they do not have access to or viceversa. - Known Error

Using GlideSystem objects such as gs.getUser(), gs.getUserID(), gs.getSession() in User Criteria does not work consistently. Form gets stuck on Submitting... on Service Portal. Users can see catalog items that they do not have access to or viceversa. 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/csh?topicname=t_ExtendUserCriteria.html&version=latest

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.