All Apps and Add-ons

Trouble passing individual tokens in pulldowns

McDonaldPa08
Explorer

I am attempting to embed a pulldown menu into every row of a table in order to allow for follow-on actions for a specific field. The search and resulting table outputs "ip" (the field I am interested in) and "domain," but I cannot get the pulldown to populate with those values. My desired output would look like this for a given row:

















ip domain actions
8.8.8.8 google.com Action 1 for 8.8.8.8
Action 2 for 8.8.8.8
Action 3 for 8.8.8.8
192.168.1.1 localhost Action 1 for 192.168.1.1
Action 2 for 192.168.1.1
Action 3 for 192.168.1.1


I feel like this should be pretty straightforward, however, the pulldown module (which is downstream) is not passing the $row.fields.ip$ token and instead outputs looks like this:

















ip domain actions
8.8.8.8 google.com Action 1 for $row.fields.ip$
Action 2 for $row.fields.ip$
Action 3 for $row.fields.ip$
192.168.1.1 localhost Action 1 for $row.fields.ip$
Action 2 for $row.fields.ip$
Action 3 for $row.fields.ip$

The XML for my dashboard looks like so:

<module name="Search" layoutPanel="panel_row3_col1" autoRun="True">
   <param name="search">
    index=ioc_sample | stats count by ip | eval actions="PLACEHOLDER" | fields ip,domain,actions
  </param>
  <param name="earliest">0</param>
  <param name="latest">now</param>
  <module name="Pager">
    <param name="count">5</param>
    <module name="Table">
      <module name="Pulldown" group="row.fields.actions">
        <param name="staticOptions">
          <list>
            <param name="label">Additional Actions</param>
            <param name="value">*</param>
            <param name="selected">True</param>
          </list>
          <list>
            <param name="value">$row.fields.ip$</param>
            <param name="label">Action 1 for $row.fields.ip$</param>
          </list>
          <list>
            <param name="value">$row.fields.ip$</param>
            <param name="label">Action 2 for $row.fields.ip$</param>
          </list>
        </param>
      </module>
    </module>
  </module>
</module>

The modules flow downstream correctly, and I can pass tokens correctly in other modules embedded within the pulldown module so I do not know where things are breaking. Ideas?

1 Solution

sideview
SplunkTrust
SplunkTrust

The problem is that the Pulldown module does not allow $foo$ substitution into staticOptions. It's often said that in Sideview modules "almost every param" accepts $foo$ tokens. Well, this is one of the few remaining gaps. 😃

Outside of Table embedding this specific gap doesn't come up very often, or at least over the years only one other customer has emailed me about it. As it happens though it's in my queue and it's slated for a somewhat near term fix.

In the meantime I can offer a couple workarounds.

1) Sometimes you can distill the $foo$ token substitution out of staticOptions and into a ValueSetter that lives downstream of the Pulldown. How easy or tricky this is depends a lot on what exactly your actions are.... Here that's not a complete workaround because you clearly want to display the field values in the pulldown labels. So that's out.

2) a trick from the vast and strange world of "postprocess hackery". Although in principle they are static options, we can render them as dynamic ones... =/ This is clunky and takes a lot of getting used to, but it'll work.

      <module name="Pulldown" group="row.fields.actions">
        <param name="valueField">value</param>
        <param name="labelField">label</param>
        <param name="postProcess">
          search ip="$row.fields.ip$" | eval label=split("Action 1 for " + ip + ",Action 2 for " + ip,",") | mvexpand label | rename ip as value</param>

        <param name="staticOptions">
          <list>
            <param name="label">Additional Actions</param>
            <param name="value">*</param>
            <param name="selected">True</param>
          </list>
        </param>
        ...
      </module>

And there are many permutations that follow this basic idea - using postprocess to create an artificial results set that is used only to render your options.

3) Wait for staticOptions to support $foo$ substitutions. Nag that Sideview guy as necessary.

