Dashboards & Visualizations

Change & Condition within From Text Inputs

gvmorley
Contributor

Hi,

I'm trying to understand a bit better the behaviour of 'change' and 'condition' tags when specifically used within Text Input Forms.

I'm seeing some strange (to me at least) behaviour and want to understand if others had seen the same. Or if it's possibly a bug of some sort.

To demonstrate the problem, I've just put together a simple Form:

<form hideEdit="false">
    <label>Input Text Test</label>

    <fieldset autoRun="true" submitButton="false">

        <input type="text" token="tok_text_1" searchWhenChanged="true">
            <label>Enter any text</label>

            <change>
                <condition value="bug">
                    <set token="tok_text_1">CHANGED</set>
                </condition>
                <condition>
                    <set token="tok_text_2">$tok_text_1$</set>
                </condition>
            </change>

        </input>

    </fieldset>

    <row>

        <panel>

            <title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$</title>

        </panel>

    </row>

</form>

I've got a couple of expectations of what should happen here when I enter text into the Input:

  • If I enter anything other than 'bug', both tokens should be set to the text I've entered:

    • The $tok_text_1$ is set by the input
    • The $tok_text_2$ is set by second change condition
    • Therefore the panel title should show the value of both tokens, which should be the text entered in the input
  • If I enter 'bug' , then $tok_text_1$ should be changed to 'CHANGED'. $tok_text_2$ should remain either unset or with it's previous value

    • The $tok_text_1$ is altered by the first change condition
    • The $tok_text_2$ is undefined (if 'bug' is first work entered). Or is remains set to it's previous value if there had been previous inputs
    • Therefore the panel title should show 'CHANGED' for the first token and either an undefined placeholder for $tok_text_2$ or it's previous value

Now if I run though some scenarios of what actually happens...

Load the Form, which has the URL: http://127.0.0.1:8000/en-GB/app/search/input_change_test

  1. Type 'test' into the input box and press return:

This results in a title of: Token 1: test | Token 2: $tok_text_1$

  1. If I then type 'test2' into the input box and press return:

This results in a title of: Token 1: test2 | Token 2: test

So what's happening here?
- In step 1, it would appear that the second change condition isn't being applied to set $tok_text_2$
- In step 2, it would appear that the second change block IS being applied, but based on the PREVIOUS value of $tok_text_1$

Now let's take a new scenario. Again, reload the dashboard with the URL from above (I.e. Remove and lingering $form.xxx$ tokens from the string).

  1. Type 'bug' into the input box and press return:

This results in a title of: Token 1: bug | Token 2: $tok_text_1$

  1. Type 'bug2' into the input box and press return:

This results in a title of: Token 1: bug2 | Token 2: bug

So what's happening here:
- In step 1 , it would appear that the first change condition isn't being applied to alter $tok_text_1$ to 'CHANGED'
- In step 2, it would appear that the second change block IS being applied, but based on the PREVIOUS value of $tok_text_1$

Both are very similar. But here's another little twist...

If you load the URL as: http://127.0.0.1:8000/en-GB/app/search/input_change_test?form.tok_text_1=bug

This results in a title of: Token 1: CHANGED | Token 2: $tok_text_2$

Now to my question.

Can anyone help me understand what's happening here?
- I'm interested in knowing if this is expected behaviour?
- What's the 'flow' around how these change conditions get evaluated?

The closest explanation I can come up with is from the Token Usage in Dashboard section of the manuals.

This suggests that 'value' isn't a available token in 'text' inputs, therefore can't be used in change conditions. 'label' and 'value' are only available in:

  • check-box
  • drop-down lists
  • multiselect
  • radio button

If that's the case, then how can you reference the text that's been entered into the text input?

Thanks in advance,

Graham.

1 Solution

jeffland
SplunkTrust
SplunkTrust

