Getting Data In

Why are text input fields unexpectedly blank in custom alert action UI?

snargleplax
Explorer

I am developing an add-on that adds a custom alert action. I've built a custom HTML fragment (as described in the custom alert UI docs), and it mostly operates as expected, but for one major issue: despite the fact that my HTML specifies default values for the input fields, the fields appear blank.

So, for example, I've got an input like this:

<input type="text" name="action.myapp.param.some_param" id="some_param" value="Default text I expect to see">

When I bring up the UI, the text box appears, but is blank. Inspecting the DOM reveals that the value attribute is indeed on the <input> element as expected, but the text just isn't showing up. I'm not sure if some bit of JavaScript I can't find is clearing it out or what, but this behavior seems incorrect.

The same problem affects <textarea> inputs, which fail to show the text occurring between <textarea> tags as expected.

I looked through all the other apps and add-ons on Splunkbase that provide custom alert actions, and none of them have HTML that specifies a value for a text input or textarea, so I guess either I'm the first one to hit this issue or others have worked around it.

The problem only affects the default values I wish to present. Once I actually enter text into the form and save it, it round-trips just fine. Well, almost; when I open the alert again after editing it, the text input fields do display the values I had saved. However, inspecting the DOM still shows the original default values in the HTML. I guess what's going on is that it's simply ignoring the value attribute (and its equivalent for <textarea>), and clobbering it with whatever's saved. In the case where the "saved" values are in fact empty (the first time the form is displayed), we get the problem I've described. I'd love to see this fixed, unless someone can explain to me how the current behavior is correct.

0 Karma
1 Solution

ziegfried
Influencer

The value of the form input is essentially managed by the data-binding layer of the alert-actions dialog, which responsible of applying the current settings to the HTML form when you're editing an existing alert. So supplying the value attribute won't have any effect.

I'd suggest specifying your default value into your stanza in alert_actions.conf

[my_action]
...
param.myparam = my default value

View solution in original post

kartik13
Communicator

Have corresponding token against your input . And set the default value of token to whatever you want to have .You need to know the concepts of data-binding in Splunk to achieve this. which is done by tokens in Splunk.

0 Karma

snargleplax
Explorer

I've spent a good part of today reviewing those docs and trying to get something to work here, but with little traction. Are you sure this is possible for a custom alert action UI, as opposed to a dashboard or something? For custom alert actions, we only provide an HTML snippet rather than a full document. When I add <script> tags outside the existing <form> tag, the UI breaks (nothing shows up).

I looked through all the add-ons and apps I could find that provide custom alert actions, and didn't find any examples of this. Am I failing to understand, or is what you describe not possible in this context?

0 Karma

ziegfried
Influencer

The value of the form input is essentially managed by the data-binding layer of the alert-actions dialog, which responsible of applying the current settings to the HTML form when you're editing an existing alert. So supplying the value attribute won't have any effect.

I'd suggest specifying your default value into your stanza in alert_actions.conf

[my_action]
...
param.myparam = my default value

snargleplax
Explorer

My default value does (also) occur in alert_actions.conf, but I don't see it getting populated in the UI based on that. What would you say needs to be in my HTML for that to occur?

0 Karma

ziegfried
Influencer

Are you sure the param name matches on both sides? param.myparam in alert_actions.conf would correspond to <input name="action.my_action.param.myparam"> in the HTML. Also make sure the alert action configuration is exported via metadata/default.meta.

0 Karma

snargleplax
Explorer

That did the trick as far as making the config value appear (discovered this yesterday, but thanks for confirming), and values I enter still round-trip properly. Unfortunately, I'm still not able to get the behavior I want in terms of providing a default value. I can see why the data binding does what it does, to populate the previously-configured value; and that's why having the param name be the same works -- but it feels like a hack to name my default value config key the same as what it's a default for. The problem with this hack comes to the surface when I configure a new default, because that default then propagates to all existing alerts. I think it would work how I want if it would actually respect the value attribute in the case when the param is absent, but that's not how it works. Anyway, thanks.

0 Karma

frobinson_splun
Splunk Employee
Splunk Employee

Hi @snargleplax,
Have you tried using "placeholder" instead of "value"?

The markup should be consistent with Bootstrap version 2.3.2:
http://getbootstrap.com/2.3.2/base-css.html?#forms

as mentioned here:
http://docs.splunk.com/Documentation/Splunk/6.3.3/AdvancedDev/CustomAlertUI

As an example, here's a snippet of an HTML file:
input type="text" name="action.hipchat.param.auth_token" id="hipchat_auth_token" placeholder="Optional"

from
http://docs.splunk.com/Documentation/Splunk/6.3.3/AdvancedDev/ModAlertsAdvancedExample#HTML_file_for...

Hope this helps!

0 Karma

snargleplax
Explorer

Odd, I thought I already responded to this. Oh well, here it is again.

Yes, using "placeholder" is what I've had to fall back on as a workaround, but it's not really the same thing as filling in the actual value. The UX is inferior with a placeholder, because:

  1. The user has to type the text in by hand.
  2. As soon as the user starts typing, the placeholder text isn't even visible for reference.
  3. They can't copy/paste it either.

There seems to be at least one other significant problem (bug, I would say) closely related to this behavior (see answer #386595), so I really think it deserves a look.

I've perused the links you provided (having mostly already done so), but find nothing helpful. I don't imagine there's anything about my expectation here that's out of line with Bootstrap's needs, is there?

0 Karma

frobinson_splun
Splunk Employee
Splunk Employee

Thanks for your notes, @snargleplax,
I've passed along your posts to our engineering team to investigate.

0 Karma

snargleplax
Explorer

Awesome, much appreciated.

0 Karma
Get Updates on the Splunk Community!

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

What's new in Splunk Cloud Platform 9.1.2312?

Hi Splunky people! We are excited to share the newest updates in Splunk Cloud Platform 9.1.2312! Analysts can ...

What’s New in Splunk Security Essentials 3.8.0?

Splunk Security Essentials (SSE) is an app that can amplify the power of your existing Splunk Cloud Platform, ...