Is it possible to pre-[de]select options in a CheckboxPulldown (sideview)

[glitchcowboy]

I've got a dynamically filled CheckboxPulldown and I'd like some of the items to be deselected (if they appear).

Is it possible?

[sideview]

There is, but it's a bit hokey and it has at least one drawback that might not work for you.

What Sideview Utils should provide as a better alternative, is a new param called "selectionField", that would be a cousin of "valueField" and the optional "labelField" params. This would be a param on Pulldown/Checkboxes/Tabs/CheckboxPulldown etc...

However, until that day comes, your only recourse is a weird trick with some advanced modules. (Sometimes I wish ResultsValueSetter and ValueSetter weren't quite so useful for bizarre things, because they end up providing a lot of weird-looking workarounds just like this)

Say you have this Search+CheckboxPulldown pair, giving you a dynamic checkbox pulldown control:

<module name="Search" layoutPanel="panel_row2_col1" autoRun="True">
  <param name="search">index=_internal source="*metrics.log" group="per_sourcetype_thruput" | dedup series | sort series | fields series</param>
  <param name="earliest">-1h</param>
  <param name="latest">now</param>

  <module name="CheckboxPulldown">
    <param name="name">selectedSourcetypes</param>
    <param name="label">Sourcetype</param>
    <param name="template">series="$value$"</param>
    <param name="valueField">series</param>

Normally selecting or deselecting dynamically rendered stuff in a Pulldown/CheckboxPulldown/Tabs/Checkboxes/Radio module is done by using a ValueSetter module. The idea is that something upstream from the module, with a "name" param that matches the form element module's name param, gives it an explicit value and when a Sideview form module sees it's own $foo$ token coming from upstream, it tries to "select" that value inside itself as appropriate.

So our weird workaround is to use the search language to actually make the set of checkbox values, then filter out the ones we dont want selected, then use ResultsValueSetter to pull that down as a $foo$ token, then we give it to the CheckboxPulldown. Weird huh?

<module name="Search" layoutPanel="panel_row2_col1" autoRun="True">
  <param name="search">index=_internal source="*metrics.log" group="per_sourcetype_thruput" | dedup series | sort series | fields series</param>
  <param name="earliest">-1h</param>
  <param name="latest">now</param>

  <module name="PostProcess">
    <param name="search">search series!="splunkd" | stats values(series) as series | eval series=mvjoin(series,",")</param>

    <module name="ResultsValueSetter">
      <param name="fields">series</param>

      <module name="ValueSetter">
        <param name="name">selectedSourcetypes</param>
        <param name="value">$series$</param>
        <param name="delim">,</param>

        <module name="CheckboxPulldown">
          <param name="name">selectedSourcetypes</param>
          <param name="label">Sourcetype</param>
          <param name="template">series="$value$"</param>
          <param name="valueField">series</param>
          <param name="postProcess">search *</param>

Note the postprocess param on the CheckboxPulldown at the end - that is required because our workaround has introduced a postprocess search that will then cascade down and affect things.... In a more complex view you may want to replace that postProcess param with an explicit PostProcess module just upstream from the CheckboxPulldown.

the main drawback here is that if there are other form elements upstream from all this, whenever something up there is changed, the selections on the CheckboxPulldown will be reset. I'll also make a note to come back to this answer and add a comment when I add the "selectionField" param.