List Collector in Service Portal

[Talvin Singh1]

Hello Reader,

I am having issues working in 'List Collector' variable type in Service Portal.Below is the issue I am facing.

I already have an existing Catalog Item in CMS in which one of the variable is of 'List Collector' type. On selecting another variable (which is of type 'Reference'), the values are populating in the right bucket and no value is available for the user to select in the left bucket.

In Service Portal, the values are populating on selecting an option from the 'Reference' field. But, the issue here is, the user has the access to select more options apart from the already populated values.

[Note: In Service Portal, the 'List Collector' has a similar look of a 'Select Box'. The only difference is, more than 1 option can be selected in List Collector.]

Please provide a solution so that the user in Service Portal is restricted from selecting any other values.

Thanks in advance!

[Michael Jones -]

Have you considered / tried setting the List Collector to read only? If you are only populating that field via script, setting it to read only with a UI Policy or a client script might do the trick. 

The only other method I could think of to prevent them from selecting additional options would be to use a dynamic reference qualifier. Add a hidden variable somewhere and onchange of your reference field make a call server side (glideajax) to return a list of specific sys_id's that you want displayed in the list, populate the hidden field with 'sys_idIN' + <comma_separated_list_of_ids>, use a ref_qual_elements attribute in your list collector to tie in your hidden variable and then make your reference qualifier javascript:current.variables.<hidden_variable>.

Hopefully read only works. 

If this was helpful or correct, please be kind and click appropriately!

Michael Jones - Proud member of the CloudPires Team!

[Brad Bowman]

It sounds like you already have a catalog client script running when the reference field changes.  It would be helpful if you posted that script.  In general, in addition to populating the (right side of) the list collector variable, this script can also alter the list collector filter (the left side).  Depending on the method you used to do this in your script, you probably already have lines like this that work in CMS

window['u_users' + 'g_filter'].reset();
window['u_users' + 'g_filter'].setQuery('group=' + newValue);
window['u_users' + 'acRequest'](null);

Where u_users is the name of the list collector variable.  In this example it's a reference to sys_user_grmember, and I'm filtering by the group selected when this script was triggered.  So what you're missing are similar lines that work in Service Portal

var myListCollector = g_list.get('u_users');
myListCollector.reset();
myListCollector.setQuery('group=' + newValue);

The typical format for including both code blocks in an onChange catalog client script is like this

try{
  var myListCollector = g_list.get(varName);
  myListCollector.reset();
  myListCollector.setQuery(filterString);
 }
 //Revert to Service Catalog method
 catch(e){
  window[varName + 'g_filter'].reset();
  window[varName + 'g_filter'].setQuery(filterString);
  window[varName + 'acRequest'](null);
 }

[Talvin Singh1]

Hi Brad,

Thank you for the response.

Could you please tell me what should be passed in .setQuery (in both CMS and Portal)? Also, what 'type' of data should it be?

In my case, I am getting a list of sys_id's (that needs to be populated) from the script include. I need to make use of these sys_id's to display the values in the 'list collector' variable.

Currently, I am making use 'setValue' which is setting the values in the list collector. But, the user still has the access to select further options available in the list collector.

Thanks.

[Brad Bowman · Accepted solution]

The new query can be simple, like in the first example 

'group=' + newValue

If that fits your scenario (the table your list collector is referencing, and the records you want to return based on the reference variable record selected).  The second example is a variable name that could be populated by your catalog client script calling a GlideAjax script include.  This is used when the filter criteria is more advanced and needs a server script to process it / GlideRecord to other tables, etc.  When you use this method the variable should contain a comma-separated list of sys_ids.  You can read my full article here, which may help your situation

https://community.servicenow.com/community?id=community_article&sys_id=28040fa4db2788905129a851ca961... 

In CMS you have no values available to select from the left, so that's why I thought you already had this filtering in place - your list collector filter is changed when the reference variable changes, and all of the records that meet that criteria are selected in the right pane.  Are you doing something differently to get this to work in CMS?