onLoad Catalog Client Script Not Working Properly on List Collector

[jmiskey]

We are using London, and are experiencing some odd behavior when trying to apply an onLoad Catalog Client Script to a List Collector variable in one of our Catalog Items.  Let me lay it out for you.

First, we have a lookup table that our List Collector References:

Table Name: u_cotiviti_input_environment

Fields: u_input_environment (mandatory display field), u_inactive (defaults to false), u_order, u_notes

And this is how the variable is set up in our Catalog Item:

And then I have the following onLoad Catalog Client Script on this field:

The function in my Script Includes that it is calling does this:

So, what this Catalog Client Script is supposed to do, is if there is EXACTLY one record in my lookup table, to automatically select that value and lock it down (make it read-only).  The reason for this is because currently, there is only one value in the lookup table.  However, new ones will be added in the future.  In the meantime, they want it to default to this one value and not allow them to change that.

So, in filling out the form on the Service Portal, everything works exactly as it should.  It defaults the value and locks it down, like this:

But, for some reason, it does not seem to pass it down to the RITM or the Task.  This is what we see on those:

Does anyone know if this is a bug?  I found some old threads that talked about issues with Catalog UI Policies on List Collectors that had similar results, and it looks like there was a known bug there (but trying the same workaround did not work on this).

If I cannot figure out how to do this, I guess the best workaround I can think of is to make the variable mandatory, and set a default value.  If I need to go that route, what is the best way of setting a default value on a list collector variable?  Can I do it right on the variable itself, or do I need to use an onLoad Catalog Client Script for that (and hopefully that will not have the same problem)?

[Stewe Lundin]

Hi!

You need to return bot the text and the sys ID for the record you want to populate in the list collector. 

In this case I send a string contain 2 joined arrays, separated with '||'
Parts of the Client side:

function populateListCollector(response){
	var answer = response.responseXML.documentElement.getAttribute('answer');
	//g_form.addInfoMessage('Populate Cost Center Slushbucket answer:' + answer)
	var arr = answer.split('||');
	//g_form.addInfoMessage('arr:' + arr)
	//arr[1] has the sys_id of the users
	//arr[0] has the display name of the users
	if (window === null)
		g_form.setValue('cost_center', arr[1], arr[0]); // Mobile Compatible
	else
		addItemstoList('cost_center', arr[1], arr[0]);
}

Parts of  the server side code:

var group_gr = new GlideRecord('sys_user_grmember');
		group_gr.addEncodedQuery('group.nameSTARTSWITHcc_^group.nameLIKEbehörig beställare');
		group_gr.addQuery('user',user_sys_id);
		group_gr.addQuery('group.cost_center.u_company.u_manager',filter_user_sys_id);
		group_gr.query();
		while(group_gr.next()){
			returned_cost_center_name.push(group_gr.group.cost_center.name.toString());
			returned_cost_center_sys_id.push(group_gr.group.cost_center.toString());
		}
		returned_cost_center_name = returned_cost_center_name.join();
		returned_cost_center_sys_id = returned_cost_center_sys_id.join();
		return returned_cost_center_name +  '||' + returned_cost_center_sys_id;	

But the secret is the name and sys_id...

[randrews]

what he said is correct.. but i have a more basic question... why do the client script/ajax call at all??

if you are filtering your list collector from a variable based on a column.. make sure the values for the selections match exactly the values from the table and set the reference qualifier... for example...

javascript:'u_active=true^u_group=' + current.variables.v_wb_group5  

in the above.. i have a variable v_wb_group5 that matches the values on the table in the column u_group... .so it will filter them automagicly..

since this is a list collector you need it to reload the choices every time the variable it is based on changes.. to do that in the attributes <on the default value tab> add something like this...

ref_qual_elements=v_wb_group5,no_filter

no filter removes their ability to modify/change the selections in the left block... the ref_qual_elements= v_wub....  tells it to reload the list collector when the variable that is filtering the list is changed.

that will limit your list collector options the only thing left is a client script to clear the right side if the variable the list collector is based on changes...

the following script will do this for BOTH classic view and ServicePortal.. just replace the collector name with your list collector variable name.. and put this in an onchange script on the variable that controls the list collector.

set the list collector as mando .. and they can't submit without selecting one.. and you don't have to modify your script when you get more options!!

function onChange(control, oldValue, newValue, isLoading) {
    if (isLoading) {
        return;
    }
    //Type appropriate comment here, and begin script below
    g_form.setValue('v_wb_group_all', '');
    var collectorName = 'v_wb_subgroup';
    
    if(window === null) {
        var myListCollector = g_list.get(collectorName);
        var selectedOptions = g_form.getValue(collectorName).split(',');
        if((selectedOptions != "") && (selectedOptions.length > 0)){
            //Remove items
            var index = 0;
            for (var i = 1, leng = selectedOptions.length+1; i < leng; i++){
                myListCollector.removeItem(selectedOptions[selectedOptions.length-i]);
                index++;
            }
        }
    }
    else{
        clearright(collectorName);
    }

[jmiskey]

Thanks for the replies.

We actually ended up going a different route yesterday, which seems sufficient, and is pretty simple.  We made the field mandatory, and set the default value (which I was not able to get working earlier because I didn't realize that I need to put the sys_id, not the value, in the Default Value box).

If there is only one valid option, they cannot change it to anything else.  They could "remove" it, but then they would not be able to submit the request, since it is a Mandatory field.

That works for us.