You might take a look at the "advanced" mode in the Pulldown module. Although the CheckboxPulldown module is almost always a better option, the older "advanced" mode does technically give you the functionality you're asking about - in that the user can type and the module will narrow down the matching selections as they type. (Note that the module still pulls the entire list of options down to the client - there is no cleverness like postprocess searches going on here - just local filtering) To get some examples of Pulldown module in the "advanced" mode, manually go to /en-US/app/sideview_utils/testcases_for_pulldown_with_chosen in your browser and open the source of that XML view in a text editor. Although there are no official docs for this mode (like I said CheckboxPulldown is generally a much better choice), the testcases will give you an idea of the breadth of functionality. ... View more

Actually the best advice I can give, is to use the CheckboxPulldown module which came out back in Sideview Utils 3.2. 1) CheckboxPulldown is so much better and more useful of a control than the multiselect Pulldown that I consider the multiselect Pulldown to be obsolete. 2) CheckboxPulldown actually selects everything by default. There is a weird and crazy workaround that I've seen though, and I mean very weird. First, don't actually do this - use CheckboxPulldown. 😃 But I mention it cause it's fun. Stitch a sequence of other modules just upstream of that Pulldown. Say that the name param of your Pulldown module is foo 1) PostProcess to do | stats list(foo) as foo | eval foo=mvjoin(foo,"::") , ie giving you a big string of all the values separated by :: 2) ResultsValueSetter to pull $foo$ down as a token, 3) ValueSetter with <param name="name">foo</param> , <param name="value">$foo$</param> and <param name="delim">::</param> Coming out of the ValueSetter is an array-valued foo token that has the same name as the Pulldown and that just happens to have every value in that Pulldown. the multiselect Pulldown module will see that array valued token and set it's own selection to it's values. Thus all become selected. But again.... don't do that. Just use CheckboxPulldown. It's way better and selects all options by default. ... View more

