How to use mandatory checkboxes on Catalog Tasks for fulfiller checklists

Dan R
Kilo Expert

Hi SNC,

I have a request to add several checklists to a workflow so that fulfillers are required to check the boxes before closing the task. While this probably isn't the OOB function for checkboxes, I have found that a client catalog script can solve this problem. The script essentially allows you to identify the checkbox variables, indicate how many checkboxes are required onSubmit, and the task won't close unless the identified-checkboxes are checked. 

Here is the script I used:

 

function onSubmit() {
if (g_form.getValue("state")== "3"){
 // ------------------------------ 
 // Set Checkbox Parameters Here -- this is the only section you should need to change to the script to work.
 // ------------------------------ 
 // List of Checkboxes 
 var requiredCheckboxList = 'task1_checkbox1,task1_checkbox2, ';
 // Number of checkboxes to be required 
 var requiredCheckboxCount = 2;
 // Section Title 
 var sectionTitle = 'Required Checklist';
 
 // ------------------------------ 
 // Run Script
 // ------------------------------ 
 var response = checkboxCheck(requiredCheckboxList, requiredCheckboxCount);
 if (!response) {
alert('You must check all the boxes from the '+sectionTitle+' section before closing the ticket.');
return false;
 }
}

function checkboxCheck (requiredCheckboxArray, myCount) {
 requiredCheckboxArray = requiredCheckboxArray.split(',');
 var answer = false;
 var match = 0;
 for (i=0; i < requiredCheckboxArray.length; i++) {
if (g_form.getValue(requiredCheckboxArray[i]) == 'true') {
 match ++;
 if (match >= myCount) {
answer = true;
break;
 }
}
 }
 return answer;
}}

 

My issue is that there are several Catalog Tasks on a single RITM, but this onSubmit script is added to the Catalog Item, so it ends up applying to EVERY task, instead of applying the proper checklist to each task 1 at a time. Obviously this is problematic, because each checklist has different variables so there must be something I have to do to alter the script so it identifies the task with the associated set of checklist variables.

1 solution I have thought of is to create static variables that don't change, and make those variables appear on each task so I can use that variable to identify the task and the associated checklist to that task. However my issue with this is that it seems a bit clunky and I can't figure out a way to say "If static_variable1 is visible, use checklist a, if static_variable2 is visible, use checklist b, and so on". Is there a different method to determine a variable's visibility on a task or another way to do this?

 

Hoping for some good thoughts and feedback from the community. Essentially my issue is (TL:DR), with a catalog client script, how can I identify the task so that the corresponding set of checklist variables can be applied to the catalog script, that way each task has its own mandatory checklist?

 

 

 

Thanks for ANY advice here, been going in circles with this one for a while now.

 

Dan R.

 

 

 

 

 

 

 

1 ACCEPTED SOLUTION

Dan R
Kilo Expert

I'll leave this open so if someone has any ideas they can respond.

 

What I ended up doing was created a few new checkbox variables and set them as default value = true and read only. Hide the checkboxes from everywhere but the Catalog Task. Then, I made each checkbox visible only on the relevant task (via workflow editor), and then wrote a script that says:

