Prepopulate Time Picker via URL parameter?

[vbumgarn]

Is there any way to prepopulate the Time Picker via a URL parameter?

I need to build a search dynamically in an external application. I have been building URLs that look like: /en-US/app/search/flashtimeline?q=search%20++starthoursago%3D7+bytne-1tu-5buf (starthoursago=7 bytne-1tu-5buf)

The issue is that if I want to send the user to a particularly heinous search with subsearches or joins, the starthoursago does not apply to the inner searches, which instead get the timeframe from the time picker, which defaults to whatever the user had done before.

So, another attempt... Starting the search via REST, then retrieving the Search ID, the user can be sent to: /en-US/app/search/flashtimeline?sid=12345.123

This works out because all parts of the search are run using the start and end dates specified in the REST call.

The problem is that the time picker doesn't reflect what was used by the search, so if the user modifies the search and runs it again, it will most likely be All Time.

I see there is another attribute when you get a link to results, but that doesn't look like something that could be built externally. flashtimeline?sid=1273187542.412176&vs=g8w6zq9w

Is there anyway to build that vs attribute externally, or are there other URL params that can be used instead?

Cheers.

[sideview · Accepted solution]

Yes there is. Just remove the earliest="foo" searchterms from your search, and instead pass them as separate parameters on the URL, 'earliest' and 'latest'.

EG:
/en-US/app/search/flashtimeline?q=search%20++bytne-1tu-5buf&earliest=-7h

I see that you're using the old 3.X timeterm syntax btw. The old starthoursago=7 syntax maps to earliest=-7h.

I think we still support starthoursago=N and all those but they are definitely not recommended. Recommended practice is to use the new more compact and more flexible syntax and to keep the time terms out of the search language entirely by using the separate arguments.

See here for more details on the syntax http://www.splunk.com/base/Documentation/4.1.2/User/ChangeTheTimeRangeOfYourSearch

[sideview]

Correct. When you have a sid the job already exists, and the time arguments are set when the job is created. Hence you cant pass both sid and time arguments on the same URL (well you can but it'll ignore the time args)

[vbumgarn]

Excellent. That works on queries specified with q, even with seconds since epoch. It doesn't seem to work on sid, but that's okay.

Cheers,
Vincent