All Apps and Add-ons

Correct syntax to default select first row in top SideView table to drilldown to second SideView table?

barrymcintosh
Engager

I have a view where I drill down on one field from a SideView table to a second SideView table on the same view. The top table returns just one row, but a user must click on that row before the second table can pickup the field from the first table (index=email size>5000 sender=$row.fields.Email$...). I found a earlier post with a similar issue where the answer was to set the 1st row in the top table as default selected, but I can not figure out the syntax to default select the first row in the top SideView table. I tried the parameter for the top table shown below but it does not work. What is the correct syntax?

0

1 Solution

sideview
SplunkTrust
SplunkTrust

An excellent question.

This is kind of pretentious but let's break it into four problems. It will help me give a full answer.

A) Dont Block: You want the Table to not do its normal behavior where it blocks downstream pushes until the user clicks a row. Instead the Table should just allow the push, for instance so that all downstream modules appear on load.

B) Set Defaults: You want the Table to provide $row.fields.foo$ values downstream that reflect appropriate defaults.

C) Look Selected: You want the Table row that has these defaults to appear selected.

D) Select the first row or the Nth row: As an alternative to B, you want to just set some selectedIndex to "0" and have it select the first row.

The problem is that there's no way to do C or D right now. Secondary problem is that while D can kinda be done, it's extremely convoluted.

1) Using just Table to get A and B --
If the field is called "foo", then to set the field "foo" to have the default value of 12, and thus to allow the Table's downstream modules to run/load/show-themselves, you would do:

<param name="default.foo">12</param>

and then the Table would output a key of $row.fields.foo$ with the value 12.

Granted... to always select the first row, we'd have to know in advance what the values of the first table were. But anyway if you want to set defaults for more than just that one row you can set multiple default params like so:

<param name="default.foo">12</param>
<param name="default.user">mildred</param>

1) Using ResultsValueSetter?

To literally always get the first row selected no matter what the values are, technically there is a convoluted way to use ResultsValueSetter to do this, but it involves a PostProcess module, a ResultsValueSetter and then another PostProcess, all before the Table. And we still wont get "C", ie the Table row still wont look selected. =/ (the postProcess complexity is because we'd have to rename the fields with this silliness: | rename foo as "row.fields.foo"

But RVS wouldn't help us with A so either we'd have to give the Table a <param name="default.nonexistentField">foo</param>, or dive into the sorcery of the Gate module.
Sorcery is cool but you'll probably burn off your eyebrows and b) the table row still wouldn't look selected. =\

So to make a long story short.... I think I should add some new functionality to the Table.

PROPOSED:
The Table module's "name" param defaults to "row", but let's say in general you have a Table module whose "name" param is "selectedHostRow". The new functionality could be that if the Table receives an upstream token of the form $selectedHostRow.selectedIndex$, that it will select that row, and you get all of A, B and C!

Also, I need to make a small improvement to the Table module's existing default.* params dictate that there is an existing rendered row that matches the default values, that the given row should be rendered in the selection colors.

View solution in original post

sideview
SplunkTrust
SplunkTrust

An excellent question.

This is kind of pretentious but let's break it into four problems. It will help me give a full answer.

A) Dont Block: You want the Table to not do its normal behavior where it blocks downstream pushes until the user clicks a row. Instead the Table should just allow the push, for instance so that all downstream modules appear on load.

B) Set Defaults: You want the Table to provide $row.fields.foo$ values downstream that reflect appropriate defaults.

C) Look Selected: You want the Table row that has these defaults to appear selected.

D) Select the first row or the Nth row: As an alternative to B, you want to just set some selectedIndex to "0" and have it select the first row.

The problem is that there's no way to do C or D right now. Secondary problem is that while D can kinda be done, it's extremely convoluted.

1) Using just Table to get A and B --
If the field is called "foo", then to set the field "foo" to have the default value of 12, and thus to allow the Table's downstream modules to run/load/show-themselves, you would do:

<param name="default.foo">12</param>

and then the Table would output a key of $row.fields.foo$ with the value 12.

Granted... to always select the first row, we'd have to know in advance what the values of the first table were. But anyway if you want to set defaults for more than just that one row you can set multiple default params like so:

<param name="default.foo">12</param>
<param name="default.user">mildred</param>

1) Using ResultsValueSetter?

To literally always get the first row selected no matter what the values are, technically there is a convoluted way to use ResultsValueSetter to do this, but it involves a PostProcess module, a ResultsValueSetter and then another PostProcess, all before the Table. And we still wont get "C", ie the Table row still wont look selected. =/ (the postProcess complexity is because we'd have to rename the fields with this silliness: | rename foo as "row.fields.foo"

But RVS wouldn't help us with A so either we'd have to give the Table a <param name="default.nonexistentField">foo</param>, or dive into the sorcery of the Gate module.
Sorcery is cool but you'll probably burn off your eyebrows and b) the table row still wouldn't look selected. =\

So to make a long story short.... I think I should add some new functionality to the Table.

PROPOSED:
The Table module's "name" param defaults to "row", but let's say in general you have a Table module whose "name" param is "selectedHostRow". The new functionality could be that if the Table receives an upstream token of the form $selectedHostRow.selectedIndex$, that it will select that row, and you get all of A, B and C!

Also, I need to make a small improvement to the Table module's existing default.* params dictate that there is an existing rendered row that matches the default values, that the given row should be rendered in the selection colors.

elliptic1
New Member

Any update on this answer since it's 6 years old?

0 Karma

barrymcintosh
Engager

I like the proposed enhancement, thank you for the very detailed explanation of how the table and modifiers function. I understand tables much better now. I may still try the 3 step PostProcess and ResultsValueSetter solution you suggested

0 Karma

martin_mueller
SplunkTrust
SplunkTrust

I second that proposal!

0 Karma

sideview
SplunkTrust
SplunkTrust

Good question, and my original answer failed to answer the question's real flavor of "I want to have the first row selected, not necessarily knowing what its values are". So I've updated my answer.

0 Karma

martin_mueller
SplunkTrust
SplunkTrust

Is there a simple way to select whatever value is in the first row without using ResultsValueSetter, preferably while showing the first row as selected in the UI as well?

0 Karma

martin_mueller
SplunkTrust
SplunkTrust

Have you tried this ResultsValueSetter approach? Not sure if the bug mentioned there has been fixed or not though. http://answers.splunk.com/answers/113759/sideview-utils-automatically-drilldown-on-first-row-in-tabl...

0 Karma
Get Updates on the Splunk Community!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

March 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...