Multi-Row Variable Set Not Displaying Properly in Catalog Task

jmiskey
Kilo Sage

So I have a tricky Catalog Item/Workflow I am working on.  I need to create and pre-populate a Multi-Row Variable Set (MRVS) from a data table we have in ServiceNow.  Our ultimate goal is to have this display only on the Catalog Task that the Workflow creates once the Catalog Item is submitted, and to allow the Task assigners to fill it out, and we would like to take away the Add/Remove options from the MRVS, so all that they can do is edit the existing pre-populated records.  But we are taking this bit-by-bit.

I have run into a problem with how the MRVS is being displayed in the Task.  I have temporarily disabled my Catalog UI Policies which hide it from the Catalog Item on the Service Portal and from the RITM that gets created, to see if that helps.  So right now, it shows in all three places.

Here is what it looks like on the Service Portal:

find_real_file.png

Here is what it looks like on the RITM:

find_real_file.png

And here is what it looks like on the Task:

find_real_file.png

As you can see, for some reason, the "Actions" title is being removed from the Header row on the Task, so all the Titles are shifted over one, and do not line up with the actual data.

Does anyone have any idea on what might be causing this behavior, or do you have any idea on how to correct it?

Thanks

1 ACCEPTED SOLUTION

jmiskey
Kilo Sage

OK, so it turns out that there was an general Client Script that we had that was affecting this.

So we had to amend the Client Script which is running against the onLoad event of the Catalog Task table like this (this is just a portion of a much larger script in there that accounts for various exceptions):

		//Make variables editable if Task is active for this Catalog Item, otherwise lock
	else if(((g_form.getValue('request_item.cat_item') == "720f2816db91d010bc827afc0f9619b3"))){
		if(g_form.getValue('active') == "true"){
			g_form.setVariablesReadOnly(false);
		}else{
			g_form.setVariablesReadOnly(true);
		}
	}

Then we moved the script to hide the Add/Remove options on the MRVS out of our Catalog Client Script (that is used to pre-populate the MRVS), to a basic Client Script that runs onLoad of Catalog Task, with this code:

function onLoad() {

	//Get values
	var catItem = g_form.getValue('request_item.cat_item');
		
	//Run on Security Termination Form
	if (catItem == '720f2816db91d010bc827afc0f9619b3' && g_user.hasRole('Security Catalog')){

		setTimeout(function () {

			//hide the add/remove table
			var z = this.document.getElementsByClassName("sc-table-variable-buttons");
			//       alert(z.length);
			var k;
			for (k = 0; k < z.length; k++) {
				z[k].style.display = 'none';
			} 


			//remove "x" (delete) from individual records
			var y = this.document.getElementsByClassName("btn btn-sm icon-cross multi-row-delete-row");
			// alert(y.length);
			var j;
			for (j = 0; j < y.length; j++) {
				y[j].style.display = 'none';
			} 

		}, 1000);

	}

}

Once we did all this, the headers appeared as they should.  (Note: We chose to do the above script in a Client Script, so we can re-use it easily if we have other MRVS that we want to set up in the same manner).

So we have the MRVS only being displayed on the Catalog Task (not on Catalog Item or Requested Item).  We use a Catalog UI Policy to hide it in theose places.  The Catalog Client Script that pre-populates the MVRS only runs against the Catalog Item.  That prevents it from re-running and overwriting all changes made to it when it is opened up in the Task. 

The variables are editable only while the Task is active.  Once it is closed, everything is locked down, which is exactly the way we need it to work.

So, finally, eveything working just the way we needed!

Thanks to all who chimed in and helped steer me in the proper direction.

 

 

View solution in original post

12 REPLIES 12

Ankur,

I think you may have gotten off on a tangent, and the question I am trying to get answered has gotten lost in the shuffle.  Granted, I still have some work to do with the buttons, but that is NOT the question I asked in this thread.  Right now, my main concern is the question I asked and detailed in my original post, which is "Why is the "Actions" header being dropped when viewing the MRVS in Catalog Task?

As I showed in my original post, it looks fine when viewed in the Service Portal, and it looks fine when viewed on the RITM.  But for some reason when viewing from the Catalog Task, the "Actions" header disappears, and all the other headers shift over, so the headers are above the wrong fields/variable (see the third image in my original post).

I am trying to figure out why that is happening, and how to correct it.  Please, let's focus on that question.

Thank you.

Ankur,

So we are now trying to simplify this a bit.  Instead of trying to create a Catalog Task with the MRVS on it, we are trying to just have the RITM (which we can assign to the group designated to work it).  

So, when I go in to view the RITM as an Admin, the MRVS looks correct to me.  It looks like this:

find_real_file.png

However, if I view it as a member of the group that it is assigned to, the RITM seems to have the exact same problem that my Catalog Task did.  It does not show the "Actions" header, and slides all of the other headers to the left like this:

find_real_file.png

I am trying to prevent this from happening.  It is odd that it looks correct when an Admin views it, but not when someone else does.  What could be causing this?

By the way, I did try the scripts you posted in the last post, regarding hiding those buttons, and that does work for that separate issue I was having, so thank you for that.  The only other thing I want to do is remove the "x" under the "Actions" which allows them to remove certain rows, leaving just the pencil "edit" option.

jmiskey
Kilo Sage

OK, so it turns out that there was an general Client Script that we had that was affecting this.

So we had to amend the Client Script which is running against the onLoad event of the Catalog Task table like this (this is just a portion of a much larger script in there that accounts for various exceptions):

		//Make variables editable if Task is active for this Catalog Item, otherwise lock
	else if(((g_form.getValue('request_item.cat_item') == "720f2816db91d010bc827afc0f9619b3"))){
		if(g_form.getValue('active') == "true"){
			g_form.setVariablesReadOnly(false);
		}else{
			g_form.setVariablesReadOnly(true);
		}
	}

Then we moved the script to hide the Add/Remove options on the MRVS out of our Catalog Client Script (that is used to pre-populate the MRVS), to a basic Client Script that runs onLoad of Catalog Task, with this code:

function onLoad() {

	//Get values
	var catItem = g_form.getValue('request_item.cat_item');
		
	//Run on Security Termination Form
	if (catItem == '720f2816db91d010bc827afc0f9619b3' && g_user.hasRole('Security Catalog')){

		setTimeout(function () {

			//hide the add/remove table
			var z = this.document.getElementsByClassName("sc-table-variable-buttons");
			//       alert(z.length);
			var k;
			for (k = 0; k < z.length; k++) {
				z[k].style.display = 'none';
			} 


			//remove "x" (delete) from individual records
			var y = this.document.getElementsByClassName("btn btn-sm icon-cross multi-row-delete-row");
			// alert(y.length);
			var j;
			for (j = 0; j < y.length; j++) {
				y[j].style.display = 'none';
			} 

		}, 1000);

	}

}

Once we did all this, the headers appeared as they should.  (Note: We chose to do the above script in a Client Script, so we can re-use it easily if we have other MRVS that we want to set up in the same manner).

So we have the MRVS only being displayed on the Catalog Task (not on Catalog Item or Requested Item).  We use a Catalog UI Policy to hide it in theose places.  The Catalog Client Script that pre-populates the MVRS only runs against the Catalog Item.  That prevents it from re-running and overwriting all changes made to it when it is opened up in the Task. 

The variables are editable only while the Task is active.  Once it is closed, everything is locked down, which is exactly the way we need it to work.

So, finally, eveything working just the way we needed!

Thanks to all who chimed in and helped steer me in the proper direction.