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. ... View more

Yea.. it's extremely unintuitive. You have to add a new HiddenSearch module that duplicates the savedsearch basically but has the little $foo$ token for the intention to plug into. =/ Nest that inside your SimpleResultsTable. As for the dashboard examples app ( http://apps.splunk.com/app/1265/ ) there are a lot of advanced xml examples in there. They may or may not be correctly linked from the nav. grep through the xml files for stringreplace. =/ Or go battle the dragons that are preventing the use of SVU. ... View more

OK. I think the remaining problem is that your stringreplace intention requires that you have a $libname$ token in the string. I know I said that $foo$ tokens and intentions are separate things (they are), but when a search is dispatched, the core Splunk UI basically evaluates intention arguments and replaces them into the corresponding $foo$ token - here $libname$. And if you don't have one for a given intention it throws it away and nothing gives you any error or warning. Review the stringreplace example that you'll find somewhere in the "dashboard examples" app. ... View more

It's really really confusing. $target$ is a ConvertToIntention thing. It really means $libname_setting$ since that's what you have in 'settingToConvert'. There's a newer ConvertToIntention syntax I put in, whereby you can just put $libname_setting$ in place of $target$ and NOT set settingToConvert at all. But yea the SimpleResultsHeader thing just says the click.value key is there. It has nothing to do with the intention. ... View more

Can you post the xml to pastebin? I would normally tell you to put an HTML module in there to debug the key $foo$ tokens, or to use the Sideview Editor's Runtime Debug mode. =P. But it will be either module order (read framework_intro about when/where/why the splunk ui framework dispatches searches), or $foo$ token mismatch. When you say you can see the intention in SimpleResultsHeader I don't know what that could mean, because intentions are not $foo$ tokens and cant be treated as such. ... View more

Weird. links to the 2 docs pages are at the top level of the Module Documentation menu, so "Module Documentation > the Gate module > Gate - Blocking Searches" and "Module Documentation > the Gate module > Gate - Complex Drilldowns" . If you dont have that item in your docs menu, even though you're on 2.7, one possibility is that you've refreshed the views since updating but you haven't restarted splunk or refreshed the nav? Go to the Freshmaker and click "nav" (ie /en-US/app/sideview_utils/refresh_entities) ... View more

without Sideview Utils.... probably but again you'd have to patch source code. 😃 With Sideview Utils it would be easy! At the risk of sounding like a sales guy - there is a licensing faq and often the cost of OEM licensing is far less than people had expected. http://sideviewapps.com/apps/sideview-utils/licensing-faq/ ... View more

Right. You also ALMOST CERTAINLY will be running into problems if you're tailing these files where it only indexes a couple of them at all. This is because your header is so big. You'll want to set something like: initCrcLength = 5000 that will tell splunk to look 5000 chars into the start of each tailed file when it's determining whether it's looking at a rolled copy of a file already indexed, or a new file. The default initCrcLength value is far too low for this sourcetype and splunk will never check past the header row, so it'll conclude that all files after the first are dupes. ... View more

My guess is that the culprit is MAX_TIMESTAMP_LOOKAHEAD=8 this says that Splunk should look only 8 characters into each event and if it doesn't find a timestamp by that point, give up looking for one. and HEADER_FIELD_LINE_NUMBER is designed for cases where you have a csv or tsv file or what-have-you where the header isn't technically on the first line but rather on the second or third. In most cases since it defaults to 0 you should just leave this unset and not think about it. As to why INDEXED_EXTRACTIONS doesn't seem to be working, I'm not sure. Things look fine. Maybe the wonky timestamp was putting things in very wrong times and causing confusion. ... View more

Sorry - no, it's a module patch so you put it as-is into application.js. What'll happen is that when that view loads ("some_special_view"), the SimpleResultsTable modules in that view will have that behavior instead of the default behavior. ... View more

