Is it impossible to resubmit a dashboard search in Splunk?

[nick405060]

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.