Why are conditional tokens one change behind for time picker changes?

[feickertmd]

I am working with setting new tokens whenever my time picker is changed so that I can offer an appropriate set of timespans for a timeline. The code seems sound, but it has a weird nuance: the displayed tokens are for the previous choice made, not the current one.

Example:
Condition A is set so that less than 12 hours sets $tokenA$ while condition B says that between 12 hours and seven days sets $tokenB$.
If I choose condition A -> condition B ->condition A, then my current choice is condition A, but my current token is one behind ($tokenB$)

Closing and refreshing the browser does no good. it's like a token choice is stuck in memory somewhere.

Here is my code:

    <panel>
      <input type="time" token="api_time" searchWhenChanged="true">
        <label>($api_time.latest$) - ($api_time.earliest$)</label>
        <default>
          <earliest>-7d@d</earliest>
          <latest>@d</latest>
        </default>
        <change>
          <!-- if time is less than 12 hours, show Hour, 15 Min, Min  -->
          <condition match="(relative_time(now(), $api_time.latest$) - relative_time(now(), $api_time.earliest$)) &lt; 43201">
            <set token="hour_top">12hour</set>
            <unset token="7day_top"></unset>
            <unset token="1month_top"></unset>
            <unset token="gt_month"></unset>
            <unset token="span"></unset>
          </condition>
          <!-- if time is between 12 hours and 7 days, show Day, Hour, 15 Min  -->
          <condition match="43200 &lt; (relative_time(now(), $api_time.latest$) - relative_time(now(), $api_time.earliest$)) &lt; 604801">
            <set token="7day_top">7day</set>
            <unset token="hour_top"></unset>
            <unset token="1month_top"></unset>
            <unset token="gt_month"></unset>
            <unset token="span"></unset>
          </condition>
...
</panel></row>

[woodcock]

I would open a support ticket for this.

[woodcock]

I had to bypass the whole mess by proxying the timepicker values through addinfo and a base search like this:

<search id="timepickerHistoryBase">
  <query>|makeresults
| addinfo
| eval span = if(isnum(info_max_time), info_max_time, now()) - info_min_time</query>
  <earliest>$api_time.earliest$</earliest>
  <latest>$api_time.latest$</latest>
  <done>
    <!-- if time is less than 12 hours, show Hour, 15 Min, Min --> 
    <condition match="$result.span$lt;43201">
      <set token="hour_top">12hour</set> 
      <unset token="7day_top"></unset> 
      <unset token="1month_top"></unset> 
      <unset token="gt_month"></unset> 
      <unset token="span"></unset> 
    </condition> 
    <condition>
      <set token="7day_top">7day</set> 
      <unset token="hour_top"></unset> 
      <unset token="1month_top"></unset> 
      <unset token="gt_month"></unset> 
      <unset token="span"></unset> 
    </condition>
  </done>
</search>

[somesoni2]

I would give this a try (changing the location of your <condition> to a separate <search> element.

<panel> 
<input type="time" token="api_time" searchWhenChanged="true"> 
<label>($api_time.latest$) - ($api_time.earliest$)</label> 
<default> 
<earliest>-7d@d</earliest> 
<latest>@d</latest> 
</default>
</input>
<search id="search_logic">
      <query>| gentimes start=-1 | addinfo | table info_min_time info_max_time | where info_max_time-info_min_time < 43201 </query>
      <earliest>$api_time.earliest$</earliest>
      <latest>$api_time.latest$</latest>
      <progress>
           <!-- if time is less than 12 hours, show Hour, 15 Min, Min --> 
 <condition match="'job.resultCount' == 0">
<set token="hour_top">12hour</set> 
<unset token="7day_top"></unset> 
<unset token="1month_top"></unset> 
<unset token="gt_month"></unset> 
<unset token="span"></unset> 
</condition> 
<condition>
<set token="7day_top">7day</set> 
<unset token="hour_top"></unset> 
<unset token="1month_top"></unset> 
<unset token="gt_month"></unset> 
<unset token="span"></unset> 
</condition>
       </progress>
   </search>
......
</panel>
</row>

[feickertmd]

Nope, that doesn't do it

[woodcock]

I see now that my answer is essentially the same as this one and it most definitely works. Try them both again.