Ability to test executing a connector on update

[mikecote]

This issue is for the "Test button when creating a connector" portion of #49372

The problem this issue is trying to solve is that the feedback loop from Create a Connector through to Discover Connector is Broken is very long.

To shorten this feedback loop we'll do the following:
In the Connectors List we'll add a Test button on each Connector in the list which, when clicked, will display a flyout with the Action form for that Connector. This form, the same form that appears in the Create/Edit Alert flyout, can then be filled out and when completed (using a Test or Execute button) the action will be executed and its output displayed to the user in the flyout.
Hopefully the output will confirm the action ran successfully, but if it fails, it will display as detailed an error message as we can in order to help the user debug the issue affecting the Connector's operation.

This approach will allow us to address the need without requiring any new APIs, as the existing execute api should suffice.

Original Description

Test button when creating a connector

• You will have to save the connector settings first, then a test button will appear
• The test button will work in the same way as when creating an alert:
  • sample/dummy values will be used to fill any missing parameters
  • a preview will be shown
  • from the preview, the action can be executed

Some additional comments in other issue:

@mikecote
A note that these executions should probably be audit logged as well.

@mikecote
I'm thinking a new API would be needed for this. The API would take config, secrets, params and execute it. This will handle the scenario of testing the configuration before creating a connector.

We can consider splitting the issue and defer Test button when creating an alert use case for now.

In regards to the new API, it would be an alternative to displaying the test button after saving the connector.

In regards to "creating a connector" I think the same should apply for update.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[mikecote]

@pmuellr there was some talk about the test button sending fixed data directly without displaying a form. I was thinking yesterday how that would work for JIRA where some user input may be required? I'm guessing re-using the action params form used by the alert shouldn't be too hard and we can display sample/dummy data within it where possible as mentioned above 🤔

[pmuellr]

Ya, we certainly need to provide some data. In some cases, we can generate all the data ourselves, eg server log. In other cases, we clearly can't, eg email (a to: address). For the case of "test an action within an alert", we will likely have most of the data, except what's provided by mustache alerts, vs the case of "test an action from the actions UI", we won't have any data to test with and would have to prompt.

I'm guessing that in many cases, we will have enough data in the alert action params to test without prompting the user for more data, but the edge cases would be if they are getting an email address for the to param via the context or such, which seems unlikely right now.

[mikecote]

++ makes total sense. It now seems best to provide the form. The sample/dummy values can be added where it makes sense as an optional feature.

[gmmorris]

I've updated the description to reflect our current thinking regarding this issue.
The research might lead us in another direction, but for now it feels like the "Action form + Api" approach will best address this need.