There's something about the token set by its input and using it inside these change statements that doesn't exactly work as you expect. I can't point you to any documentation, this is from personal experience and testing and it may change in the future, but I've found that you can't use the token inside these statements because they're not yet set to anything when the js code handling the value change runs. However, you can use the (temporary) token $value$ inside these change statements, as they contain the value the user just selected (there's also a $label$ token available if applicable, e.g. on dropdowns, not in the case of your text input).
Now this is where things become tricky because the behavior is possibly undefined. I don't know if you're intended to set the token of your input in a change statement, and I've always avoided that by using my own tokens with set (using value as above yields the same result, but consistently). First, if I change your token use to $value$, I get this:

<form hideEdit="false">
     <label>Input Text Test</label>
     <fieldset autoRun="true" submitButton="false">
         <input type="text" token="tok_text_1" searchWhenChanged="true">
             <label>Enter any text</label>
             <change>
                 <condition value="bug">
                     <set token="tok_text_1">CHANGED</set>
                 </condition>
                 <condition>
                     <set token="tok_text_2">$value$</set>
                 </condition>
             </change>
         </input>
     </fieldset>
     <row>
         <panel>
             <title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$ </title>
         </panel>
     </row>
 </form>

This sets tok_text_2 entirely as expected (if you enter "bug", the value stays what it was before because the condition never reaches the default/last option). tok_text_1 on the other hand is what the input sets it to (so it says "bug" and not "CHANGED"), probably because that runs after the conditionally set tokens are evaluated. However, and this looks inconsistent to me, if you enter "bug" into the text input, click on "Edit" and change the source in a way not relevant to the tokens (e.g. add a space to the panel title) and save that, you end up with "CHANGED" as the value for tok_text_1.

In conclusion, I'd advise you to use independent tokens when setting them directly in a change statement, like so:

<form hideEdit="false">
     <label>Input Text Test</label>
     <fieldset autoRun="true" submitButton="false">
         <input type="text" token="unused" searchWhenChanged="true">
             <label>Enter any text</label>
             <change>
                 <condition value="bug">
                     <set token="tok_text_1">CHANGED</set>
                 </condition>
                 <condition>
                     <set token"tok_text_1">$value$</set>
                     <set token="tok_text_2">$value$</set>
                 </condition>
             </change>
         </input>
     </fieldset>
     <row>
         <panel>
             <title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$ </title>
         </panel>
     </row>
 </form>

This should give you the expected behavior.

PS: if you want to change the input as well, use form.tokenName. Try this out to see what I mean:

<form hideEdit="false">
     <label>Input Text Test</label>
     <fieldset autoRun="true" submitButton="false">
         <input type="text" token="tok_text_1" searchWhenChanged="true">
             <label>Enter any text</label>
             <change>
                 <condition value="bug">
                     <set token="form.tok_text_1">CHANGED</set>
                 </condition>
                 <condition>
                     <set token="tok_text_2">$value$</set>
                 </condition>
             </change>
         </input>
     </fieldset>
     <row>
         <panel>
             <title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$ </title>
         </panel>
     </row>
 </form>

Feel free to ask any remaining questions!

View solution in original post

abulco01
Explorer

gvmorley, thank you for taking the time to explain this frustrating situation, as I was just about to create a post and call "bug" on this bizarre token behavior myself. This thread helped me a lot!

0 Karma

jeffland
SplunkTrust
SplunkTrust

There's something about the token set by its input and using it inside these change statements that doesn't exactly work as you expect. I can't point you to any documentation, this is from personal experience and testing and it may change in the future, but I've found that you can't use the token inside these statements because they're not yet set to anything when the js code handling the value change runs. However, you can use the (temporary) token $value$ inside these change statements, as they contain the value the user just selected (there's also a $label$ token available if applicable, e.g. on dropdowns, not in the case of your text input).
Now this is where things become tricky because the behavior is possibly undefined. I don't know if you're intended to set the token of your input in a change statement, and I've always avoided that by using my own tokens with set (using value as above yields the same result, but consistently). First, if I change your token use to $value$, I get this:

<form hideEdit="false">
     <label>Input Text Test</label>
     <fieldset autoRun="true" submitButton="false">
         <input type="text" token="tok_text_1" searchWhenChanged="true">
             <label>Enter any text</label>
             <change>
                 <condition value="bug">
                     <set token="tok_text_1">CHANGED</set>
                 </condition>
                 <condition>
                     <set token="tok_text_2">$value$</set>
                 </condition>
             </change>
         </input>
     </fieldset>
     <row>
         <panel>
             <title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$ </title>
         </panel>
     </row>
 </form>

This sets tok_text_2 entirely as expected (if you enter "bug", the value stays what it was before because the condition never reaches the default/last option). tok_text_1 on the other hand is what the input sets it to (so it says "bug" and not "CHANGED"), probably because that runs after the conditionally set tokens are evaluated. However, and this looks inconsistent to me, if you enter "bug" into the text input, click on "Edit" and change the source in a way not relevant to the tokens (e.g. add a space to the panel title) and save that, you end up with "CHANGED" as the value for tok_text_1.

In conclusion, I'd advise you to use independent tokens when setting them directly in a change statement, like so:

<form hideEdit="false">
     <label>Input Text Test</label>
     <fieldset autoRun="true" submitButton="false">
         <input type="text" token="unused" searchWhenChanged="true">
             <label>Enter any text</label>
             <change>
                 <condition value="bug">
                     <set token="tok_text_1">CHANGED</set>
                 </condition>
                 <condition>
                     <set token"tok_text_1">$value$</set>
                     <set token="tok_text_2">$value$</set>
                 </condition>
             </change>
         </input>
     </fieldset>
     <row>
         <panel>
             <title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$ </title>
         </panel>
     </row>
 </form>

This should give you the expected behavior.

PS: if you want to change the input as well, use form.tokenName. Try this out to see what I mean:

<form hideEdit="false">
     <label>Input Text Test</label>
     <fieldset autoRun="true" submitButton="false">
         <input type="text" token="tok_text_1" searchWhenChanged="true">
             <label>Enter any text</label>
             <change>
                 <condition value="bug">
                     <set token="form.tok_text_1">CHANGED</set>
                 </condition>
                 <condition>
                     <set token="tok_text_2">$value$</set>
                 </condition>
             </change>
         </input>
     </fieldset>
     <row>
         <panel>
             <title>Token 1: $tok_text_1$ | Token 2: $tok_text_2$ </title>
         </panel>
     </row>
 </form>

Feel free to ask any remaining questions!

actionabledata
Path Finder

This was incredibly useful. Thank you!

0 Karma

abulco01
Explorer

Jeffland, you area awesome! Thank you so much for your explanation! I was having the exact same issue where my fields were showing the previous token value (as opposed to the current), and your trick using $value$ worked perfectly! I too was unable to find any documentation addressing this behavior.

0 Karma

niketn
Legend

@abulco01, predefined input tokens $value$ and $label$ have definitely been covered in Splunk Documentation: http://docs.splunk.com/Documentation/Splunk/latest/Viz/tokens#Predefined_tokens_for_accessing_labels...

Also Splunk Dashboard Examples also covers Input Label and Value example.

There are several examples on Splunk Answers around using value or $value$ to access Text Box Value depending on where they are being accessed within the text box <change> event handler.

____________________________________________
| makeresults | eval message= "Happy Splunking!!!"

Nam7Splnk
Explorer

does this also work with multiselect ?

0 Karma

jeffland
SplunkTrust
SplunkTrust

No, multiselects do not have a change event handler. Docs here.

0 Karma

niketn
Legend

@Nam7Splnk @jeffland, there is a limitation with checkbox and multiselect input <change> event handler, however, we can use our own JavaScript to handle and retrieve multiple values selected. Refer to one of my recent answers for the same: https://answers.splunk.com/answers/504338/using-eventhandler-with-multiselectinput.html

____________________________________________
| makeresults | eval message= "Happy Splunking!!!"
0 Karma

Nam7Splnk
Explorer

thanks @niketnilay, @jeffland. your responses are very helpful.

tmcmaster
Explorer

The form.token was the part I was missing. Without it I wasn't getting the token overridden when I was trying to modify a second text token. Thanks.

0 Karma

rachala
New Member

Hi Jeffland,

My Scenario:-

If host=AB* then need to get the data from macro $Host$_Base_Search,( host=C* OR host != AB*) then need to get the data from different macro $Host$_Base_Search.

US

AD

if host=AB* then macro US_Base_Search
host=C* then macro AD_Base_Search

Please help me.

Thanks in advance..

0 Karma

jeffland
SplunkTrust
SplunkTrust

I don't see how this is related to the question discussed above. I would suggest you ask a new question.

0 Karma

rachala
New Member

Sorry for the confusion. i'll post a new question.

0 Karma

gvmorley
Contributor

Hi,

Many thanks for the detailed reply.

It's reassuring the see that you also saw the same inconsistency when trying the re-set the same token in the change block that was used for the input.

Maybe it's by design? If any of the Splunk folks are reading, if it is, perhaps a little update in the change & condition docs to just highlight this?

Your approach makes a lot of sense. Essentially, just have a 'disposable' or 'temporary' token for the the input (in your example token="unused"). Then just set new tokens based on the value contained within it.

I like it - a really good approach.

Thanks for taking the time to put together your response.

Graham.

0 Karma

jeffland
SplunkTrust
SplunkTrust

Glad I could help 🙂
I've had good experience giving feedback directly on the relevant documentataion sites, at the botton where it says "Was this topic useful". The folks receiving that feedback are really helpful and competent and take care to look into the issues brought up to them, escalating to the appropriate people if needed or just downright correcting/enhancing the docs.

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...