All Apps and Add-ons

sideview Redirector and TimeRangePicker

disha
Contributor
<module name="Redirector">
  <param name="url">my_custom_form_search_view</param>
  <param name="arg.user">$user.rawValue$</param>
  <param name="arg.earliest">$search.timeRange.earliest$</param>
  <param name="arg.latest">$search.timeRange.latest$</param>
</module>

When I pass the time range like this and on my next view I have again a TimeRangePicker Module. This range is passed for next page search but in TimeRangePicker Module default selection is "Custom Time". Can we show the same time range which is passed as default selected in TimeRangePicker.
For example: first Page It is "Last 4 hours" so on next view can TimeRangePicker show "Last 4 hours" instead of "Custom Time".
Please suggest.
Thanks,

1 Solution

sideview
SplunkTrust
SplunkTrust

This means that the first page has a chart or a table drilldown, and it's the drilldown interaction that leads to the search in the second page.

What happens is, that the chart and table modules all follow a convention where on drilldown, if it's a relative or realtime timerange, they swap out the timerange for the absolute-timerange equivalent at that exact moment. The reason for this is so that the numbers of the drilldown search can exactly match the aggregated numbers of the bar or column that you clicked on. If it didn't do this, and you waited a minute or two between clicks, the actual data underneath might change.

If you want to override this behavior, one way is to use the ValueSetter module to preserve the TimeRangePicker's timerange into 2 different $foo$ keys, further upstream. Then in the Redirector instead of passing $search.timeRange.earliest$ and $search.timeRange.latest$, you can pass these keys that you stashed for yourself.

ie

<module name="ValueSetter">
  <param name="name">stashedEarliest</param>
  <param name="value">$search.timeRange.earliest$</param>

  <module name="ValueSetter">
  <param name="name">stashedLatest</param>
    <param name="value">$search.timeRange.latest$</param> 

If you stitch in the above config, downstream from the TimeRangePicker, but upstream from your chart/table drilldown, and if you use $stashedEarliest$ etc in your Redirector, you should now get the behavior you expect.

View solution in original post

disha
Contributor


true
Last 4 hours

stashedEarliest
$search.timeRange.earliest
stashedLatest
$search.timeRange.latest$

<![CDATA[My Search|chart span=1m first(mu) as "Memory Usage(MB)" over _time by VMSID]]>




line
connect

   <param name="charting.axisTitleX.text">Time</param>
    <param name="charting.axisTitleY.text">Memory Usage(MB)</param>
     <param name="charting.legend.placement">bottom</param>
           <module name="JobProgressIndicator"/>
              <module name="JSChart">
             <param name="height">400px</param>
             <param name="enableResize">false</param>
                <module name="Redirector">

      <param name="url">DetailedCustomerView</param>
        <param name="arg.earliest">$stashedEarliest$</param>
      <param name="arg.latest">$stashedLatest$</param>
       <param name="arg.VMSID">$click.name2$</param>
              </module>

On the next page I need TimeRangePicker to select "last 60 min" if I select the same on this page.
Thanks.

0 Karma

disha
Contributor

I have just noticed that if the first page has TimeRangePicker with Table module the next page is showing same time in TimeRangePicker. As "last 15 min is redirecting as earliest=-15m and latest=now ans next page TimeRangePicker is showing "last 15 min" as selected.
But if we drilldown from a chart at first page the time range is passing as string of numbers and then it is showing as Custom time on the next page. Probably because Table is from sideview:) 🙂 it is showing time correctly.:)

0 Karma

sideview
SplunkTrust
SplunkTrust

This means that the first page has a chart or a table drilldown, and it's the drilldown interaction that leads to the search in the second page.

What happens is, that the chart and table modules all follow a convention where on drilldown, if it's a relative or realtime timerange, they swap out the timerange for the absolute-timerange equivalent at that exact moment. The reason for this is so that the numbers of the drilldown search can exactly match the aggregated numbers of the bar or column that you clicked on. If it didn't do this, and you waited a minute or two between clicks, the actual data underneath might change.

If you want to override this behavior, one way is to use the ValueSetter module to preserve the TimeRangePicker's timerange into 2 different $foo$ keys, further upstream. Then in the Redirector instead of passing $search.timeRange.earliest$ and $search.timeRange.latest$, you can pass these keys that you stashed for yourself.

ie

<module name="ValueSetter">
  <param name="name">stashedEarliest</param>
  <param name="value">$search.timeRange.earliest$</param>

  <module name="ValueSetter">
  <param name="name">stashedLatest</param>
    <param name="value">$search.timeRange.latest$</param> 

If you stitch in the above config, downstream from the TimeRangePicker, but upstream from your chart/table drilldown, and if you use $stashedEarliest$ etc in your Redirector, you should now get the behavior you expect.

sideview
SplunkTrust
SplunkTrust

Oops. I had a typo on my ValueSetter XML. Note that I left off the trailing $ on one of the values. Fix that and you're good to go.

0 Karma

disha
Contributor

Hey Nick..Thanks now I understood the concept but now on the redirecting view's TimeRangePicker I am getting selected value as "Over Custome Relative time range". Prev it was "Custom Time" and in URL latest and earliest are blank. Please help.Please see below for my piece of code.

0 Karma
Get Updates on the Splunk Community!

Announcing Scheduled Export GA for Dashboard Studio

We're excited to announce the general availability of Scheduled Export for Dashboard Studio. Starting in ...

Extending Observability Content to Splunk Cloud

Watch Now!   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to leverage ...

More Control Over Your Monitoring Costs with Archived Metrics GA in US-AWS!

What if there was a way you could keep all the metrics data you need while saving on storage costs?This is now ...