hehe. Believe it or not I've written customBehaviors to do exactly that. With some help from postprocess to figure out what "page" the given result row is actually on, and then some tinkering with Pager to go to that page. Sideview's app for Cisco CallManager has a page where a couple tables get selected to dynamic values and the Pager/Table automatically loads that page. 😃 Although I wasn't thinking of going that far into Wonderland, it's actually not a terrible idea... I'll look into providing such a feature. ... View more

There may be a pure search language solution where you use the first search inside a subsearch, and then have a conditional eval creating a field called "query" that has the string value of the entire second search, if the condition matches, and that has a value of "foo NOT foo" otherwise. If you had return query or |table query | head 1 at the end of the subsearch, then based on the condition the subsearch would basically yield out to the main search pipeline, either the entire search string of the second search, or the "foo NOT foo". Of course the drawback is that you have no ability to actually show the user the results from the first search. It's either the second search runs or nothing runs. Unless you wanted to package the first search string again inside the subsearch. <head explodes> On a different tack, and I'm not sure if this is the answer you're looking for, but there are a couple ways to do this at the UI layer if you're using Sideview Utils. The best I think is to use a ResultsValueSetter with a Switcher. You first would use a bit of search language in the first search to create a field called "proceed" that has values true or false, then use a Sideview ResultsValueSetter module to pull down that field value and make it available as $proceed$. Then you could use a Sideview Switcher module to only show and run the second query (and all its charts and whatnot) if the $proceed$ value is "true". This same technique can be applied over and over and you can build quite complex chains of automatic search logic inside a single dashboard. Sideview Utils contains docs pages that have working examples for both ResultsValueSetter and Switcher modules. http://sideviewapps.com/apps/sideview-utils ... View more

My apologies - I had a typo in my XML and the "name" param of the Pulldown was set wrong. I edited my answer so that the value of the Pulldown's name param is now "company" ... View more

I don't think there's a way to do this without Sideview Utils. If you do have Sideview Utils though, this is exactly what the "default" param on the Table module does - it allows there to be an initially selected selection on a drilldown table. Prior to the existence of the Table module, I used to patch the SimpleResultsTable module's behavior to do this sort of thing. This kind of patch involves understanding isReadyForContextPush, which is one of the least documented areas of the framework, but the code at least for such a patch is relatively short. Note here the "some_special_view" to make sure that the patch only applies within a particular view. if (Splunk.Module.SimpleResultsTable && Splunk.util.getCurrentView() == "some_special_view") { Splunk.Module.SimpleResultsTable = $.klass(Splunk.Module.SimpleResultsTable, { hideDescendants: function() {}, showDescendants: function() {}, isReadyForContextPush:function() { if (this.getLoadState() < Splunk.util.moduleLoadStates.HAS_CONTEXT) return false; return true; } }); } But it's definitely better to just use the Table module if you can. ... View more

If what you need can boil down to a search using the datamodel command, then it will run just fine in Sideview Utils. http://docs.splunk.com/Documentation/Splunk/6.0/SearchReference/Datamodel Under the hood datamodels are implemented using the search language - generally tstats , stats or transaction , and I always just use those bits and pieces directly instead of trying to get datamodel to compose them for me. If you get a comfort level with that lower layer, then again you're just running searches and Sideview Utils runs fine... If you want to use or embed Splunk's Pivot User Interface somehow in your Sideview Utils views, that's another story entirely and that's really not possible. ... View more

