Open pmuellr opened 3 years ago
Pinging @elastic/kibana-alerting-services (Team:Alerting Services)
I was unable to find a Swimlane issue / PR where we had mentioned this before, so will need to do some research on the exact needs.
I believe the story is similar to the ServiceNow one though - today, we can do this "additional work" in the alerting UI, and prevent the Save from occurring if we need to, by customizing the UI. But we can't do this if the connector is being created by the HTTP API. IIRC, for Swimlane, we needed to get some field mappings from the Swimlane service.
Hi @pmuellr. That is correct. We need to get some field mappings from the Swimlane service in the UI so the user can configure the connector.
The connector's configuration has two steps: a) instance configuration b) mappings configuration. The user has to first fill in the username and password and then go to the second step. In the second step, the minimum requirement is to select the connector type. The problem is that the user could press Save
without going to the second step. To bypass this problem, we made an assumption and set the connector type to a default of our choice. It would be nice to have the create hook and return a message to the user about the mapping configuration (instead of a schema error).
Also, based on the connector type some of the fields in the mapping are required. Having that hook would enable us to do that kind of validation if someone tries to use the API directly.
Swimlane PR: https://github.com/elastic/kibana/pull/100086
Currently, alerting connector types are only invoked to execute the connector. We've had some scenarios where it would be useful to allow connectors to provide some feedback during create. Specifically, to do some checking against 3rd party services (Swimlane and ServiceNow), and be able to "veto" the creation. Think of it as an additional validation, that's done at the time of the create, given the connector parameters.
One way to view this is just as an additional type of validation, where the connector type could register to have this additional validation run on the create. Another way to think about it is a general "hook" mechanism, where the connector type can be invoked on interesting calls (create/update/delete), and "provide feedback", where one form of that feedback would be to not allow the creation, and presumably provide an error message.
The "additional validation" approach is likely easier, but also less flexible, if we find we need to do other "interesting" things later.
This is also possibly something we'd want for rules, as well as connectors.