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
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.
Have you tried using "placeholder" instead of "value"?
The markup should be consistent with Bootstrap version 2.3.2:
as mentioned here:
As an example, here's a snippet of an HTML file:
input type="text" name="action.hipchat.param.authtoken" id="hipchatauth_token" placeholder="Optional"
Hope this helps!
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:
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?
Thanks for your notes, @snargleplax,
I've passed along your posts to our engineering team to investigate.
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
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?
Are you sure the param name matches on both sides?
param.myparam in alertactions.conf would correspond to `<input name="action.myaction.param.myparam">` in the HTML. Also make sure the alert action configuration is exported via metadata/default.meta.
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.
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.