Both me (Splunk developer) and two of my (non-technical) end users are very confused.
My end users are complaining that they can't resubmit searches with a time period of "... to date" when they don't update the other non-time parameters. In my mind $TIMERANGE.latest$ should be dynamically updating every second, and thus enabling a re-search on button click since the token value changed, but I understand it doesn't work this way. Even with a javascript button I can't figure out a way to refresh the panel on submit (or page... preferably panel) and then have the search re-run.
My end users are confused because they just want to use a button the way every other application on earth uses a button. I, the Splunk developer, am probably even more confused because I cannot understand how every other Splunk user in existence has not had this problem. Are you all just content with nixing the button and repeatedly changing the timepicker from "today" to "some_junk_time_period" and back to "today" just to resubmit a search...? Or do you tell your bosses that they must learn to use both a submit and refresh button in conjunction with each other, to use any of your dashboards, in which case how are you not laughed out of their office?
.
.
.
ORIGINAL POST BELOW
.
.
.
Formerly titled "How can I get the timepicker to dynamically recognize latest=now?"
Hi guys,
My users are complaining that when they have a time range with a latest of "now" that the dashboard isn't searching when they hit the submit button again (without changing any parameters). Shouldn't $TIMERANGE.latest$ be updating every second, and thus enabling a re-search, if latest is set to now? How do I fix this?
While my timepicker configuration is a bit complex...
<fieldset submitButton="true" autoRun="false">
<input type="time" token="TIMERANGE" searchWhenChanged="false" id="timepicker">
<label>Time range:</label>
<default>
<earliest>@d</earliest>
<latest>now</latest>
</default>
<change>
<eval token="earliest_epoch_onChange">case(isnum($earliest$), $earliest$, $earliest$=="now", time(), $earliest$="", 0, true(), relative_time(time(), $earliest$))</eval>
<eval token="latest_epoch_onChange">case(isnum($latest$), $latest$, $latest$=="now", time(), true(), relative_time(time(), $latest$))</eval>
</change>
</input>
<input type="text" token="earliest_epoch" depends="$justHideMe$">
<default>$earliest_epoch_onChange$</default>
</input>
<input type="text" token="latest_epoch" depends="$justHideMe$">
<default>$latest_epoch_onChange$</default>
</input>
... it doesn't matter, the problem still exists with a very basic timepicker configuration (run anywhere dash below).
<dashboard>
<label>wtf</label>
<description></description>
<fieldset submitButton="true">
<input type="time" token="TIMERANGE" id="timepicker">
<label>Time range:</label>
<default>
<earliest>@d</earliest>
<latest>now</latest>
</default>
</input>
</fieldset>
<row>
<panel>
<title></title>
<table>
<search>
<query>
| makeresults | eval simplexmlistheworst="v_true" | table *
</query>
<earliest>$TIMERANGE.earliest$</earliest>
<latest>$TIMERANGE.latest$</latest>
</search>
<option name="wrap">true</option>
<option name="rowNumbers">false</option>
<option name="drilldown">none</option>
<option name="dataOverlayMode">none</option>
<option name="count">20</option>
</table>
</panel>
</row>
</dashboard>
This is applicable to other time choices that depend on now, e.g. week-to-date or today.
Solution: switch to js button, set a junk trigger token in your .js file and concat Math.random(), and reference the junk trigger somewhere in your dashboard query. Because Splunk does not want to create an even half-working submit button.
require([
'jquery',
'splunkjs/mvc',
'splunkjs/mvc/simplexml/ready!'
], function($,mvc){
var defaultTokens = mvc.Components.get("default");
var submittedTokens = mvc.Components.get("submitted");
$('#jsButton').on("click",function(){
submittedTokens.set("junkTrigger", "submitbuttonistheworst"+Math.random());
defaultTokens.set("junkTrigger", "submitbuttonistheworst"+Math.random());
});
});
Solution: switch to js button, set a junk trigger token in your .js file and concat Math.random(), and reference the junk trigger somewhere in your dashboard query. Because Splunk does not want to create an even half-working submit button.
require([
'jquery',
'splunkjs/mvc',
'splunkjs/mvc/simplexml/ready!'
], function($,mvc){
var defaultTokens = mvc.Components.get("default");
var submittedTokens = mvc.Components.get("submitted");
$('#jsButton').on("click",function(){
submittedTokens.set("junkTrigger", "submitbuttonistheworst"+Math.random());
defaultTokens.set("junkTrigger", "submitbuttonistheworst"+Math.random());
});
});
@mpwelch Here is your answer to that thing we were discussing @ DASUG last week!!!
I TOTALLY agree that this is a bug and you DEFINITELY should open a support case on it but the result is likely to be "working as designed" and closed without fixing it. The best that you can do is to use auto refresh
(just don't do realtime
); check out refresh
on this link:
https://docs.splunk.com/Documentation/Splunk/latest/Viz/PanelreferenceforSimplifiedXML#Shared_option...
but auto refresh doesn't really help; after all users want their results to stay until THEY perform an action
Try removing id="timepicker"
on <input type="time" token="TIMERANGE" id="timepicker">
... because i dont have that in any of my dashboards and i use "now" as well.
That doesn't fix the problem, and I generally need to have an id for the timepicker. Are you able to resubmit with "now" without changing non-timepicker toks?
Yes, i can refresh my dashboard, or click on submit and get new results.
Describe what you mean by resubmit? The entire work flow you are anticipating with "resubmit".
Resubmitting whatever the button is meant to submit.
Can you submit an example of a dashboard that you have that lets you get new results upon submit, without having changed non-time toks?