For years I think every client I’ve ever worked with has asked for a way to easily select multiple records with a filter in a portal catalog item the same way you can in the platform with a list collector field. In the platform you get a slushbucket interface but in the portal the interface is very different. Only 1 item can be selected at a time and there is no real filter options. So, I set out to create a widget that will work in the portal and SOW that works as an interface for a List collector field that is reusable and can be easily added to an existing catalog item. In this example the reference qualifier is keying off the Assigned to variable and showing computers where the assigned to on the computer record matches the assigned to reference variable.
This is all configurable via the Default value of the widget variable which is a JSON object containing all of the options for configuring the widget so this can be used on multiple catalog items without the need to modify the actual widget.
To use this widget the attached update set contains 2 records. The widget and a widget dependency to the out of box SN Filter widget dependency.
You will need a catalog item that has a list collector variable already on it. Then add another variable of type Custom or Custom with label and set the “Widget to Portal and SOW Slush Bucket”. At this point you can bring up the catalog item in the portal and since the mandatory data in the default value is not populated there will be a popup containing an example JSON that you can copy in to the default value of variable.
For the example above this is what the JSON looks like
{
"widget":"portalandsowslushbucket", //MANDATORY: The name of this widget
"tablename":"cmdb_ci_computer", //MANDATORY: table to reference
"listcollectorfield":"computers", //MANDATORY: name of standard list collector variable
"reference_qual":"javascript:'assigned_to=' + current.variables.assigned_user.sys_id",//Reference Qualifier to always apply
"ref_qual_elements":"assigned_user",//fields that trigger an update to the reference qualifier
"clear_selection_on_ref_change":true, // when fields in ref_qual_elements change clear selected values
//"initialquery":"nameLIKEm", //default query to display in condition builder
"hidelistcollector":false, //when true hides the list collector field(For debugging/validation)
"fieldlist":"name,serial_number,assigned_to.location,assigned_to.department,os,os_service_pack,assigned_to.email,model_id", //fields to show under slushbucket defaults to reference list
"recordlimit":5000, //max number of records to return from query. defaults to 1000
"displayfields":"name,model_id", //display value fields. defaults to table display value
"displayfieldseparator":"➖", //separates displayfields defaults to space
"load_filter":true, //Show Load Filter button
"save_filter":true, //Show Save Filter button
"test_filter":false, //Show Preview button - If a ref qual is used the preview button will not show accurate results
"related_list_query":false, //Show Related list query options
"no_filter":false, //Hide Filter if true
"show_tooltip":true, //when true shows a tooltip when an item is hovered over. Can be usefull for records with long names
"debug":false
}
Leave widget as “portalandsowslushbucket” unless you copy the widget or rename it. This should always be the name of the widget
tablename should be the name of the table to get data from
listcollectorfield is the name of the current list collector on your catalog item that you want this widget to interact with.
The debug option will just show an info message with the query that was sent to the server. This is because this may need to be slightly different then what you have on your current list collector field. For example in the example above the list collector has a reference qualifier of javascript: "assigned_to=" + current.variables.assigned_user and the reference qualifier in the JSON is javascript:'assigned_to=' + current.variables.assigned_user.sys_id. The .sys_id is required since the widget is building the current object and it does not translate the same.
A lot of the options have defaults if the option is not provided. For example the fieldlist option that shows at the bottom of the widget will default to the sys_popup view(Same as the slushbucket uses), The recordlimit will default to 1000, The displayfields which is what shows in the select boxes will default to the display field of the selected table, and the displayfieldseparator defaults to space(In the example above you can see Unicode emojis can be pasted in to this option for a distinct visual separator).
I think the description in the comment after all the other fields is sufficient for their functionality.
