[Response Ops] [Rule Form] Add Rule Form Flyout v2

[Zacqary]

Summary

Part of #195211

Replaces the create/edit rule flyout with the new rule flyout

Restores the confirmation prompt before canceling or saving a rule without actions defined.

Also fixes most of the design papercuts in the Actions step:

Checklist

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios

[Zacqary]

@elastic/kibana-design This PR is still in draft but could use some feedback on these two design elements as they weren't in the Figma:

I'm particularly unsure about the confirmation screen, it's definitely Not A Flyout Opening A Modal™ but it's also a ton of blank space

[MichaelMarcialis]

@elastic/kibana-design This PR is still in draft but could use some feedback on these two design elements as they weren't in the Figma:

Hey, @Zacqary. I'm not certain who the designer was on this, so I'll defer to them if they disagree with any of the following opinions. That said, I'd suggest the following:

Discard changes screenshot

You made mention of not triggering the confirmation modal from the flyout. Is there a compelling reason not to do so? Personally, I'm wondering if it might be a more common/familiar pattern to open a confirmation modal instead of repurposing the content area of the flyout. It'll also be more forgiving for short messages such as this.

No actions configured screenshot

Since it's allowed, I'm wondering if we should change the color="warning" prop on the EuiCallout to the default primary color, to avoid scaring folks. If it's truly just an informational message and not a warning (i.e. nothing is going awry), then we should style it as such. You'll likely also want to change or remove the icon as well.

Additionally, since the message is most relevant at the moment the user leaves the "Actions" step and moves to the "Details" step, perhaps it would make sense to move the callout up towards the top of the flyout (just below the header).

[Zacqary]

Additionally, since the message is most relevant at the moment the user leaves the "Actions" step and moves to the "Details" step, perhaps it would make sense to move the callout up towards the top of the flyout (just below the header).

The reason I put the callout on the footer is because it's replacing something the full page Rule Form shows as a confirmation popup. It's a message that we're usually displaying to the user right as they're making the decision to save the rule.

I'm happy to move the callout to the top of the screen, but if flyouts are allowed to open confirmation modals I could also just have it pop up the same modal as the rule page instead.

[joana-cps]

Thanks, @MichaelMarcialis for your comment and thoughts. I forgot to add these screens on Figma and missed the notification for the PR review. @Zacqary is now aware that I'm the one responsible for this area.

Discard changes screenshot
Regarding modals and flyouts I agree with avoiding it when we're talking about modals in the middle of a flyout flow, like the action connector and show request for example. Since this is a validation, the most common pattern around kibana is just a simple confirmation modal. The only thing that we need to be aware of is adding the background so the user can only interact with the confirmation modal.

This behavior is already in use if you create/edit a Rule from Observability:

No actions configured screenshot
Let's use the same modal that we use on the Rule page for consistency. We already show that actions are optional in the actions step, this is just a confirmation modal.

[Zacqary]

@cnasikas

* We pass the `onChangeMetaData` prop around the rule form to do

useEffect(() => {
    if (!isEmpty(metadata)) {
      onChangeMetaData(metadata);
    }
  }, [metadata, onChangeMetaData]);

Why do we need that? The initialMetaData already has that information. It seems that we needed it here: src/platform/plugins/shared/discover/public/application/main/components/top_nav/app_menu_actions/get_alerts.tsx. How are the metadata being used? Could we pass the metadata to the onClose or onSubmit as before and avoid this pattern?

@elastic/kibana-data-discovery Is this something simple enough to refactor in this PR or do we need to make it a follow-up issue?

[Zacqary]

I noticed that when I edit a rule in o11y it uses the old flyout and not the new one.

Fixed in 314d14c

[awahab07]

obs-ux-logs changes LGTM!

Only reviewed CODEOWNERS files. Also tested the create rule flow from Discover.

[jughosta]

Data Discovery changes LGTM 👍

Would be great to avoid the validation error showing up during the opening of the flyout:

[elasticmachine]

💔 Build Failed

• Buildkite Build
• Commit: 78cf8db

Failed CI Steps

• Check Types

History

• 💔 Build #278582 failed 9e3d7e9
• 💔 Build #278571 failed fd7e080
• 💔 Build #278532 failed 6e765ec
• 💛 Build #278148 was flaky f4aff0f
• 💔 Build #277890 failed 30b89de