[ResponseOps][Rules] Use rule form instead of rule flyout in observability solution

[js-jankisalvi]

Summary

Resolves #195574

This PR updates observability solution to use new rule form to create and edit rules same as stack management > rules page.
It removes usage of rule flyout form o11y solution. Also updated functional tests.

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

How to test

• Create a rule in o11y, verify it works as expected
• Edit rule in o11y via different options (from rule details page, rule list table, alert details page etc.) verify it works as expected
• Verify the same in serverless o11y project

Release Note

Use rule form to create or edit rules in observability.

[elasticmachine]

Pinging @elastic/response-ops (Team:ResponseOps)

[elasticmachine]

Pinging @elastic/obs-ux-management-team (Team:obs-ux-management)

[github-actions]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

• /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
• run docs-build : Re-trigger the docs validation. (use unformatted text in the comment!)

[maryam-saeidi]

Thanks for making this change 🙏🏻

I haven't finished the review, just an early feedback:

1. When editing the rule in observability, there is an extra Edit title, can we remove that?

   Observability	Stack manegemnt

2. When clicking on the breadcrumb to navigate to Rules, in observability, it will refresh the whole page as shown below:

   Screen.Recording.2025-01-22.at.10.05.27.mov

[js-jankisalvi]

1. When editing the rule in observability, there is an extra Edit title, can we remove that?
2. When clicking on the breadcrumb to navigate to Rules, in observability, it will refresh the whole page as shown below:

Fixed both issues in 134313d

breadcrumb_obs.mov

[adcoelho]

Why this change?

[js-jankisalvi]

This is because validConsumers of o11y solution always has AlertConsumers.OBSERVABILITY, however we don't want it for some rules like (custom threshold, esql etc.) which have other consumers like logs, metrics etc.
However if it is serverless, we want all rules to have AlertConsumers.OBSERVABILITY consumer.

[maryam-saeidi]

Just to add the decision here: (based on discussion with @maciejforcone)
We decided to only have the rule form in the rule creation flow on the rules page. We will keep the flyout for other scenarios (i.e., edit and rule creation on the app pages.)

[shahzad31]

Just to add the decision here: (based on discussion with @maciejforcone) We decided to only have the rule form in the rule creation flow on the rules page. We will keep the flyout for other scenarios (i.e., edit and rule creation on the app pages.)

@maryam-saeidi that sounds logical, but i think we should make those flyouts at least resizeable, i think the actual place like expression and graphs on the flyout is usually very congested, either we can increase the size or make the fields above expression compressed to give maximum space to the content which matters on flyouts. I think purpose of this initiative was to address these things but if we still kept those as flyouts, it kinda defeats the purpose.

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 0113eec
• Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-206774-0113eec316d0

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
observability	1150	1269	+119

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
observability	482.1KB	1.3MB	⚠️ +814.8KB
triggersActionsUi	1.7MB	1.7MB	+171.0B
total			+815.0KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
observability	101.9KB	102.0KB	+128.0B

Unknown metric groups

async chunk count

id	before	after	diff
observability	20	21	+1

miscellaneous assets size

id	before	after	diff
observability	888.1KB	1.2MB	⚠️ +379.0KB

History

• 💚 Build #269212 succeeded 134313d
• 💚 Build #268619 succeeded 11dec7e
• 💛 Build #268559 was flaky 81b1651
• 💔 Build #268492 failed 0884e30
• 💔 Build #268406 failed b5c7596

cc @js-jankisalvi

[maryam-saeidi]

@maryam-saeidi that sounds logical, but i think we should make those flyouts at least resizeable, i think the actual place like expression and graphs on the flyout is usually very congested, either we can increase the size or make the fields above expression compressed to give maximum space to the content which matters on flyouts. I think purpose of this initiative was to address these things but if we still kept those as flyouts, it kinda defeats the purpose.

Good point. The plan is to have the option to resize the flyout but in a different step. @cnasikas shared that this option will be easier to add when @Zacqary 's work on the rule form is finished (I believe it is related to this PR)