1) In a dynamic Pulldown module, if you want the "All" option to go away, you have to set <param name="staticOptions></param> Basically the default value of staticOptions is "All/*" so you have to explicitly set it to null to take it away. There is a docs page in Sideview Utils dedicated to this exact topic, at "Module Documentation - form element modules - The Pulldown module - Configuring the 'all' options" (make sure you're on a relatively recent version of utils and not 1.3.5 as this docs page probably didn't exist back in the ancient 1.3.5 version) 2) As far as setting one of the dynamic options to be selected by default in a dynamic Pulldown, this is fairly straightforward and you use the ValueSetter module. Go to "Module Documentation > The ValueSetter Modules > The ValueSetter Module", and it will give you a working example of how to use ValueSetter to prepopulate a dynamic Pulldown and tell you about it all. There is a link to that same page from the "notes" section in the docs page "Module Documentation - form element modules - The Pulldown Module - dynamic config". ... View more

You just need to put an autoRun="True" onto that initial Search module. That will kick off the cascading push, which will cause the search to be dispatched, which then causes the Pulldown to render. With a Table module you sort of expect it to sit there and not render with no autoRun="True" . With a Pulldown people often have the opposite expectation, but all of the Sideview modules behave that way - without some user-initiated push (like clicking a green button or hitting return in a TextField), or a autoRun="True" push from somewhere upstream, it'll all just sit there. ... View more

I'd try a couple things 1) upgrade to the latest Sideview Utils. I see some old legacy param names here that make me think you're using the ancient 1.3.5 version. There were some weird issues way back when and this might be one of those, I can't remember. 2) remove the PostProcess module entirely and try it with the postprocess param on the Pulldown module. ie <param name="postProcess">| dedup FIELD2</param> . 3) throw a <module name="Table"/> in right before the Pulldown. And you can send a screenshot to nick [at] sideviewapps.com. ... View more

Well, it most likely is caused by some search syntax error that for whatever reason only occurs sporadically. When there's a search syntax error on a postprocess request, unfortunately Splunk returns 404. Since an actual 404 isn't terribly common (for instance if your search results suddenly vanished or if someone deleted your job ), it's almost certainly one of these "syntax error" 404's, which are in my experience quite common. You can often fish out the postprocess search syntax and troubleshoot and often the nature of the error comes to light. For instance if the postprocess search makes an assumption that some field will always exist, it might generate an error when that field turns out to be absent. Manually glue the two pieces back together and experiment in the search page. I bet there's some lookup syntax that generally works and sometimes generates a "not all fields in lookup could be found" error or something like that. ... View more

You want to remove the |table result on the end of your postprocess search, or at least change it to say |table result title . The way it is now you are throwing the title field away and thus ResultsValueSetter wont be able to pull it down. You can also specify multiple fields in the ResultsValueSetter module's "fields" param so one way to read your question is that you're trying to do <param name="fields">title, result</param> and that would allow you to use both $title$ and $result$ however you like. Again you do need to make sure that both of those fields are present in the first row of the results. ... View more

The problem is that the SavedSearch module can't pull the savedsearch name from a $foo$ token. So it's literally looking for a savedsearch called "$searchName$". The reason I haven't gotten to this yet is that it involves a fairly big rewrite of the module. The module currently does all this work when the page is loading, ie before any modules exist, and long before they are passing around $foo$ tokens. There is a workaround fortunately and that is to use the Search module and get the results for the given job either via the loadjob command or the savedsearch command, depending on whether you're trying to load previously scheduled job, or dispatch a new search. http://docs.splunk.com/Documentation/Splunk/latest/SearchReference/Loadjob http://docs.splunk.com/Documentation/Splunk/6.1.1/SearchReference/Savedsearch n ... View more

Sideview is certainly still actively maintained. You can always check out our release notes here, and get on the mailing list for future updates here. By our count there are a couple thousand companies using it and the release of new UI features in both Splunk 6.0 and 6.1 has not dented our download numbers. In fact they are a bit up. There is a lot of uncertainty as to what will happen to the old UI systems, commonly known as "the advanced XML". There's also sometimes a little misinformation. I have talked to a lot of customers who were told that the Advanced XML would be removed in 5.0 or 6.0, or 6.1. Or customers who were told that Sideview Utils would definitely not work in 6.1, and the like (Obviously these were false). I somewhat regularly meet folks who ask me what Sideview will do when the advanced XML is removed in 7.0 and I try to politely disagree. In Splunk 6.0 and 6.1 they have certainly moved away from that system in the core product and in most of their apps. However a) many of Splunk's own apps continue to run on top of the advanced XML to this day. b) any deprecation or removal of the advanced XML would be over the dead bodies of a significant number of customers. Might Splunk do it anyway? I have no idea. I doubt it. It doesn't really cost them anything because the primary carrier of the support burden on the old system at this point is Sideview itself. there are hundreds of bugs patched and feature gaps filled by Sideview Utils at this point, a contribution that has outstripped the improvements and bugfixes contributed by Splunk. but it's more complicated than just Simple XML vs Advanced XML. Let's break it down. a) The simple XML, but only using the dashboard wizard. This is great. It's a lot less limited than it used to be, but it still has limitations. But the technical bits of your brain can focus on the search language, and most of the rest is available in the wizards. b) the simple XML, but hand-editing the simple XML format. You can do a bit more with this but you lose that dashboard-wizard, visualization-editing awesomeness and now you're hand-editing XML. This layer is kind of a bummer and since ultimately you're still pretty limited, customers in my experience tend to jump to Sideview Utils from here after a short time. c) The advanced XML, using only core Splunk modules. This is terrible. Nobody uses this and you shouldn't either. If you look on answers, for a long time now the people posting advanced XML questions are all using Sideview Utils modules. d) the advanced XML but using the Sideview modules instead of the core ones and using the core patches from Sideview Utils. Lots of new features, normalized conventions and systems, less verbose XML syntax. But yes ultimately there are the same really weird things and the XML hierarchy is still there, and you have to read the Sideview Utils docs page "Introduction to the Advanced XML" to understand it and to thrive. And you're editing XML - You can use the Sideview Editor, which is a fully featured authoring system for the Sideview views although many people do still choose to hand-edit the XML. e) or in 6.0 and 6.1 you can press a button to convert your Simple XML to a big page of HTML and Javascript ie the "new splunk web framework". This is what Splunk will urge you to do if you can't live with some number of the Simple XML's limitations. If you have N years of job experience as a professional web developer or as a software engineer, this is a great system and it puts you right where you want to be. On the other hand if you are like most Splunk admins, they lose you completely at this point. 60 lines of javascript and 20 lines of CSS and 10 lines of weird django syntax, for a pretty simple page that mirrors something you can do in the simple XML... For the thing you actually need to do - ok now you need to read code samples and write javascript. As for how to enumerate the advantages, that is hard. Certainly if you play with the Splunk 6.1 dashboard wizard you come away thinking it's totally awesome and it'll be totally sufficient. But if you actually make dashboards for a day or a week you'll still hit limitations. Going the other way, let's say you go through Sideview Utils, specifically through the 60+ documentation and examples pages and through the params and features of all the Sideview Utils modules, as you're going through ask yourself how many of those features can be accomplished with the dashboard wizard. The answer is actually not very many. And there are some incredibly cool things like Table-Embedding and the Multiplexer module that the new splunk UI will probably never be able to do (at least not without making people dive into writing their own javascript). ... View more

Goodness. Yes thanks for reporting this - this is a bug in the Lookup Updater. Fortunately it's a silly one and quite easy to fix locally. Go to $SPLUNK_HOME/etc/apps/sideview_utils/default/data/ui/views/update_lookup.xml on line 100 you'll see this XML: <module name="Pager"> <module name="Multiplexer"> <param name="field">key</param> <module name="HTML"> <param name="html"><![CDATA[ <div class="addNewRow"> <label>$key$</label> <input type="text" name="$key$" onblur="clearMessages()"> </div> ]]></param> </module> </module> </module> That is basically the entire "add new row" section believe it or not. Just remove the Pager module from the top, and remove a closing </module> tag from the bottom and this problem will go away. It was a mistake to Page that Multiplexer - since the Lookup Updater makes no attempt to remember the selections, when you clicked page 2 it just throws page 1 completely away. Without that Pager, it will happily render all 30 fields worth of text inputs. UPDATE: you mentioned that setting <param name="count">30</param> on the Pager didn't work for you -- I'm thinking you must have some different stuff in a customized version of the tool, because there is no $results.count$ shenanigans going on in the core Lookup Updater. Anyway, yes if there is a $results.count$ coming from upstream, absolutely the Pager module will listen to that. as will the Multiplexer as well. So the answer in that case would be to add in a <module name="ValueSetter"><param name="arg.results.count">100</param> upstream from the Pager. I think this will make sense to you. ... View more