4) Beyond this there is the world of customBehavior. If you have read through all the Sideview Utils docs and living examples, and you've never heard of customBehavior, that's because it's very well hidden. Go to "Tools > Other Tools", and scroll down to the last panel on that page. It will give you a link to the CustomBehavior docs page. I should make it make that little secret-tunnel noise from super mario brothers one day. CustomBehavior is always a last resort, because nobody likes to write or maintain UI in javascript. Life is too short and UI requirements change too much. But, if you were going to go this way, I would say give the Pulldown a postprocess of "| stats count", and then override hte implementation of the Pulldown's buildOptionListFromResults method. Normally that method takes a jsonStr as an argument, which jsonStr is the result set. However you can write your own method that ignores that jsonStr and renders whatever options you need...

Slightly better, less code and with less surface area for breakage, would be to preserve a methodReference to the base buildOptionListFromResults method, override it to then pass a JSON literal (your labels and values), to the methodReference. If you have no idea what I'm talking about, this is NOT for you and I'm afraid you should reexamine #1 and #2.

View solution in original post

sideview
SplunkTrust
SplunkTrust

The problem is that the Pulldown module does not allow $foo$ substitution into staticOptions. It's often said that in Sideview modules "almost every param" accepts $foo$ tokens. Well, this is one of the few remaining gaps. 😃

Outside of Table embedding this specific gap doesn't come up very often, or at least over the years only one other customer has emailed me about it. As it happens though it's in my queue and it's slated for a somewhat near term fix.

In the meantime I can offer a couple workarounds.

1) Sometimes you can distill the $foo$ token substitution out of staticOptions and into a ValueSetter that lives downstream of the Pulldown. How easy or tricky this is depends a lot on what exactly your actions are.... Here that's not a complete workaround because you clearly want to display the field values in the pulldown labels. So that's out.

2) a trick from the vast and strange world of "postprocess hackery". Although in principle they are static options, we can render them as dynamic ones... =/ This is clunky and takes a lot of getting used to, but it'll work.

      <module name="Pulldown" group="row.fields.actions">
        <param name="valueField">value</param>
        <param name="labelField">label</param>
        <param name="postProcess">
          search ip="$row.fields.ip$" | eval label=split("Action 1 for " + ip + ",Action 2 for " + ip,",") | mvexpand label | rename ip as value</param>

        <param name="staticOptions">
          <list>
            <param name="label">Additional Actions</param>
            <param name="value">*</param>
            <param name="selected">True</param>
          </list>
        </param>
        ...
      </module>

And there are many permutations that follow this basic idea - using postprocess to create an artificial results set that is used only to render your options.

3) Wait for staticOptions to support $foo$ substitutions. Nag that Sideview guy as necessary.

4) Beyond this there is the world of customBehavior. If you have read through all the Sideview Utils docs and living examples, and you've never heard of customBehavior, that's because it's very well hidden. Go to "Tools > Other Tools", and scroll down to the last panel on that page. It will give you a link to the CustomBehavior docs page. I should make it make that little secret-tunnel noise from super mario brothers one day. CustomBehavior is always a last resort, because nobody likes to write or maintain UI in javascript. Life is too short and UI requirements change too much. But, if you were going to go this way, I would say give the Pulldown a postprocess of "| stats count", and then override hte implementation of the Pulldown's buildOptionListFromResults method. Normally that method takes a jsonStr as an argument, which jsonStr is the result set. However you can write your own method that ignores that jsonStr and renders whatever options you need...

Slightly better, less code and with less surface area for breakage, would be to preserve a methodReference to the base buildOptionListFromResults method, override it to then pass a JSON literal (your labels and values), to the methodReference. If you have no idea what I'm talking about, this is NOT for you and I'm afraid you should reexamine #1 and #2.

McDonaldPa08
Explorer

Thanks a lot, Nick; you are a magician. I will start with the postprocess quick fix you mentioned and improve from there.

0 Karma

McDonaldPa08
Explorer

Sorry for the deletions yesterday, Nick. I was having major formatting issues.

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