Hi 🙂
We have a lookup table with 20+ columns and our users have noticed a problem when they use the "Add New Row" feature in "The Lookup Updater" in Sideview Utils 3.2.3 (on Splunk 6.0.2).
The paging sets the number of rows to 10 per page by default, but when a user fills out the fields and clicks between the 3 pages, any previous fields they entered are emptied.
I tried setting the count for the Pager module and/or the Table module to 30 but it seems to be overridden by results.count which is upstream. I understand this is expected behavior, however I would like to force it to be greater than 10 to allow the users to fill out all fields in one page, could you please advise where is the best place in the xml to do so?
Thanks in advance,
Luke 🙂
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.
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.
Thanks Nick! I removed the Pager module and added the ValueSetter as recommended 🙂