Record Producer Will Not Submit Record on Service Portal

[Ben Cervantes]

Has anyone ever seen this message before. I am attempting to submit a new record from a record producer in our catalog and the submit button has "submitting" next to it but it never completes. Opened the console up and was able to see this error. Any ideas on where I could track down the root cause?

[sachinbhasin11]

Hi,

Just check if there is any UI policy/Client Script that is hiding a field that is set as 'Mandatory' this won't allow you to submit the request and will keep displaying 'Submitting'

[Ben Cervantes]

I was able to find the onChange client script that was having the issue. It is saying that I am throwing an exception GlideAjax error. These are the two scripts that are having the issue, this was created by an admin that is no longer with us. Is this best practice to call the script include? When I turn the scripts off the form is able to submit a record. 

Script Include

var sarAccessList = Class.create();
sarAccessList.prototype = Object.extendsObject(AbstractAjaxProcessor, {
	
	userInfo: function() {
		var systems;
		var user = this.getParameter('sysparm_user');
		var gr = new GlideRecord('sys_user');
		gr.addQuery('sys_id', user);
		gr.query();
		if (gr.next()) {
			
			// Set variable information for mapping
			var jobCode = gr.u_job_code.getDisplayValue().substring(0,5);
			var deptCode = gr.department.id;
			var mapName = jobCode + ' - ' + deptCode;
			
			var template = new GlideRecord('u_template_mapping');
			template.addQuery('u_mapping_name', mapName);
			template.query();
			if (template.next()) {
				systems = template.u_access_systems.getDisplayValue();
				
			}
		}
		return systems;
	},
	
	type: 'sarAccessList'
});

Client Script 

function onChange(control, oldValue, newValue, isLoading) {
	if (isLoading || newValue == '') {
		return;
	}
	var newHire = g_form.getValue('new_hire');
	if (newHire == 'Yes') {
		var access = g_form.getValue('access_container');
		// Clears values from fields as user changes
		if (newValue != oldValue) {
			g_form.clearValue('access_container');
			g_form.clearValue('access_sys_ids');
		}
		
		// Queries sarAccessList script include
		var ga = new GlideAjax('sarAccessList');
		ga.addParam('sysparm_name', 'userInfo');
		ga.addParam('sysparm_user', g_form.getValue('u_division_user'));
		ga.getXML(accessList);
		
		// Gathers response information
		function accessList(response) {
			var answerFromXML = response.responseXML.documentElement.getAttribute("answer");
			var ar = answerFromXML.split(",");
			// Sets form values
			if (ar.length > 0) {
				g_form.setValue('access_container', ar);
			}
			
			var access = g_form.getValue('access_container');
			if (access != '') {
				g_form.showFieldMsg('access_container', 'Systems updated for provisioning', 'info');
			}
			
			// Queries sarAccessID script include
			var na = new GlideAjax('sarAccessID');
			na.addParam('sysparm_name', 'userInfo');
			na.addParam('sysparm_user', g_form.getValue('u_division_user'));
			na.getXML(accessID);
			
			// Gathers response information
			function accessID(response) {
				var answerFromXMLtwo = response.responseXML.documentElement.getAttribute("answer");
				var arr = answerFromXMLtwo.split(",");
				// Sets form values
				g_form.setValue('access_sys_ids', arr);
			}
		}
	}
}

[joshuamayes]

I had a similar issue, it looks like the official recommendation is to upgrade your instance. Here is what Hi responded with:

The problem is documented in the problem document - PRB1303324. But the development team had identified that as a duplicate of PRB1248440 which I am attaching with the incident for your reference(Since the other one is closed as a duplicate, you will not be able to see the prb). The issue is fixed in Kingston Patch 12 and London releases. If you want to have a permanent resolution, upgrading to those versions would be the option rather than creating scoped ACLs as a workaround. 

Here's the Known error Doc for PRB1248440:  https://hi.service-now.com/kb_view.do?sys_kb_id=e63807e9dbbbd7c054250b55ca961964

In my specific case my record producer was in a scoped application and I was able to implement a workaround by adding the following ACL to the application:

READ for sc_cat_item_producer, no roles, no script, no condition. 

Hope this helps!

[Sumanth16 · Accepted solution]

Hi Ben,

We faced same issue after London upgrade .We cloned catalog item widget again and started using that widget in portal.

There is lot of knowledge of articles related to this issue.Please refer below HI-knowledge articles:

https://hi.service-now.com/kb_view.do?sysparm_article=KB0656139

https://hi.service-now.com/kb_view.do?sysparm_article=KB0683981

https://community.servicenow.com/community?id=community_question&sys_id=ca8907a5db5cdbc01dcaf3231f961936

Thanks,

Sumanth