My goal is to use the SearchControls Module along Tabs & PostProcess Module to deliver different views of the base search. I have a set of tabs generated by search results:
Domain Ip Filename
Then I have one static tab:
All
The value generated by selecting a tab is used downstream within the PostProcess module to filter results. The problem is that the SearchControls Module does not seem to take on the changes made when selecting a tab. It seems to just use the results from the ALL tab which is first one that loads. If I click another tab, the results are filtered but the SearchControls Module still exports results from the All tab.
<module name="Search">
<param name="search">index=myindex search goes here</param>
<module name="Tabs">
<param name="name">thisTab</param>
<param name="postProcess">dedup my_type | sort my_type</param>
<param name="valueField">my_type</param>
<param name="name">thisTab</param>
<param name="labelField">my_type</param>
<param name="staticTabs">
<list>
<param name="value">%</param>
<param name="label">View All</param>
</list>
</param>
<module name="PostProcess">
<param name="search"><![CDATA[WHERE my_type like("$thisTab.rawValue$")]]></param>
<module name="Pager">
<param name="collapseWhenEmpty">False</param>
<module name="SearchControls">
<module name="SimpleResultsTable">
<param name="entityName">events</param>
<param name="drilldown">row</param>
</module>
</module>
</module>
</module>
</module>
I'm afraid that the SearchControls module, like it's core Splunk analogue JobStatus, can only export, save, print, etc.. the main search results that exist at it's location in the XML hierarchy. It wont pay attention to postProcess arguments.
And the change to make it do so would be very comprehensive - the relevant code isn't actually in the SearchControls module at all, but scattered across the core Splunk wizards and python controllers that power the saving,sharing,exporting,etc....
that said, if your need is to just export the relevant postProcess'ed results, I can look into this as essentially a CustomBehavior example, and put that example in a future version of Utils. It would be much simpler - just a Button module and a CustomBehavior module, with that customBehavior's JS defined out in application.js.
I'm afraid that the SearchControls module, like it's core Splunk analogue JobStatus, can only export, save, print, etc.. the main search results that exist at it's location in the XML hierarchy. It wont pay attention to postProcess arguments.
And the change to make it do so would be very comprehensive - the relevant code isn't actually in the SearchControls module at all, but scattered across the core Splunk wizards and python controllers that power the saving,sharing,exporting,etc....
that said, if your need is to just export the relevant postProcess'ed results, I can look into this as essentially a CustomBehavior example, and put that example in a future version of Utils. It would be much simpler - just a Button module and a CustomBehavior module, with that customBehavior's JS defined out in application.js.
I went ahead and implemented a new export controller packaged in Sideview Utils that supports postprocess and I have modified the SearchControls module to use that controller for exporting. The end result is that the export button from SearchControls will account for postProcess. This update to Sideview Utils hasn't actually released yet but I am hoping to release it before christmas. I'll post back here when it goes out.
@sideview
if you have the example let us know
Yes, please. I'd like such a CustomBehavior example. Have you created it yet?
Thanks for clearing that up. I think this would be an great example to include in future versions of Utils. It would allow easy exporting of sub-sets of data without having to run multiple searches. For now my fix seems easy enough. I'll have the selectedTab value dictate the search or maybe use a switcher. BTW, A++ on SideView Utils.