[Sideview Utils] Can I disconnect a TimeRangePicker from upstream modules?

[Lowell]

Is it possible to have a TimeRangePicker ignored previously set timeranges from other TimeRangePickers or Search modules?

Here are a couple of use cases:

1. Search over a short time frame to populate a Pulldown. Then allow a TimeRangePicker to search over a user-given timerange based on the value from the pulldown. (Allow the TimeRangePicker to use the default value, not be determined by the timeframe of the drop-down's populating search.)
2. In a drill down situation where on top-level search (governed by a top-level TimeRangePicker). A search nested under the drill-down should be able to pick it's own time without effect the time of the parent search.

[sideview]

Yes it is. In fact in the 2.1 release I cleaned up the TRP behavior a bit specifically to support prepopulate/dont-prepopulate use cases like this.

Background:

TimeRangePicker gets its behavior patched a little bit by Sideview Utils so as to make the prepopulation behavior consistent with the Sideview systems. In particular if a timerange comes down from upstream, the TRP will select itself to that timerange. However there's always been a weird wrinkle in the behavior around "all time". Since the Splunk UI treats the absence of a timerange as an "all time" timerange, the TimeRangePicker will NOT select itself to an all-time timerange coming down from above. This is simply because it can't or else it would be resetting itself to "all time", er, all the time.

The Fix:

Right above the TimeRangePicker that you don't want to prepopulate, stitch in this Search module.

<module name="Search">
  <param name="earliest"> </param>
  <param name="latest"> </param>

It's bizarre, but this will effectively bleach away the timerange. Thus the TimeRangePicker downstream will neither set itself to a) the upstream timerange because it was bleached away, nor to b) the implicit "all time" timerange, because of the wrinkle described above.

BONUS:

In Sideview Utils 2.1 I built a way out of this strange "lack of timerange" == "all time" wrinkle.

As of Sideview Utils 2.1, you can continue to use the empty implicit "all time" timerange, but you can also use an explicit "all/all" timerange. The all/all arguments will never go to Splunkd, but I tweak the framework so as to treat all/all differently from the implicit kind while the data is passing through the module system.

The difference that I create is that the explicit kind will cause TimeRangePicker modules to select themselves to "All Time", where the implicit kind does not.

The biggest upshot of that is that in complex form search views, you can set the TimeRangePicker to "all time" now and the back and forward button behavior will still work correctly.

And because of this you can now link drilldowns to custom views and actually prepopulate the 'all time' timerange when appropriate.