Why do set/unset change conditions for a checkbox input not work on Splunk 6.4.x?

[andrewtrobec]

Hello,

I'm trying to figure out why a piece of code that works on Splunk 6.6.x does not work on Splunk 6.4.x. Here is the standalone form:

<form>
  <label>Checkbox Token Test</label>
  <row>
    <panel>
      <title>$checkbox$ - $setToken$</title>
      <input type="checkbox" token="checkbox" searchWhenChanged="true">
        <label></label>
        <choice value="Enable">Enable</choice>
        <change>
          <condition value="Enable">
            <set token="setToken">1</set>
          </condition>
          <condition>
            <unset token="setToken"></unset>
          </condition>
        </change>
      </input>
    </panel>
  </row>
</form>

All it does is set a token when the checkbox has been selected and unset the token when it has been deselected. Simple use case to study change conditions.

What do I need to change to get it working with Splunk 6.4.x?

Thank you!

Andrew

[niketn · Accepted solution]

@andrewtrobec, the <change> Event Handler for checkbox and multivalue inputs do not play well on dashboard when multiple values are present, which is a known issue and is not resolved yet as far as I know. Refer to one of the questions on the same: https://answers.splunk.com/answers/506563/how-can-i-show-and-hide-panels-based-on-a-checkbox.html

In your case however, there is only one value for checkbox, which implies you can use the input token (in your case $checkbox$ itself as toggle. Please try below and confirm.

   <input type="checkbox" token="checkbox" searchWhenChanged="true">
     <label></label>
     <choice value="Enable">Enable</choice>
     <change>
       <condition match="$checkbox$==&quot;Enable&quot;">
         <set token="setToken">1</set>
       </condition>
       <condition>
         <unset token="setToken"></unset>
       </condition>
     </change>
   </input>

What do you want to do when check box is checked or unchecked? Do you want to show/hide any visualization?

For handling multiple values from check box you would need to use JavaScript for which you can refer to other Answers here like https://answers.splunk.com/answers/314505/how-to-pass-selected-checkbox-values-to-drilldown.html

[andrewtrobec]

Thanks for the reply!

I've tested this code and for some reason it works, but inversely: when I check the checkbox, nothing happens, but when I uncheck it, then it sets the token... based on the code i don't think this should be happening

I'm using this checkbox as a mechanism for running a search. The search will only run when the the checkbox is selected, which will be embedded with this pipe:

| where isnum($setToken$)

Also, that same checkbox will hide/show a panel using the depends property on the panel.

[niketn]

@andrewtrobec, Yes it might work in reverse order (since I tested on version 7.0). It is because the token value gets available after the click submits. So you can do either of the two things.

1) Replace depends with rejects so that token behavior is reversed (or vice versa if required)
2) If you have several places where depends token is used, then you can switch the code inside the condition blocks.

Please accept the answer and up vote comments if it works out.

[andrewtrobec]

The depends in my case is based on the checkbox token being enabled, regardless of the value so I don't think points 1 and 2 are applicable.

My goal is to make sure that setToken gets set when the checkbox is check, which it's currently doing inversely. That will then be used to activate a search. Is there a way to set a depends within the condition block?

[niketn]

@andrewtrobec, Can you add the remaining code where you have used depends and also the token?

[andrewtrobec]

@niketnilay here's a simple representation of what I'm trying to do:

<form>
  <row>
    <panel>
      <title>Checkbox: $checkbox$ - setToken: $setToken$ </title>
      <input type="checkbox" token="checkbox" searchWhenChanged="true">
        <label></label>
        <choice value="Enabled">Enabled</choice>
        <change>
          <condition match="$checkbox$==&quot;Enabled&quot;">
            <set token="setToken">1</set>
          </condition>
          <condition>
            <unset token="setToken"></unset>
          </condition>
        </change>
      </input>
    </panel>
  </row>
  <row>
    <panel depends="$checkbox$">
      <title>Hidden Row</title>
      <table>
        <search>
          <query>| makeresults | where isnum($setToken$) | table _time</query>
        </search>
      </table>
    </panel>
  </row>
</form>

When you select the checkbox, the hidden row appears. Selecting the checkbox should also set the token so that the search will run, but it doesn't since the token is only set when the checkbox is unchecked.

Hope this sheds some light, and I appreciate you taking the time.

[niketn]

@andrewtrobec, this behavior is working as expected in Splunk Enterprise 7 and as you have noticed in 6.6 as well. So, I wanted you to use the token behavior in Splunk 6.4 which is reverse of how it should ideally behave. You can also code checkbox enabled as disabled scenario and vice-versa.

So try the following code first:

 <form>
   <row>
     <panel>
       <title>Checkbox: $checkbox$ - setToken: $setToken$ </title>
       <input type="checkbox" token="checkbox" searchWhenChanged="true">
         <label></label>
         <choice value="Enabled">Enabled</choice>
         <change>
           <condition match="$checkbox$==&quot;Enabled&quot;">
             <set token="setToken">1</set>
           </condition>
           <condition>
             <unset token="setToken"></unset>
           </condition>
         </change>
       </input>
     </panel>
   </row>
   <row>
     <panel depends="$setToken$">
       <title>Hidden Row</title>
       <table>
         <search>
           <query>| makeresults | where isnum($setToken$) | table _time</query>
         </search>
       </table>
     </panel>
   </row>
 </form>

If it does not work then just reverse the condition with tokens set and unset

 <form>
   <row>
     <panel>
       <title>Checkbox: $checkbox$ - setToken: $setToken$ </title>
       <input type="checkbox" token="checkbox" searchWhenChanged="true">
         <label></label>
         <choice value="Enabled">Enabled</choice>
         <change>
           <condition match="$checkbox$==&quot;Enabled&quot;">
             <unset token="setToken"></unset>
           </condition>
           <condition>
             <set token="setToken">1</set>
           </condition>
         </change>
       </input>
     </panel>
   </row>
   <row>
     <panel depends="$setToken$">
       <title>Hidden Row</title>
       <table>
         <search>
           <query>| makeresults | where isnum($setToken$) | table _time</query>
         </search>
       </table>
     </panel>
   </row>
 </form>

Unfortunately I can't test on 6.4. But idea is to use the glitch to our favor. You can also try renaming the Enabled choice to Disabled if complete behavior is just reverse.

[andrewtrobec]

@niketnilay the second piece of code gives the required results! The only change I've made is to make the panel depend on $checkbox$ and not $setToken$. If I use the latter then the panel is displayed by default. By using the former it hides the panel until the value is selected. Thank you so much!

Is there a way to formulate a responsem or should I accept as the answer this last comment?

Regards,

Andrew

[niketn]

@andrewtrobec, you can accept this thread as an answer. Since we tried couple of iterations, you can up vote the comments that helped.

I was only able to realize that you are using two separate tokens for query and depends after seeing your complete dashboard code. 🙂

So, here are couple of more tips:

1) Most of the time the token being used in the search query can be used directly as depends so that the results display only when the required token for the search is set.
2) On the other way around when you have just a token for depends, ideally you should see whether the same token can be placed inside the search as well. This way when panel is hidden underlying search should not run in the background.

Well obviously both of the scenarios may not always be applicable, but you should verify the same first.