[Alerting UI] Positioning of the action groups in the Alert flyout

[YulNaumenko]

Current UI requires from the user to create the action first and then decide when it should run (select an action group to which the action belongs).
There are some difficulties to apply this approach for some use cases. For example, in the flow for geo-threshold alert it doesn't fit with the conditions context. The problem is that without adding the action, user doesn't have the idea about possible options.
cc @aaronjcaldwell , @mdefazio

[elasticmachine]

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

[pmuellr]

Ya, it seems like if an alert has > 1 action group (not counting the built-in recovered action group), we really should be prompting for the action group before asking for which action to add. If an alert only has 1 action group, then there's no real choice for the user. I believe the geo alert is the first alert to use multiple action groups, but I'd guess we'd see the same sort of issue for other alerts with multiple action groups.

I specifically called out not including the built-in recovered action group when counting the action groups, since it seems unlikely you would want to add an action ONLY when it's recovered. And we have an issue open to see if we can make it easier for customers to get recovered action group actions added, compared to the current behavior, at least for some actions.

[mdefazio]

This is a first shot at placement for this checkbox. It felt like it belonged near the Event action option, and I'm putting it on it's own line in case we have to explain what this is a bit further (and also should help with layout flow)

I think this gets more difficult when we try to apply it broader than PagerDuty. So for now, I think this is just for that connector's form.

Admittedly I am not super versed in PagerDuty. So perhaps @arisonl or someone can walk through some of the other scenarios in PagerDuty to make sure this is right?

[arisonl]

Couple of questions:

• How does it interact with the Event Action option and the Run when action UX?
  • When is it visible? For example: Should it only become available when Run when is Active and Event Action is triggered?
  • What happens if a user selects Auto-resolve and also adds a Run when Recovered? Is there the possibility of a logical "conflict"? We should guard against technical conflicts at least. For example erroring when attempting to resolve an incident by adding Run when when it is already resolved by the Auto-resolve option
• The Summary and the rest of the fields are currently void for the resolution event (they do not get passed along to PD). Is this correct? If we want to keep it like this, the they should be removed. Do we want to remove them or do we want to maintain some as optional (e.g. the Summary)?
• What is the default value? Checked or not? I would argue not checked but at the same time to make it more prominent perhaps by making it more descriptive. E.g. "Auto-resolve incident when the alert recovers" or similar in place of the "Additional description need for this?" hint?

[mdefazio]

Realized I posted to the wrong issue. Posted 2nd version of mockup here: #89166