There's no simple way. There are I think a couple very strange ways. One that springs to mind is to use a couple Gate modules and apply autoRun a little cleverly. Gate is a relatively new Sideview module, and it has two features. The first allows it to block pushes from upstream until some set of $foo$ tokens are present. The second allows it to kind of teleport pushes from it's location the module hierarchy to another Gate module elsewhere in the hierarchy. Here we will use the second feature only. You could have your form element modules, and then downstream from them you have a Gate module with an "id" param of "insideFormElements". Then downstream from the Gate you have your tables and charts and whatnot. Then, completely unrelated to those modules, up at the root level of the view you could have a SavedSearch module with a Gate module downstream. That Gate module would have a "to" param set to "insideFormElements". Put an autoRun="True" on the SavedSearch module and nowhere else and you've basically implemented the thing you need here. When the page loads, the SavedSearch gets the scheduled job, and then teleports it through the gate past all the form search elements. Then when the user makes really any change in the set of form elements, that push would clobber the old push from the saved search results and you'd get an ad-hoc search dispatched automatically. Use cases for the Gate module are always kind of brainbending, but it's an extremely handy module if used wisely. As always the docs and the working examples for the Gate module are embedded in the Sideview Utils app itself. Gate released in 2.4.8 but it received pretty substantial changes in later releases so make sure you're on the most current Sideview Utils (2.7.1 as of this writing). http://sideviewapps.com/apps/sideview-utils UPDATE: Actually the Gate module idea doesn't work here, due to a wrinkle around autoRun="True". Pulldown modules need an autoRun="True" attribute somewhere upstream from them in order to render themselves when the page loads. However once you put that autoRun="true" attribute it will push on down through the rest of the page and your scheduled search results wont be used - instead the autoRun push will dispatch an ad-hoc search. Sorry for the waste of time! ... View more

