This is a request to make token behaviors consistent for form inputs (applies to version 6.2 through 6.6.1 as of posting). Here is a link to the docs page about the types of tokens I am referring to: http://docs.splunk.com/Documentation/Splunk/latest/Viz/tokens#Define_tokens_for_conditional_operatio...
Basically, the request is to make the "searchWhenChanged" setting on the input element apply to the tokens that can be set under the
The problem is if you have an input that sets
searchWhenChanged="false" so that the input token is only applied when tokens are submitted, any tokens you set using
unset inside the
condition elements of the input are immediately applied in the dashboard. This happens because those "child" tokens of the input are immediately applied to both default and submitted token models regardless of the "searchWhenChanged" setting.
A simple scenario where this is a problem is any time you use a dropdown or radio button to set a field used in the "by" clause of a chart. If you have any custom operations or axes label changes that are field dependent and set under
condition of the dropdown, the chart is going to be immediately updated whenever the value changes even if the top-level token value is supposed to require a submit event.
Here is XML to demonstrate the use case
<input id="target_field" searchWhenChanged="false" token="target_field" type="radio"> <label>Split-by Field</label> <choice value="process">Executables</choice> <choice value="url_domain">URL Domains</choice> <default>process</default> <change> <condition value="url_domain"> <set token="target_field_filter">valid_url=1</set> <set token="target_field_axes_label">$label$</set> </condition> <condition value="*"> <set token="target_field_filter"> </set> <set token="target_field_axes_label">$label$</set> </condition> </change> </input>
In this use case, any chart or search that is based on the tokens
target_field_axes_label will be automatically rerun or updated when the radio button changes even though the
searchWhenChanged="false"setting would indicate the top-level token requires a submit event.
Also add the
tag and put the version of Splunk that you are using. Maybe somebody somewhere down the line will mine Answers and work on this.
Changed it back to ER. Went through and mined the mrsparkle / SplunkJS code, and you can find where the code applies the same logic to all eval, set, and unset operations without having any steps to evaluate what token model to apply it to.
Agreed, bug, not ER. However 95% of bug reports I've submitted to Splunk they classify as "Enhancement Requests" and then don't fix them; I debating submitting a bug report on this one for a while before concluding that Splunk is just going to ignore it because they don't want to do the work.
So I experimented with this a bit. (Thanks @rjthibod for the sample dashboard!) Below is what I came up with.... but it is a bit messy. Probably more annoying than actually just dealing with the "glitch".
So Basically, you set a
<done> on the search that has the token in question. Make that an base search (use
id). Then, create a hidden dropdown, with a populating search that is a POST Process search based on the main search, and do a little magic with
makeresults to get rid of the actual results. This will dynamically eval fields based on the output of the main search, and the selected label, and if they match when the search is
done, then change an updated token that you use to render the label. Totally not clean, but totally works.
<form> <label>Token Test</label> <fieldset submitButton="true"> <input type="time" searchWhenChanged="true"> <label>Search Period</label> <default> <earliest>-7d@h</earliest> <latest>now</latest> </default> </input> <input type="dropdown" token="index" searchWhenChanged="false"> <label>Index</label> <choice value="* OR index=_*">All Indexes</choice> <choice value="_*">Internal Indexes</choice> <choice value="*">Non-internal Indexes</choice> <change> <set token="index_label">$label$</set> <set token="index_value">$value$</set> </change> </input> <input type="dropdown" depends="$no_token$"> <search base="token_dependent"><query>append[makeresults | eval index = "$index_updated$", index_value = "$index_value$", gobblygook = "yep"]| stats count by index index_value gobblygook</query> <done> <condition match=" 'result.index' == 'result.index_value' "> <set token="index_label_updated">$index_label$</set> </condition> </done></search> </input> </fieldset> <row> <panel> <chart> <title>Index Event Count</title> <search id="token_dependent"> <query>| tstats count where index=$index$ by index | sort 10 -count</query> <done><set token="index_updated">$index$</set></done> </search> <option name="charting.axisX.scale">linear</option> <option name="charting.axisY.scale">linear</option> <option name="charting.chart">bar</option> <option name="charting.drilldown">none</option> <option name="charting.legend.placement">right</option> <option name="charting.axisTitleX.text">$index_label_updated$</option> </chart> </panel> </row> </form>
I did not get a chance to explore this solution. @niketnilay mentioned that it is for a slightly different use case than the one in the below post, however if anyone is struggling with this, the solution in the below post may be what you need.
I agree with the idea. In my opinion, this should be a setting on the
eval tags though, because it is not a setting of the input itself. Something like
<change> <set token="target_field_filter" applyOnSubmit="true">valid_url=1</set> </change>
That would allow for more flexibility.
I concur with this kind of approach as well. Keeps current dashboard logic consistent.