Dashboards & Visualizations

TimeRangePicker Won't Hold Value on Dashboard

snowmizer
Communicator

How can I get the TimeRangePicker to always default to the value specified in my dashboard? I've read two different posts on this website and they both recommend using "isSticky=false" in the tag on the dashboard. I have tried this and it will not work. I've got the default set to "Last 4 hours" but it always shows "Last 24 hours" since that's what I used for a previous dashboard search (different dashboard). Here's the code I have:

<view template="dashboard.html" stylesheet="three_panel_custom_width.css" isSticky="false">
    <label>Cisco IPS Overview</label>
    <module name="AccountBar" layoutPanel="appHeader"/>
    <module name="AppBar" layoutPanel="navigationHeader"/>
    <module name="Message" layoutPanel="messaging">
        <param name="filter">*</param>
        <param name="clearOnJobDispatch">False</param>
        <param name="maxSize">1</param>
    </module>
    <module name="TitleBar" layoutPanel="viewHeader">
        <param name="actionsMenuFilter">dashboard</param>
    </module>
    <module name="SearchBar" layoutPanel="mainSearchControls">
        <param name="useAssistant">true</param>
        <param name="useTypeahead">true</param>
        <module name="TimeRangePicker">
            <param name="searchWhenChanged">true</param>
            <param name="default">Last 4 Hours</param>
            <module name="ViewRedirector">
                <param name="viewTarget">flashtimeline</param>
            </module>
        </module>
    </module>
</view>

Thanks.

1 Solution

sideview
SplunkTrust
SplunkTrust

(expanding on my own answer which was channeled by piebob)

I just experimented a bit and indeed it looks like there is a sizeable bug here. When you set isSticky="False" you would expect it to then ignore all previously "stuck" values. However it doesnt do this and what it does instead is prevent any further changes from sticking. So whatever you set it to the last time you touched it (ie before you changed isSticky to False) , that value will still apply. The end result is that your value in the XML will still get overridden.

Of course you can obliterate the most recently stuck value by deleting a key from a stanza in viewstates.conf. Unfortunately since it remembers these states independently for each user you'll have a stanza in a different viewstates.conf file for each user on the system. So to get it to fall back to the value specified in the XML you'll have to not just set isSticky to "False" but also modify one viewstate.conf file per user.

for example, for the admin user, within /etc/users/admin/search/local/viewstates.conf, there will be this stanza:

[flashtimeline:_current]
FlashTimeline_0_5_0.minimized = false
FieldPicker_0_6_1.fields = 
TimeRangePicker_0_1_0.default = Last 4 hours
FlashTimeline_0_5_0.height = 119px
SearchBar_0_0_0.autoOpenAssistant = false
Count_0_7_1.default = 50
MaxLines_0_13_0.default = 100

You can see in there that the TimeRangePicker is set to 'Last 4 hours'. For you this will say whatever the last change was before the day when you set isSticky to "False". And for all other users they'll have a stanza in a different file in a different folder. So this means you'll have to go find that stanza for each user you have.

And if your users ever use the flashtimeline view in other apps, you'll then also have to hunt down all the same stanzas in all the same user directories in all those other apps as well. Which is less than ideal.

(ie /etc/users/<username>/<appname>/local/viewstates.conf)

It is indeed a bug, and rachel/piebob has filed it so hopefully it'll be fixed soon.

View solution in original post

sideview
SplunkTrust
SplunkTrust

(expanding on my own answer which was channeled by piebob)

I just experimented a bit and indeed it looks like there is a sizeable bug here. When you set isSticky="False" you would expect it to then ignore all previously "stuck" values. However it doesnt do this and what it does instead is prevent any further changes from sticking. So whatever you set it to the last time you touched it (ie before you changed isSticky to False) , that value will still apply. The end result is that your value in the XML will still get overridden.

Of course you can obliterate the most recently stuck value by deleting a key from a stanza in viewstates.conf. Unfortunately since it remembers these states independently for each user you'll have a stanza in a different viewstates.conf file for each user on the system. So to get it to fall back to the value specified in the XML you'll have to not just set isSticky to "False" but also modify one viewstate.conf file per user.

for example, for the admin user, within /etc/users/admin/search/local/viewstates.conf, there will be this stanza:

[flashtimeline:_current]
FlashTimeline_0_5_0.minimized = false
FieldPicker_0_6_1.fields = 
TimeRangePicker_0_1_0.default = Last 4 hours
FlashTimeline_0_5_0.height = 119px
SearchBar_0_0_0.autoOpenAssistant = false
Count_0_7_1.default = 50
MaxLines_0_13_0.default = 100

You can see in there that the TimeRangePicker is set to 'Last 4 hours'. For you this will say whatever the last change was before the day when you set isSticky to "False". And for all other users they'll have a stanza in a different file in a different folder. So this means you'll have to go find that stanza for each user you have.

And if your users ever use the flashtimeline view in other apps, you'll then also have to hunt down all the same stanzas in all the same user directories in all those other apps as well. Which is less than ideal.

(ie /etc/users/<username>/<appname>/local/viewstates.conf)

It is indeed a bug, and rachel/piebob has filed it so hopefully it'll be fixed soon.

danielpellarini
Path Finder

A little update on this: it is not enough to look at the flashtimeline:_current stanza for every user, because if there are several dashboards in an app then there will be several other stanzas in the viewstates.conf file which have to be edited too.

0 Karma

cyndiback
Path Finder

Is this still a bug in 4.2? I'd like to set the default time per app without having to touch all user files.
Thanks

0 Karma

sideview
SplunkTrust
SplunkTrust

That means somewhere there's a viewstate still, or that the XML you're looking at is not what's running. And it will work for results-per-page as well, aka the 'Count' module.

0 Karma

snowmizer
Communicator

I thought this was working but I've gone through these steps for another dashboard and my timerangepicker is stuck on the last value I selected yesterday. Also, will this work for the "results per page" lists?

0 Karma

snowmizer
Communicator

Following this worked for what I needed. Thanks.

0 Karma

piebob
Splunk Employee
Splunk Employee

channeling Nick here:

"apparently if you set isSticky="False", it just means that it will no longer remember changes to the value. however it will happily continue sticking to the previously set value. so you'll have to set isSticky=False, and then find all the various places in various viewstate.conf files where different users have set different sticky values and delete them all. which if there's more than a few users is somewhat prohibitive."

i've filed a bug.

snowmizer
Communicator

Code didn't post properly:



true
true

true
Last 4 Hours
...

0 Karma
Get Updates on the Splunk Community!

Enterprise Security Content Update (ESCU) | New Releases

In December, the Splunk Threat Research Team had 1 release of new security content via the Enterprise Security ...

Why am I not seeing the finding in Splunk Enterprise Security Analyst Queue?

(This is the first of a series of 2 blogs). Splunk Enterprise Security is a fantastic tool that offers robust ...

Index This | What are the 12 Days of Splunk-mas?

December 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...