You can't really do this with Switcher - Switcher can only pick one of it's N direct children as the "active" one. It then shows that module and all its downstream modules, and hides all the other children and their descendants. Fortunately what you need here is very commonly implemented as a customBehavior and quite easy to implement. You might have on your Checkbox module: <param name="customBehavior">hide if foo is selected</param> and then in application.js you would have this: if (typeof(Sideview)!="undefined") { Sideview.utils.declareCustomBehavior("hide if foo is selected", function(checkboxModule) { var methodReference = checkboxModule.onContextChange.bind(checkboxModule); checkboxModule.onContextChange = function() { methodReference(); var context = this.getContext(); // long story, but each "mode" by which a module might be shown // or hidden needs its own name. var visibilityToken = "hide me when the other checkbox is foo"; if (context.get("otherCheckboxName")=="foo") { this.hide(visibilityToken); } else { this.show(visibilityToken); } } }); } You'll have to edit it to change the "otherCheckboxName" to be the name param of the upstream checkbox, and obviously the magic value wont be "foo", but hopefully you can read the code enough to modify it for your purposes. Beware that when you first create the file at appserver/static/application.js for a given app, that you have to restart splunkWeb for it to get picked up. And beware as you edit it thereafter that Splunk has very aggressive cacheing for static files so prepare to clear your cache a lot and get to know the "bump" endpoing. Scroll down in the Sideview FreshMaker to read about the bump endpoint. read the "Tools" page in Sideview Utils if you don't know what the heck the FreshMaker is. 😃 And one last note... usually in this situation merely showing or hiding the form element isn't all you have to do - you usually have to make sure it's checked or unchecked as appropriate so that it's $foo$ token doesn't wreak some kind of havoc downstream. Making this change at the same time might require reading through the Checkbox module's source code a little, or I could help you through that in subsequent comments here. ... View more

The Simple XML to Advanced XML conversion for <form> views has always been flaky. However I think here you've discovered a newer class of problems where the new 6.0 simple XML renderer is actually capable of doing something that the core Splunk Advanced XML system is not really able to do. To back up a second - in 5.0 and earlier the Simple XML was kind of a macro layer that was implemented at runtime by some equivalent Advanced XML config. In 6.0 the Simple XML is actually rendered by a completely different UI system. This puts the "conversion" utility into a strange situation - where the supported range of configurations for simple XML and advanced XML may no longer match well. Fortunately I recommend, across the board, never converting Simple XML views to Advanced XML views using the default converter. The core advanced xml systems are limited inconsistent and pretty bewildering, and the converter introduces a certain amount of cruft into the XML that makes it even worse. Instead it is easier to get familiar with the latest Sideview Utils app ( http://sideviewapps.com/apps/sideview-utils ) and then rewrite the dashboard in the Advanced XML format, but using Sideview modules. Here is your view rewritten. You may agree with me that it's not really any more complicated than the "simple" xml. <view autoCancelInterval="90" isVisible="true" onunloadCancelJobs="true" template="dashboard.html"> <label>Excel Export dashboard Simple 2</label> <module name="AccountBar" layoutPanel="appHeader" /> <module name="AppBar" layoutPanel="appHeader" /> <module name="SideviewUtils" layoutPanel="appHeader" /> <module name="Message" layoutPanel="messaging"> <param name="filter">*</param> <param name="maxSize">2</param> <param name="clearOnJobDispatch">False</param> </module> <module name="Search" layoutPanel="panel_row1_col1" autoRun="True"> <param name="search">| inputlookup rich-co</param> <param name="earliest">-1h</param> <param name="latest">now</param> <module name="Pulldown"> <param name="name">company</param> <param name="label">Select a Company:</param> <param name="template">Company="$value$"</param> <param name="valueField">Company</param> <param name="labelField">Co_Name</param> <module name="TimeRangePicker"> <param name="selected">Last 4 hours</param> <module name="Search"> <param name="search">sourcetype="completions_*" $company$</param> <module name="Pager"> <module name="Table"></module> </module> </module> </module> </module> </module> </view> ... View more

Properly parsing arbitrary numbers to correctly determine what country code is in there, if any, is a very tricky matter. Unless you're dealing with a small subset of country codes, and unless you're fine with a lot of false positives from things like incomplete numbers, you can't really do it with regex. http://en.wikipedia.org/wiki/List_of_country_calling_codes Our most recent Splunk for Cisco CDR app packages some code licensed and ported from Android that actually parses out the numbers as well as local area codes. From this it infers geographical regions. Within the US it also parses exchanges and gets zipcodes which it then uses to get an approximate city and state. I've been thinking of releasing the package as its own commercial Splunk app for use with anyone who wanted just that one feature. What particular call system are you using here? It's also quite possible that Sideview could create an app for that system and package these same features for that system. btw the code we use is a python port of Android's libphonenumber ( http://code.google.com/p/libphonenumber/ ) ... View more

OK. There's probably a lot of things that could be improved fwiw. There always are. If you have a second check out the Sideview Utils homepage which has a little gallery table that gives you some examples of problems and solutions. I say this only because most early users start only using one or two things because they don't know about the other 20 things. Cheers though. I understand the hesitation. ... View more

you would have $summary.label$ if you were using a Sideview Pulldown module instead of the core Splunk StaticSelect, and all sorts of other useful keys. StaticSelect will just be giving you $group_setting2$ though - and not $summary$. "Summary" is actually an intention, and since you're already using Sideview Utils you don't want to be using that at all. The Sideview docs and workign examples - particularly on the page that introduces the Search module - will tell you more and then you'll be able to delete the ConvertToIntention module and never use it again. But more generally if you're already using Sideview Utils then you really shouldn't be using StaticSelect or SearchSelectLister by the way - you should use Pulldown. Read the Pulldown docs and the docs about linking (ie Redirector) and things will get a lot simpler. And don't use the $foo.label$ keys for under-the-hood stuff like drilldown arguments and url components. Use $foo$ or $foo.rawValue$. Again the docs and examples can explain. ... View more

You're right by the way - your time is being extracted from an epochtime value and there's a longstanding bug in Splunk where it cannot determine timezone when it gets the time from an epochtime value. Instead of using local server time, or failing that not creating date_* fields at all, splunkd creates all the date_* fields as though the data was from the GMT timezone. So effectively date_* fields is always unreliable whenever _time is extracted from epochtime values. (unless you happen to use GMT on that host. 😃 ... View more

Yea it sounds like Sideview Utils didn't get installed all the way. Maybe you didn't restart Splunk after the upgrade or maybe there had been manual permissions and file ownership changes made on disk such that it disrupted the upgrade later? In such cases you can end up with a frankenstein build where some parts are new and some parts are old. The bugs resulting from such a problem might be subtle or might be very dramatic. ... View more