Saving the Current Configuration on the Dashboard

[cmak]

I have a dashboard view that has pulldowns that modify the original search query. I was wondering if there is any way to save the dashboard with the current selections.

I know by using Sideview Utils, there is the URLLoader that saves a URL with the current configs. However, I would like to know if it is possible to save it the same way as saving a normal search (so it saves in the Splunk database and can be accessed from the menu).

I do not want to simply save the search query normally since I want it to be loaded in my own view.

[sideview · Accepted solution]

Yes. I need to write up official documentation for how to do this, but this is what all the Sideview apps do, and it works well.

First of all, Sideview has built a system whereby the viewstates.conf system can be bypassed, and instead the keys to restore all of the form elements in a form search, will be saved into the savedsearch itself. This eliminates a lot of headaches around viewstates.conf and having things line up with savedsearches.conf.

Here's how you do it.

1) Make sure you have the latest Sideview Utils app. Sideview Utils has a savedsearches.conf.spec file in its README directory, and by virtue of this some new keys are added to the allowed keys in savedsearches.conf across all apps. And by latest I mean the latest version from the Sideview site, which is 2.4, not the latest from Splunkbase which is 1.3.5 and which is actually quite old. You can get it from http://sideviewapps.com/apps/sideview-utils and it's free for internal use.

2) In your app, in your savedsearches.conf file, put this up at the top.

[default]
request.ui_context = 
request.ui_edit_view = 

3) Obviously you'll need some control that the user can use to save searches and create alerts and dashboards. I recommend the Sideview 'SearchControls' module, which looks like Splunk's JobStatus module but is more flexible in its configuration. Put this module into your view and put it downstream from all of the UI controls you wish to prepopulate when the savedsearch is loaded. It does not need to nest any modules inside it. Generally you put it near the HTML module you're using as a results header, or near a JobProgressIndicator.

4) Make sure you have a URLLoader at the top of your view, and that all the modules on the page are nested inside it. Or at least all the modules you want to prepopulate from the URL and from saved searches.

5) You're almost there. You just need to import two files from Sideview Utils, to patch the core systems around saving searches to establish the new conventions.

Up in the SideviewUtils module, which usually sits at the top of the page and looks like:

<module name="SideviewUtils" layoutPanel="appHeader" />

Replace that with this:

<module name="SideviewUtils" layoutPanel="appHeader">
  <param name="customJavascript">sideview_utils/report.js sideview_utils/save_create_patches.js</param>
</module>

This will effectively import two files from the appserver/static directory of Sideview Utils, and load them in your view.

And that's it. Searches saved in this view now will not actually generate viewstates into viewstates.conf, but instead you'll get these request.ui_context keys generated right in your savedsearch stanzas. And when you've saved some searches after these changes and you go to run them from the menu, you'll see that no matter how complicated a form search view you have, all of the Sideview modules (TextFields, Pulldowns, Checkboxes), and the main Splunk modules (SearchBar, TimeRangePicker), will get it's selection state restored correctly.

Be aware that if you ever deploy these savedsearches to another Splunk instance, you have to make sure that that these steps are covered on that instance as well or else the prepopulation wont work, and Splunk might complain on startup about these unknown keys.

And again, this will only work if you have the latest versions of Sideview Utils. As of this writing the latest is 2.4, and is available from http://sideviewapps.com/apps/sideview-utils . Note that if you only have the latest from Splunkbase that is only version 1.3.5 and these steps will not work.

[sideview]

Cool. I'm glad you asked. Consider it upvoted as a new feature. 😃

[cmak]

Yup, that makes sense. I expected this, and it definitely is not too common. I just asked just in case

[sideview]

Not currently, no. Once you're in the wizard popup screens you're pretty much in core-splunk territory, and the limitation you're talking about is a limitation in those core Splunk screens. I might in the future add a purely Sideview-created wizard, and a corresponding entry in the SearchControls module's "save" menu "save existing report", but right now I'm afraid it's not a common enough request to rise very high in my queue.

[cmak]

I have an additional question about this functionality.
Once I save a search, is it possible to modify this saved search and re save it under the same name?

When I try to resave a search under the same name, it gives me an error that the search exists (this is correct behavior).

In order to do this, I actually must delete the search and then make a new one with the same name. Is there any way around this?

[sideview]

Radio module is now relased, as of Sideview Utils 2.4.5, which released today. http://sideviewapps.com/apps/sideview-utils

[cmak]

Thanks :), sounds good

[sideview]

I actually created the Radio module in Sideview Utils and it'll go out with the next maintenance release. The param space works just like Pulldown, Tabs and the "Checkboxes" module. You can use it to render zero or more "static" radio buttons as defined by explicit config, plus zero or more "dynamic" radio btons whose values and labels it will get from search results. Next maintenance release will be in about a week so it won't be long.

[cmak]

Sure, no problem

[sideview]

That's right. It wont prepopulate core Splunk modules besides SearchBar and TimeRangePicker. I'm afraid Sideview Utils doesn't yet have a Radio module although there's one in the queue. Hmm.. I could maybe patch StaticRadio more quickly than I can release the Radio module... In the meantime is there any chance you can use a Checkbox or Checkboxes or Pulldown instead?

[cmak]

This does not seem to work for the module "StaticRadio". Is it because that is not a sideview module? If so, which module should be used in order to show static radio buttons

[sideview]

Indeed - thanks Calvin for jumping into some email back and forth and because of that we were able to narrow down the bug and indeed the bug is fixed in 2.4.1 which released this afternoon. http://sideviewapps.com/apps/sideview-utils/release-notes

[cmak]

Sideview 2.4.1 fixed this issue 🙂

[sideview]

It seems to work fine in my testcases, and I took a look at one of my apps that does have many multiselect pulldowns in a view from which searches can be saved, and it works fine there. So there must be some other difference between the views? Run through it again -- URLLoader upstream from the Pulldown module, autoRun set correctly and not nested inside another autoRun... If it's a different app make sure the savedsearches.conf keys are in there etc.. Post the XML if you can't find it.

[cmak]

In Sideview 2.4, this does not seem to save multiple selection pulldowns. Single selection pulldowns are saved but multiple selection pulldowns are left blank. Is this a general bug, or just happening in my app?