Within the app itself you will find dozens of pages of very extensive documentation, complete with lots of working interactive examples, and "view source" links on each page to make it easy to copy and paste from the official examples.
If the dashboards you need to make are a little too complex, clunky or limited in the Simple XML, but Splunk's HTML dashboards are just way out of reach, Sideview Utils may be the tool for you.
Also if you have dashboards that use Splunk's Advanced XML with only the Splunk core modules, you have even more to gain:
And if you're using the 1.3.X version but you've held off on upgrading to 2.X and now 3.X, you may be crazy. We have a Licensing FAQ page here that might resolve the uncertainty. If not just contact us. There have been hundreds of new features, new modules, new tools, bugfixes and big performance improvements that have happened since the 1.3 version came out 5.5 years ago.
Watch some demos to be convinced
And you can always read the Release Notes .
Fixed a mistake that prevented 3.4.13's redirect from working.
Improvements to the work done in 3.4.9 so now for any app that has a Sideview-XML view, when a user tries to load that view in 8.X (and has at least this version of Sideview Utils installed), they will either be automatically redirected to the Canary URL if they have Canary installed, or they will be redirected to a sorry page explaining what Canary is and how to install and use it.
3.4.12 (February 24th, 2021)
> Added "cssClass" param to Layer.
> Added a "drilldown" param to the Table module, although I'm sorry it
doesn't actually do anything here. It's really only here so that when 7.X
users using SVU happen to have a Canary app loaded that uses this param in
Canary, they don't get UI errors about an illegal param.
> Note: if you're reading these SVU will be going away at some point when
Sideview's commercial apps drop support for Splunk 7.X so take a look at
our Canary app and how well your views run as Canary views.
> Ported some changes from Canary to SVU so that apps can use the Canary
pattern of using a Layer of Link modules to present a clickable context
menu on some interactions like Table clicks.
3.4.11 (March 16th, 2020)
> Cleaning up some python syntax. Although I don’t think any of these were
causing python3 problems.
> Adding “covid19_sideview” to the list of canary supported apps. Until Splunk
implements some mechanism for legacy xml views to indicate where they’d
like their users to be redirected, this somewhat manual redirection method
is what makes the redirects work in Splunk 8 today.
Resolved an issue where the 'export' functionality of the SearchControls
module would fail with an error because the previous page would try to
autocancel the job being exported.
3.4.9 (September 23rd, 2019)
> Added a change to help users who have both Sideview Utils and Canary
installed on Splunk Enterprise 8.0, seamlessly redirect to their Sideview
view in the Canary UI instead of the Advanced XML UI.
> Fixed a problem around a change in browser behavior in the last few years,
where browsers no longer execute the "unload" handler when the user leaves
the page. Since this is the mechanism that the advanced xml uses to cancel
jobs that will be orphaned by leaving the page, the end result is jobs tend
to build up every time you leave the page. Essentially replacing this
with a new implementation that triggers on the "beforeunload" event and it
seems to work well and restore the original Splunk developer's intention.
3.4.8 (April 29th 2019)
> Fixed a bug where if CheckboxPulldown had no checkboxes selected, opening
and closing the checkbox list without making any changes, caused downstream
UI elements to refresh unnecessarily.
> Patched a UI regression introduced by Splunk in Splunk 7.2.5 that breaks the
TimeRangePicker's "relative", "real time" and "advanced" modes within
"Custom Time". The manifestation of the regressions is that the UI for
those other three modes never appears when you click on the control that's
supposed to activate them.
3.4.7 (March 1st, 2019)
> REST module now supports DELETE in addition to POST method.
> REST module now displays HTTP status codes in errorMessages properly.
> Layer module's default css now puts a min-width of 400px.
3.4.6 (January 14th, 2019)
> Fixed a regression caused by Splunk in 7.2 or 7.1 where all TimeRangePicker
modules got a "default times.conf label" entry that when clicked ran an
"all time" search.
> Report module now supports _time axis reports having $xFieldBins$ args
apply to the time axis.
3.4.5 (October 12th, 2018)
> removed the "fishies" search from savedsearches.conf, and commented out the
realtime timeranges on 2 disabled testcase searches used by one of the
SavedSearch module's example views.
NOTE: this release only exists to workaround an appinspect + cloud vetting
3.4.4 (September 19th, 2018)
> Fixed a bug in some advanced functionality that parses SPL to some extent,
where handling of "*" characters in search expressions led to literals
being erroneously recognized as fields.
> Fixed some cosmetic (CSS) issues with CheckboxPulldown and FieldPicker.
> Some improvements to Layer, Rest and Switcher to support them being used to
implement complex UI's whereby end users can create and edit Splunk
knowledge objects directly from your views.
> Implemented some CSS fixes for 7.2.
3.4.3 (July 6th, 2018)
> Added some troubleshooting logic to the Table module to help cases where
logic in a given view is flawed such that a postprocess search becomes
malformed and splunk then returns a confusing 404.
> Fixed a cosmetic problem in Splunk 7.1 where the text in custom date/time
picker fields was rendering slightly too large and getting clipped.
> Fixed a problem in the Report module, where if it was working with a binned
split-by field (zFieldBins), and the bins integer was higher than 10, it
would not set the same argument as a limit in timechart/chart, resulting in
many values falling into "OTHER".
> Significant improvements to the prototype modules "Layer" and "REST".
> Fixed a bug in the SearchControls module where the print button didn't
work in Splunk 7.1+
> Added a "nullTemplate" param to ArrayValueSetter. With this it now has a
way to generically handle the same kind of null entries that the form
element modules can process with their own nullTemplate params.
> Fixed a regression in CheckboxPulldown introduced in 3.4.1, where if one
option was selected the control's label wouldn't update at all.
3.4.1 ( April 24th, 2018)
> Updated the version of the jquery multiselect control used by the
CheckboxPulldown module. Fixed various functional and positioning bugs
when the module is loaded in Splunk 7.1
> Fixed various look and feel bugs in the SearchControls, Pulldown and Button
modules when they are loaded in Splunk 7.1.
> Fixed a bug in CheckboxPulldown's selectAllOptimization param, where if the
control ever found itself in the strange situation of having only a single
entry, the optimizations wouldn't be applied. Now they are.
3.4 (November 1st, 2017)
> Fixed a bug in the export controller causing it to always give the Save File
dialog a file extension of "csv" even if you picked json or xml as the
> Switched all URL's to Sideview Docs to use http instead of http.
> Removed the Sideview Editor from the app. It is now packaged inside the
"Sideview Admin Tools" app.
> Removed the Lookup Updater from the app. It is now packaged inside the
"Sideview Admin Tools" app.
> Fixed a bug in the DateTime module where $search.timeRange.earliest$ and
the $search.timeRange.latest$ keys wouldn't be respected properly when
received from upstream.
> Fixed a regression that occurs in Splunk in 6.6 and newer in the DateTime
module, where 'zoom to selected' interactions with the ZoomLinks module
were not working.
> Added new sample interfaces "Metrics Explorer" and "User Activity". Both
to showcase advanced functionality of the more advanced modules, and also
because the views themselves can be quite useful.
> Added a "hideOnEmpty" param to the CheckboxPulldown module, for cases
where you want to hide it completely if it ever has no options to present.
> Improvements to 2 prototype modules - Layer and REST. Testcases added.
Splunk AppInspect evaluates Splunk apps against a set of Splunk-defined criteria to assess the validity and security of an app package and components.
As a Splunkbase app developer, you will have access to all Splunk development resources and receive a 10GB license to build an app that will help solve use cases for customers all over the world. Splunkbase has 1000+ apps and add-ons from Splunk, our partners and our community. Find an app or add-on for most any data source and user need, or simply create your own with help from our developer portal.