function onSubmit() {
			if (g_form.getValue("state")== "3"){
			// ------------------------------
			// Instantiate Variables Here
			// ------------------------------
			// List of Checkboxes
			var requiredCheckboxList = 'checkbox_1,checkbox_2,checkbox_3,checkbox_4,checkbox_5,checkbox_6,checkbox_7,checkbox_8, ';
			// Number of checkboxes to be required
			var requiredCheckboxCount = 8;
			// Section Title
			var sectionTitle = 'Required Checklist';
			var response;
			
			//------------------------------
			// Set variables here based on below if statement to determine which set of checkboxes to use
			//------------------------------
			if (g_form.getValue("current.variables.checklist1_required") == "true"){
				requiredCheckboxList = 'task1_checkbox1,task1_checkbox2, ';
				requiredCheckboxCount = 2;
				 response = checkboxCheck(requiredCheckboxList, requiredCheckboxCount);
			if (!response) {
				alert('You must check all the boxes from the '+sectionTitle+' section before closing the ticket.');
				return false;
			}
			}
			if (g_form.getValue("current.variables.checklist2_required") == "true"){
				requiredCheckboxList = 'task2_checkbox1_freetext1,task2_checkbox2,task2_checkbox3_freetext2, ';
				requiredCheckboxCount = 3;
				 response = checkboxCheck(requiredCheckboxList, requiredCheckboxCount);
			if (!response) {
				alert('You must check all the boxes from the '+sectionTitle+' section before closing the ticket.');
				return false;
			}
			}
			if (g_form.getValue("current.variables.checklist3_required") == "true"){
				requiredCheckboxList = 'task3_checkbox1,task3_checkbox2,task3_checkbox3,task3_checkbox4, ';
				requiredCheckboxCount = 4;
				 response = checkboxCheck(requiredCheckboxList, requiredCheckboxCount);
			if (!response) {
				alert('You must check all the boxes from the '+sectionTitle+' section before closing the ticket.');
				return false;
			}
			}
			if (g_form.getValue("current.variables.checklist4_required") == "true"){
				requiredCheckboxList = 'task4_checkbox1,task4_checkbox2,task4_checkbox3, ';
				requiredCheckboxCount = 3;
				 response = checkboxCheck(requiredCheckboxList, requiredCheckboxCount);
			if (!response) {
				alert('You must check all the boxes from the '+sectionTitle+' section before closing the ticket.');
				return false;
			}
			}
			if (g_form.getValue("current.variables.checklist5_required") == "true"){
				requiredCheckboxList = 'task5_checkbox1,task5_checkbox2,task5_checkbox3,task5_checkbox4,task5_checkbox5, ';
				requiredCheckboxCount = 4;
				 response = checkboxCheck(requiredCheckboxList, requiredCheckboxCount);
			if (!response) {
				alert('You must check all the boxes from the '+sectionTitle+' section before closing the ticket.');
				return false;
			}
			}
			if (g_form.getValue("current.variables.checklist_not_needed") == "true"){
				requiredCheckboxList = 'checklist_not_needed, ';
				requiredCheckboxCount = 1;
			}
			
			
			
			
		}
	
	function checkboxCheck (requiredCheckboxArray, myCount) {
		requiredCheckboxArray = requiredCheckboxArray.split(',');
		var answer = false;
		var match = 0;
		for (i=0; i < requiredCheckboxArray.length; i++) {
			if (g_form.getValue(requiredCheckboxArray[i]) == 'true') {
				match ++;
				if (match >= myCount) {
					answer = true;
					break;
				}
			}
		}
		return answer;
	}}
	

 

So if my new checkbox variables exists on that task, it will do the action indicated. By using this method, I don't need to have the WF set any special values, as long as the checkbox appears on that task, it will evaluate to true, and run the process. If the variable is not added to the Task from the WF editor, then it will not see the "true" value the checkbox is holding and it will ignore (or evaluate to false).

 

This seems to be a decent option as an alternative to an isVisible function (that doesn't exist anyway!). Hope this helps anyone who had trouble on developing out a solution for this.

 

If anyone else has an idea, feel free to share and discuss.

 

View solution in original post

5 REPLIES 5

ty_roach
Tera Guru

The problem with the OOB checklists is that they are unreliable, meaning, people can change the content of the checklist item after the fact, add items, delete items, change items.  There's also no guarantee that the same checklist will appear for same situation.  There is no way to restrict who can edit the checklist or when it can be edited (like do you really want people changing checklist responses after the record has been closed).

Enter Checklist Pro.  We built Checklist Pro to solve all those problems and more.  Checklist Pro application administrators can define when checklists get created and associated with records in a table (any table - not just those that extend TASK), when these checklists can be edited, when the associated record is considered "closed" (and thus should prohibit further checklist updates).  We even added the ability to define "Required" checklist items that allow enforcement, thereby preventing a record from closing unless the required items are completed.  We've built convenience Database Views to go with the most common checklist tables, which include TASK, SYSAPPROVAL_APPROVER, CMDB_CI.

They work in the Service Portal as well as in the Classic UI.

They'll work with other Scoped Applications (like HR or SecOps or even custom scoped apps & tables).

For more information contact TyGR LLC or goto our youtube channel to see it in action.