How to customize oob sc catalog item widget to allow for multiple submissions of a record producer?

[dpalmer]

Hello everyone;

We are on the London instance, and utilizing the new oob widget for submitting catalog items. I would like to know if anyone had any ideas for an enhancement I am working on, in which we have a cloned copy of the sc_cat_item widget embedded on the homepage of our site, and I would like to be able to allow users to submit an incident, and once submitted, the form fields reset themselves and allow the users to resubmit the form again. Right now I am utilizing a widget macro that allows me to reset the fields and even show a custom characters remaining label, which allows me to successfully clear form fields from there. When attempting to submit from the record producer more than once, I get an error: "Unique Key violation detected by database (Duplicate entry '< sys id displays here >' for key 'PRIMARY')" . An incident number is generated, however when i search that number in servicenow, no record appears. Let me know if there is more context I can add that might help.

[Allen Andreas]

Hi,

It sounds more like you need to adjust the logic of the submit or order button for the widget to refresh the screen, submit current item, keep them on the same item, but refresh. I'm not sure if you want that behavior for every single item, or an additional button you create that just say (order more like this) or something and it's a separate thing.

Ultimately, you'd want to look at just simply refreshing the page (like a classic F5 situation). This would allow submission and then refresh the page.

Portal code and back-end code are different in various scenarios, but this works in back-end: action.setRedirectURL(current);

So you'd want that in the client script portion of the widget, inside the function that fires once the button is clicked.

Please mark reply with Helpful/Correct, if applicable. Thanks!

[dpalmer]

Hey Allen, 

Right now the structure of our homepage doesn't really allow for a whole refresh for sake of user experience. We have the embedded form: 

And once complete, we launch a modal:

We also have additional sections on this page for seeing activity data that i wouldn't want to fetch again if it could be avoided. Right after the user submits the incident, the form scrolls back up and the modal appears. I have attempted retrieving the widget via ajax, and loading it dynamically, so on page load the incident is there, and after submission, i tried making an ajax request for the same widget again to see if that helped, but it does not. Previous to this i was using all custom fields, an sn record picker field, a text area, and a custom attachment script, however with the addition of now wanting to add users to a watch list on an incident, i really dont want to have to find a third party library to work with to recreate the portal slushbucket and basically reinvent the wheel.

[dpalmer]

Hey Allen,

After getting some sleep and approaching it again, I may have solved the issue. I first get my record producer client side utilizing spUtil: 

spUtil.get("sh-incident-form-producer").then(function(response) {
		$scope.catalogItemWidget = response;
		var template = $compile('<div id="sh-incident-form-embedded"><sp-widget widget="catalogItemWidget"></sp-widget></div>')($scope);
		angular.element($("#incident-form")).append(template);
	});

Then, after the user submits the form, i remove that element with jquery and add it again. So in all I have an html element i can append to, and my client controller looks like this: 

function($scope, $timeout, snAttachmentHandler, $uibModal,spUtil,$rootScope,$compile) {
	var c = this;
	spUtil.get("sh-incident-form-producer").then(function(response) {
		$scope.catalogItemWidget = response;
		var template = $compile('<div id="sh-incident-form-embedded"><sp-widget widget="catalogItemWidget"></sp-widget></div>')($scope);
		angular.element($("#incident-form")).append(template);
	});

	$rootScope.$on("closeForm",function(){
		resetForm();	
	}); 

	$rootScope.$on("resetWidget",function(){
		resetWidget();	
	});

	//reset form function
	function resetForm(callback){
		if(callback){
			angular.element(".incidentFormBlock").fadeToggle(callback);
		}else{
			angular.element(".incidentFormBlock").fadeToggle();	
		}
		$scope.toggled=false;
		$scope.$emit("scrollUp");
	}

	//reset widget
	function resetWidget(){
		resetForm(resetIncidentWidget);	
	}

	//call back to remove widget from dom and add again
	function resetIncidentWidget(){
		angular.element("#sh-incident-form-embedded").remove();
		spUtil.get("sh-incident-form-producer").then(function(response) {
			$scope.catalogItemWidget = response;
			var template = $compile('<div id="sh-incident-form-embedded"><sp-widget widget="catalogItemWidget"></sp-widget></div>')($scope);
			angular.element("#incident-form").append(template);
		});
	}


} //end all

I may rewrite it to clean it up and make it more efficient, but using jquery's .remove() function to remove the entire sp-widget directive from the dom and re-adding seems to have solved it for now. I'll let you know of any bugs i might catch, and if I find a more "angular" way to do it.

[Allen Andreas]

Ok, good news. I was going to type up a response, but I see you have a good grip on it now.

All sounds and looks good and echos the similarity, slightly, of a refresh, but it a more sophisticated way.