New Sideview Utils module – NavBar

The latest release of Sideview Utils (3.3.9) includes a new module called NavBar that can be used to replace Splunk’s AppBar module.

Now why do I need to replace AppBar?.

Well, you very well might not! It has to do with the “displayview” setting in savedsearches.conf. If you’re a Splunk app developer who’s been around for a while you might have seen that setting. The idea of displayview is that a saved search can remember what view it is supposed to load in, and go to that view when run. If the key is empty, then the savedsearch of course loads in the generic Splunk UI.

Unfortunately in Splunk 6.3 the implementation of the main navigation in AppBar was changed and a (presumably unintended) side effect was that the “displayview” setting in savedsearches.conf broke. Thus in 6.3 and beyond, all saved searches and reports just load in the generic search/report view when run from the main nav. {sad trombone}.

but.. ok let’s say I used this key and it worked, how would form elements in my view repopulate correctly?.

With just the advanced XML, they wouldn’t! which is the main reason why displayview was so seldom used. (Prepopulation of form elements was part of the old 4.0 “resurrection” system which was incomplete and unstable, and turned off by Splunk some time ago anyway.)

But if you’re using Sideview Utils, Sideview Utils replaced this stuff with its own systems long ago, around a new key it added to savedsearches.conf (did you know that apps can actually extend the core conf space? Yay Splunk for doing many things properly long ago).

Specifically when the user saves a search or report in the SearchControls module, if
a) they use the Sideview SearchControls module and if
b) the view includes “sideview_utils/save_create_patches” in the customJavascript param of the Sideview Utils module and
c) the view uses the URLLoader module (most views with form elements really should anyway)

then it will file away upstream form element state into a key called request.ui_context. Then when any user runs the report later, it will load back in that view courtesy of displayview, and the form elements there would get set correctly courtesy of request.ui_context