[ResponseOps][Rules] Use the new rule form to the create rules flyout #195211

cnasikas · 2024-10-07T10:05:58Z

In #175634 we implemented the new rule form. We should use the new rule form on the create rules flyout.

Designs: https://www.figma.com/design/zetHXnUP0YnDG4YmvPwRb8/Adapt-new-Rule-form-to-work-in-flyout?node-id=1-191&node-type=canvas&t=PyPLu7smPOf1cqj9-0

DoD

Give feedback

Create a package called @kbn/response-ops-rule-form under packages/response-ops and move all the code related to the rule form from the @kbn/alerts-ui-shared. Types or code used in other places should not be moved and can be imported by the @kbn/alerts-ui-shared package. ([ResponseOps][Rules] Move Rule Form code into @kbn/response-ops-rule-form #198725)
Export the new flyout following the designs where it can be used to create rules using the new rule form. ([ResponseOps] [Rule Form] Move rule form steps to hook with progress tracking #205944, [Response Ops] [Rule Form] Add new flyout to rule form library, responsive design and illustration to rule form page #206141, [Response Ops] [Rule Form] Add Show Request and Add Action screens to flyout #206154)
Replace the old flyout with the new one whenever is being used. ([Response Ops] [Rule Form] Add Rule Form Flyout v2 #206685)
Remove the old flyout from the triggers_actions_ui plugin along with all related code. [Response Ops] [Rule Form] Remove V1 Rule Form Flyout #209171
Options

The text was updated successfully, but these errors were encountered:

elasticmachine · 2024-10-07T10:06:01Z

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

Zacqary · 2024-10-24T14:42:47Z

Working on new package task in an initial PR

Lots of code to move and reroute, might be a big job

cnasikas · 2024-10-25T09:52:55Z

Thanks @Zacqary! No worries. Plz move code relevant to the form. Any types,hooks, etc that are being used either by the @kbn/alerts-ui-shared or triggers_actions_ui or any solution should remain in @kbn/alerts-ui-shared and the new package can import from the @kbn/alerts-ui-shared whatever it needs.

…form (#198725) ## Summary Part of #195211 Moves Rule Form code out of `@kbn/alerts-ui-shared` and into a new package called `@kbn/response-ops-rule-form`. Some types and hooks that are used by multiple features or solutions are still in `@kbn/alerts-ui-shared` and have been rerouted. The bulk of Rule Form-specific code is in this new package. ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Kevin Delemme <[email protected]>

…-rule-form (#198725) (#202907) # Backport This will backport the following commits from `main` to `8.x`: - [[ResponseOps][Rules] Move Rule Form code into @kbn/response-ops-rule-form (#198725)](#198725)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport)  Co-authored-by: Christos Nasikas <[email protected]>

…form (elastic#198725) ## Summary Part of elastic#195211 Moves Rule Form code out of `@kbn/alerts-ui-shared` and into a new package called `@kbn/response-ops-rule-form`. Some types and hooks that are used by multiple features or solutions are still in `@kbn/alerts-ui-shared` and have been rerouted. The bulk of Rule Form-specific code is in this new package. ### Checklist - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: kibanamachine <[email protected]> Co-authored-by: Kevin Delemme <[email protected]>

…tracking (#205944) ## Summary Part of #195211 In preparation for the horizontal rule form layout, move the generation of the rule form steps into three hooks: - `useCommonRuleFormSteps`: private hook that generates a series of objects specifying the rule form steps, how to display them, and what order to display them in - `useRuleFormSteps`: hook that calls `useCommonRuleFormSteps` and transforms them into data for the standard vertical `EuiSteps`, along with progress tracking based on `onBlur` events - `useRuleFormHorizontalSteps`: hook that calls hook that calls `useCommonRuleFormSteps` and transforms them into data for `EuiStepsHorizontal`, plus navigation functions. ***These will be used in the smaller rule form flyout in a second PR*** Because `EuiStepsHorizontal` rely more heavily on the `EuiSteps` `status` property, I took this opportunity to improve progress tracking in the standard vertical steps. Most rule types will load the create page with Step 1: Rule Definition already being in a `danger` state, because an incomplete rule definition component immediately sends errors, and the error API doesn't distinguish between invalid data or incomplete data. This PR wraps each step in a `reportOnBlur` higher-order component, which will report the first time a step triggers an `onBlur` event. Steps with errors will now report `incomplete` until they first trigger an `onBlur`. The result: 1. The user loads the Create Rule page. Rule Definition is marked `incomplete` 2. The user interacts with Rule Definition, but does not yet complete the definition. 3. The user interacts with the Actions step, the Rule Details step, or another part of the page. The Rule Definition is now marked `danger`. This is inelegant compared to an error API that can actually distinguish between an incomplete form and an invalid form, but it's an improvement for now. --------- Co-authored-by: Elastic Machine <[email protected]>

…tracking (elastic#205944) ## Summary Part of elastic#195211 In preparation for the horizontal rule form layout, move the generation of the rule form steps into three hooks: - `useCommonRuleFormSteps`: private hook that generates a series of objects specifying the rule form steps, how to display them, and what order to display them in - `useRuleFormSteps`: hook that calls `useCommonRuleFormSteps` and transforms them into data for the standard vertical `EuiSteps`, along with progress tracking based on `onBlur` events - `useRuleFormHorizontalSteps`: hook that calls hook that calls `useCommonRuleFormSteps` and transforms them into data for `EuiStepsHorizontal`, plus navigation functions. ***These will be used in the smaller rule form flyout in a second PR*** Because `EuiStepsHorizontal` rely more heavily on the `EuiSteps` `status` property, I took this opportunity to improve progress tracking in the standard vertical steps. Most rule types will load the create page with Step 1: Rule Definition already being in a `danger` state, because an incomplete rule definition component immediately sends errors, and the error API doesn't distinguish between invalid data or incomplete data. This PR wraps each step in a `reportOnBlur` higher-order component, which will report the first time a step triggers an `onBlur` event. Steps with errors will now report `incomplete` until they first trigger an `onBlur`. The result: 1. The user loads the Create Rule page. Rule Definition is marked `incomplete` 2. The user interacts with Rule Definition, but does not yet complete the definition. 3. The user interacts with the Actions step, the Rule Details step, or another part of the page. The Rule Definition is now marked `danger`. This is inelegant compared to an error API that can actually distinguish between an incomplete form and an invalid form, but it's an improvement for now. --------- Co-authored-by: Elastic Machine <[email protected]> (cherry picked from commit d8b0b6e)

…gress tracking (#205944) (#206346) # Backport This will backport the following commits from `main` to `8.x`: - [[ResponseOps] [Rule Form] Move rule form steps to hook with progress tracking (#205944)](#205944)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport)  Co-authored-by: Zacqary Adam Xeper <[email protected]>

…tracking (elastic#205944) ## Summary Part of elastic#195211 In preparation for the horizontal rule form layout, move the generation of the rule form steps into three hooks: - `useCommonRuleFormSteps`: private hook that generates a series of objects specifying the rule form steps, how to display them, and what order to display them in - `useRuleFormSteps`: hook that calls `useCommonRuleFormSteps` and transforms them into data for the standard vertical `EuiSteps`, along with progress tracking based on `onBlur` events - `useRuleFormHorizontalSteps`: hook that calls hook that calls `useCommonRuleFormSteps` and transforms them into data for `EuiStepsHorizontal`, plus navigation functions. ***These will be used in the smaller rule form flyout in a second PR*** Because `EuiStepsHorizontal` rely more heavily on the `EuiSteps` `status` property, I took this opportunity to improve progress tracking in the standard vertical steps. Most rule types will load the create page with Step 1: Rule Definition already being in a `danger` state, because an incomplete rule definition component immediately sends errors, and the error API doesn't distinguish between invalid data or incomplete data. This PR wraps each step in a `reportOnBlur` higher-order component, which will report the first time a step triggers an `onBlur` event. Steps with errors will now report `incomplete` until they first trigger an `onBlur`. The result: 1. The user loads the Create Rule page. Rule Definition is marked `incomplete` 2. The user interacts with Rule Definition, but does not yet complete the definition. 3. The user interacts with the Actions step, the Rule Details step, or another part of the page. The Rule Definition is now marked `danger`. This is inelegant compared to an error API that can actually distinguish between an incomplete form and an invalid form, but it's an improvement for now. --------- Co-authored-by: Elastic Machine <[email protected]>

…nsive design and illustration to rule form page (#206141) ## Summary Part of #195211 Adds components for the new rule form flyout, and duplicates some of its design elements as responsive design on the Rule Page. This PR makes use of CSS `@container` queries, which EUI doesn't yet support natively. I've opened elastic/eui#8265 to get native EUI support for this functionality, but for now we can apply it through class names and SCSS. The reason we're using `@container` is so the Rule Form can be responsive regardless of whether it's bound by the window size (in the case of the Rule Page) or a container element on a larger screen (in the Rule Flyout). When responsive design just relies on `@media screen` queries, we can have a situation where we're trying to render the rule form in a 500px wide flyout, but because the window is 1920px wide, it still tries to apply wide screen styling. `@container` instead responds to the width of an enclosing element, which can either be the body of the Rule Page, or the width of the Rule Flyout. ### Non-User Facing Changes - Adds the new rule flyout to `@kbn/response-ops-rule-form`. ***It is not yet actually user-facing anywhere in the application, this will be done in a second PR.*** <details> <summary><h4>Screenshots</h4></summary> <img width="508" alt="Screenshot 2025-01-08 at 4 29 55 PM" src="https://github.com/user-attachments/assets/7f03cd3a-5f37-4ac2-9992-ca4951664770" /> <img width="502" alt="Screenshot 2025-01-08 at 4 29 59 PM" src="https://github.com/user-attachments/assets/c0620fc2-83db-4603-90b7-1282e5b0e6ab" /> <img width="507" alt="Screenshot 2025-01-08 at 4 30 03 PM" src="https://github.com/user-attachments/assets/8440d551-46af-49e0-9c92-22d6b3ba1866" /> <img width="507" alt="Screenshot 2025-01-08 at 4 30 32 PM" src="https://github.com/user-attachments/assets/cf7493a7-6e4a-4e55-8027-89e9b36012fc" /> </details> ### User-Facing Changes These changes were added to the existing full page rule form to minimize the amount of code differences between the flyout and the full page - Adds some responsive styling to the rule form page to make it look more similar to the flyout when the browser window is narrow <details> <summary>Screenshot</summary> <img width="783" alt="Screenshot 2025-01-08 at 4 31 50 PM" src="https://github.com/user-attachments/assets/a3532b92-9f22-4e88-bcc3-e408fc53e64c" /> </details> - Adds the new illustrated "Add an action" empty prompt from the flyout designs to the existing rule form page <details> <summary>Screenshot</summary> <img width="1299" alt="Screenshot 2025-01-08 at 5 00 55 PM" src="https://github.com/user-attachments/assets/c4acd50d-9268-4874-b650-ecba532f3e9c" /> </details> ### Testing To test the new flyout, edit `packages/response-ops/rule_form/src/create_rule_form.tsx` and `packages/response-ops/rule_form/src/edit_rule_form.tsx` so that they render `<RuleFlyout>` instead of `<RulePage>`. <details> <summary><strong>Use this diff block</strong></summary> ```diff diff --git a/packages/response-ops/rule_form/src/create_rule_form.tsx b/packages/response-ops/rule_form/src/create_rule_form.tsx index 2f5e0472dcd..564744b96ec 100644 --- a/packages/response-ops/rule_form/src/create_rule_form.tsx +++ b/packages/response-ops/rule_form/src/create_rule_form.tsx @@ -31,6 +31,7 @@ import { parseRuleCircuitBreakerErrorMessage, } from './utils'; import { RULE_CREATE_SUCCESS_TEXT, RULE_CREATE_ERROR_TEXT } from './translations'; +import { RuleFlyout } from './rule_flyout'; export interface CreateRuleFormProps { ruleTypeId: string; @@ -199,7 +200,7 @@ export const CreateRuleForm = (props: CreateRuleFormProps) => { }), }} > - <RulePage isEdit={false} isSaving={isSaving} onCancel={onCancel} onSave={onSave} /> + <RuleFlyout isEdit={false} isSaving={isSaving} onCancel={onCancel} onSave={onSave} /> </RuleFormStateProvider> </div> ); diff --git a/packages/response-ops/rule_form/src/edit_rule_form.tsx b/packages/response-ops/rule_form/src/edit_rule_form.tsx index 392447114ed..41aecd7245a 100644 --- a/packages/response-ops/rule_form/src/edit_rule_form.tsx +++ b/packages/response-ops/rule_form/src/edit_rule_form.tsx @@ -26,6 +26,7 @@ import { import { RULE_EDIT_ERROR_TEXT, RULE_EDIT_SUCCESS_TEXT } from './translations'; import { getAvailableRuleTypes, parseRuleCircuitBreakerErrorMessage } from './utils'; import { DEFAULT_VALID_CONSUMERS, getDefaultFormData } from './constants'; +import { RuleFlyout } from './rule_flyout'; export interface EditRuleFormProps { id: string; @@ -193,7 +194,7 @@ export const EditRuleForm = (props: EditRuleFormProps) => { showMustacheAutocompleteSwitch, }} > - <RulePage isEdit={true} isSaving={isSaving} onSave={onSave} onCancel={onCancel} /> + <RuleFlyout isEdit={true} isSaving={isSaving} onSave={onSave} onCancel={onCancel} /> </RuleFormStateProvider> </div> ); ``` </details> ### Still Todo 1. Replace the action connector modal with an in-flyout UI as called for in the [design spec](https://www.figma.com/design/zetHXnUP0YnDG4YmvPwRb8/Adapt-new-Rule-form-to-work-in-flyout) 2. Add the Show Request UI 3. Replace all instances of the v1 rule flyout with this new one (it's used heavily in solutions, not in Stack Management) ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios

…nsive design and illustration to rule form page (elastic#206141) ## Summary Part of elastic#195211 Adds components for the new rule form flyout, and duplicates some of its design elements as responsive design on the Rule Page. This PR makes use of CSS `@container` queries, which EUI doesn't yet support natively. I've opened elastic/eui#8265 to get native EUI support for this functionality, but for now we can apply it through class names and SCSS. The reason we're using `@container` is so the Rule Form can be responsive regardless of whether it's bound by the window size (in the case of the Rule Page) or a container element on a larger screen (in the Rule Flyout). When responsive design just relies on `@media screen` queries, we can have a situation where we're trying to render the rule form in a 500px wide flyout, but because the window is 1920px wide, it still tries to apply wide screen styling. `@container` instead responds to the width of an enclosing element, which can either be the body of the Rule Page, or the width of the Rule Flyout. ### Non-User Facing Changes - Adds the new rule flyout to `@kbn/response-ops-rule-form`. ***It is not yet actually user-facing anywhere in the application, this will be done in a second PR.*** <details> <summary><h4>Screenshots</h4></summary> <img width="508" alt="Screenshot 2025-01-08 at 4 29 55 PM" src="https://github.com/user-attachments/assets/7f03cd3a-5f37-4ac2-9992-ca4951664770" /> <img width="502" alt="Screenshot 2025-01-08 at 4 29 59 PM" src="https://github.com/user-attachments/assets/c0620fc2-83db-4603-90b7-1282e5b0e6ab" /> <img width="507" alt="Screenshot 2025-01-08 at 4 30 03 PM" src="https://github.com/user-attachments/assets/8440d551-46af-49e0-9c92-22d6b3ba1866" /> <img width="507" alt="Screenshot 2025-01-08 at 4 30 32 PM" src="https://github.com/user-attachments/assets/cf7493a7-6e4a-4e55-8027-89e9b36012fc" /> </details> ### User-Facing Changes These changes were added to the existing full page rule form to minimize the amount of code differences between the flyout and the full page - Adds some responsive styling to the rule form page to make it look more similar to the flyout when the browser window is narrow <details> <summary>Screenshot</summary> <img width="783" alt="Screenshot 2025-01-08 at 4 31 50 PM" src="https://github.com/user-attachments/assets/a3532b92-9f22-4e88-bcc3-e408fc53e64c" /> </details> - Adds the new illustrated "Add an action" empty prompt from the flyout designs to the existing rule form page <details> <summary>Screenshot</summary> <img width="1299" alt="Screenshot 2025-01-08 at 5 00 55 PM" src="https://github.com/user-attachments/assets/c4acd50d-9268-4874-b650-ecba532f3e9c" /> </details> ### Testing To test the new flyout, edit `packages/response-ops/rule_form/src/create_rule_form.tsx` and `packages/response-ops/rule_form/src/edit_rule_form.tsx` so that they render `<RuleFlyout>` instead of `<RulePage>`. <details> <summary><strong>Use this diff block</strong></summary> ```diff diff --git a/packages/response-ops/rule_form/src/create_rule_form.tsx b/packages/response-ops/rule_form/src/create_rule_form.tsx index 2f5e0472dcd..564744b96ec 100644 --- a/packages/response-ops/rule_form/src/create_rule_form.tsx +++ b/packages/response-ops/rule_form/src/create_rule_form.tsx @@ -31,6 +31,7 @@ import { parseRuleCircuitBreakerErrorMessage, } from './utils'; import { RULE_CREATE_SUCCESS_TEXT, RULE_CREATE_ERROR_TEXT } from './translations'; +import { RuleFlyout } from './rule_flyout'; export interface CreateRuleFormProps { ruleTypeId: string; @@ -199,7 +200,7 @@ export const CreateRuleForm = (props: CreateRuleFormProps) => { }), }} > - <RulePage isEdit={false} isSaving={isSaving} onCancel={onCancel} onSave={onSave} /> + <RuleFlyout isEdit={false} isSaving={isSaving} onCancel={onCancel} onSave={onSave} /> </RuleFormStateProvider> </div> ); diff --git a/packages/response-ops/rule_form/src/edit_rule_form.tsx b/packages/response-ops/rule_form/src/edit_rule_form.tsx index 392447114ed..41aecd7245a 100644 --- a/packages/response-ops/rule_form/src/edit_rule_form.tsx +++ b/packages/response-ops/rule_form/src/edit_rule_form.tsx @@ -26,6 +26,7 @@ import { import { RULE_EDIT_ERROR_TEXT, RULE_EDIT_SUCCESS_TEXT } from './translations'; import { getAvailableRuleTypes, parseRuleCircuitBreakerErrorMessage } from './utils'; import { DEFAULT_VALID_CONSUMERS, getDefaultFormData } from './constants'; +import { RuleFlyout } from './rule_flyout'; export interface EditRuleFormProps { id: string; @@ -193,7 +194,7 @@ export const EditRuleForm = (props: EditRuleFormProps) => { showMustacheAutocompleteSwitch, }} > - <RulePage isEdit={true} isSaving={isSaving} onSave={onSave} onCancel={onCancel} /> + <RuleFlyout isEdit={true} isSaving={isSaving} onSave={onSave} onCancel={onCancel} /> </RuleFormStateProvider> </div> ); ``` </details> ### Still Todo 1. Replace the action connector modal with an in-flyout UI as called for in the [design spec](https://www.figma.com/design/zetHXnUP0YnDG4YmvPwRb8/Adapt-new-Rule-form-to-work-in-flyout) 2. Add the Show Request UI 3. Replace all instances of the v1 rule flyout with this new one (it's used heavily in solutions, not in Stack Management) ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios (cherry picked from commit 471f948)

… responsive design and illustration to rule form page (#206141) (#206816) # Backport This will backport the following commits from `main` to `8.x`: - [[Response Ops] [Rule Form] Add new flyout to rule form library, responsive design and illustration to rule form page (#206141)](#206141)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport)  Co-authored-by: Zacqary Adam Xeper <[email protected]>

… flyout (#206154) ## Summary Part of #195211 - Adds Show Request screen to the new rule form flyout <details> <summary>Screenshot</summary> <img width="585" alt="Screenshot 2025-01-10 at 1 30 15 PM" src="https://github.com/user-attachments/assets/72500b0d-d959-4d17-944e-a7dc0894fb98" /> </details> - Renders the action connectors UI within the flyout instead of opening a modal <details> <summary>Screenshot</summary> <img width="505" alt="Screenshot 2025-01-10 at 1 28 38 PM" src="https://github.com/user-attachments/assets/b5b464c0-7359-43ab-bea1-93d2981a5794" /> </details> - Duplicates the dropdown filter design from the flyout UI within the action connectors modal when displayed on a smaller screen <details> <summary>Screenshot</summary> <img width="809" alt="Screenshot 2025-01-10 at 1 30 28 PM" src="https://github.com/user-attachments/assets/5ef28458-1b6d-4a29-961d-fbcc1640e706" /> </details> ### Implementation notes In order to get the action connectors UI to render the same way in both a modal and the flyout, without duplicating a large amount of code, I had to introduce a little bit of complexity. Within the Rule Page, it's as simple as opening the UI inside a modal, but the flyout cannot open a second flyout; it has to know when and how to completely replace its own contents. - The bulk of the action connectors UI is now moved to `<RuleActionsConnectorsBody>`. `<RuleActionsConnectorsModal>` and `<RuleFlyoutSelectConnector>` act as wrappers for this component. - The `<RuleActions>` step no longer handles rendering the connector UI, because it's not at a high enough level to know if it's in the `<RulePage>` or the `<RuleFlyout>`. Instead, it simply sends a signal up the context hierarchy to `setIsConnectorsScreenVisible`. - A new context called `RuleFormScreenContext` keeps track of `isConnectorsScreenVisible`, a state for whether or not the action connectors "screen" is open, regardless of whether that screen is displayed in a modal or a flyout. - The Rule Page uses `isConnectorsScreenVisible` to determine whether to render the modal. This works the same way as it used to, but handled by the `<RulePage>` instead of the `<RuleActions>` component. - The Rule Flyout uses `isConnectorsScreenVisible` to determine whether to continue to render `<RuleFlyoutBody>` or to completely replace its contents with `<RuleFlyoutSelectConnector>` For consistency, this PR also moves the Show Request modal/flyout screen into the same system. ### Testing To test the new flyout, edit `packages/response-ops/rule_form/src/create_rule_form.tsx` and `packages/response-ops/rule_form/src/edit_rule_form.tsx` so that they render `<RuleFlyout>` instead of `<RulePage>`. <details> <summary><strong>Use this diff block</strong></summary> ```diff diff --git a/packages/response-ops/rule_form/src/create_rule_form.tsx b/packages/response-ops/rule_form/src/create_rule_form.tsx index 2f5e0472dcd..564744b96ec 100644 --- a/packages/response-ops/rule_form/src/create_rule_form.tsx +++ b/packages/response-ops/rule_form/src/create_rule_form.tsx @@ -31,6 +31,7 @@ import { parseRuleCircuitBreakerErrorMessage, } from './utils'; import { RULE_CREATE_SUCCESS_TEXT, RULE_CREATE_ERROR_TEXT } from './translations'; +import { RuleFlyout } from './rule_flyout'; export interface CreateRuleFormProps { ruleTypeId: string; @@ -199,7 +200,7 @@ export const CreateRuleForm = (props: CreateRuleFormProps) => { }), }} > - <RulePage isEdit={false} isSaving={isSaving} onCancel={onCancel} onSave={onSave} /> + <RuleFlyout isEdit={false} isSaving={isSaving} onCancel={onCancel} onSave={onSave} /> </RuleFormStateProvider> </div> ); diff --git a/packages/response-ops/rule_form/src/edit_rule_form.tsx b/packages/response-ops/rule_form/src/edit_rule_form.tsx index 392447114ed..41aecd7245a 100644 --- a/packages/response-ops/rule_form/src/edit_rule_form.tsx +++ b/packages/response-ops/rule_form/src/edit_rule_form.tsx @@ -26,6 +26,7 @@ import { import { RULE_EDIT_ERROR_TEXT, RULE_EDIT_SUCCESS_TEXT } from './translations'; import { getAvailableRuleTypes, parseRuleCircuitBreakerErrorMessage } from './utils'; import { DEFAULT_VALID_CONSUMERS, getDefaultFormData } from './constants'; +import { RuleFlyout } from './rule_flyout'; export interface EditRuleFormProps { id: string; @@ -193,7 +194,7 @@ export const EditRuleForm = (props: EditRuleFormProps) => { showMustacheAutocompleteSwitch, }} > - <RulePage isEdit={true} isSaving={isSaving} onSave={onSave} onCancel={onCancel} /> + <RuleFlyout isEdit={true} isSaving={isSaving} onSave={onSave} onCancel={onCancel} /> </RuleFormStateProvider> </div> ); ``` </details> ### Still Todo 1. Replace all instances of the v1 rule flyout with this new one (it's used heavily in solutions, not in Stack Management) ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: Elastic Machine <[email protected]>

… flyout (elastic#206154) ## Summary Part of elastic#195211 - Adds Show Request screen to the new rule form flyout <details> <summary>Screenshot</summary> <img width="585" alt="Screenshot 2025-01-10 at 1 30 15 PM" src="https://github.com/user-attachments/assets/72500b0d-d959-4d17-944e-a7dc0894fb98" /> </details> - Renders the action connectors UI within the flyout instead of opening a modal <details> <summary>Screenshot</summary> <img width="505" alt="Screenshot 2025-01-10 at 1 28 38 PM" src="https://github.com/user-attachments/assets/b5b464c0-7359-43ab-bea1-93d2981a5794" /> </details> - Duplicates the dropdown filter design from the flyout UI within the action connectors modal when displayed on a smaller screen <details> <summary>Screenshot</summary> <img width="809" alt="Screenshot 2025-01-10 at 1 30 28 PM" src="https://github.com/user-attachments/assets/5ef28458-1b6d-4a29-961d-fbcc1640e706" /> </details> ### Implementation notes In order to get the action connectors UI to render the same way in both a modal and the flyout, without duplicating a large amount of code, I had to introduce a little bit of complexity. Within the Rule Page, it's as simple as opening the UI inside a modal, but the flyout cannot open a second flyout; it has to know when and how to completely replace its own contents. - The bulk of the action connectors UI is now moved to `<RuleActionsConnectorsBody>`. `<RuleActionsConnectorsModal>` and `<RuleFlyoutSelectConnector>` act as wrappers for this component. - The `<RuleActions>` step no longer handles rendering the connector UI, because it's not at a high enough level to know if it's in the `<RulePage>` or the `<RuleFlyout>`. Instead, it simply sends a signal up the context hierarchy to `setIsConnectorsScreenVisible`. - A new context called `RuleFormScreenContext` keeps track of `isConnectorsScreenVisible`, a state for whether or not the action connectors "screen" is open, regardless of whether that screen is displayed in a modal or a flyout. - The Rule Page uses `isConnectorsScreenVisible` to determine whether to render the modal. This works the same way as it used to, but handled by the `<RulePage>` instead of the `<RuleActions>` component. - The Rule Flyout uses `isConnectorsScreenVisible` to determine whether to continue to render `<RuleFlyoutBody>` or to completely replace its contents with `<RuleFlyoutSelectConnector>` For consistency, this PR also moves the Show Request modal/flyout screen into the same system. ### Testing To test the new flyout, edit `packages/response-ops/rule_form/src/create_rule_form.tsx` and `packages/response-ops/rule_form/src/edit_rule_form.tsx` so that they render `<RuleFlyout>` instead of `<RulePage>`. <details> <summary><strong>Use this diff block</strong></summary> ```diff diff --git a/packages/response-ops/rule_form/src/create_rule_form.tsx b/packages/response-ops/rule_form/src/create_rule_form.tsx index 2f5e0472dcd..564744b96ec 100644 --- a/packages/response-ops/rule_form/src/create_rule_form.tsx +++ b/packages/response-ops/rule_form/src/create_rule_form.tsx @@ -31,6 +31,7 @@ import { parseRuleCircuitBreakerErrorMessage, } from './utils'; import { RULE_CREATE_SUCCESS_TEXT, RULE_CREATE_ERROR_TEXT } from './translations'; +import { RuleFlyout } from './rule_flyout'; export interface CreateRuleFormProps { ruleTypeId: string; @@ -199,7 +200,7 @@ export const CreateRuleForm = (props: CreateRuleFormProps) => { }), }} > - <RulePage isEdit={false} isSaving={isSaving} onCancel={onCancel} onSave={onSave} /> + <RuleFlyout isEdit={false} isSaving={isSaving} onCancel={onCancel} onSave={onSave} /> </RuleFormStateProvider> </div> ); diff --git a/packages/response-ops/rule_form/src/edit_rule_form.tsx b/packages/response-ops/rule_form/src/edit_rule_form.tsx index 392447114ed..41aecd7245a 100644 --- a/packages/response-ops/rule_form/src/edit_rule_form.tsx +++ b/packages/response-ops/rule_form/src/edit_rule_form.tsx @@ -26,6 +26,7 @@ import { import { RULE_EDIT_ERROR_TEXT, RULE_EDIT_SUCCESS_TEXT } from './translations'; import { getAvailableRuleTypes, parseRuleCircuitBreakerErrorMessage } from './utils'; import { DEFAULT_VALID_CONSUMERS, getDefaultFormData } from './constants'; +import { RuleFlyout } from './rule_flyout'; export interface EditRuleFormProps { id: string; @@ -193,7 +194,7 @@ export const EditRuleForm = (props: EditRuleFormProps) => { showMustacheAutocompleteSwitch, }} > - <RulePage isEdit={true} isSaving={isSaving} onSave={onSave} onCancel={onCancel} /> + <RuleFlyout isEdit={true} isSaving={isSaving} onSave={onSave} onCancel={onCancel} /> </RuleFormStateProvider> </div> ); ``` </details> ### Still Todo 1. Replace all instances of the v1 rule flyout with this new one (it's used heavily in solutions, not in Stack Management) ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: Elastic Machine <[email protected]> (cherry picked from commit 8004e3e)

…ens to flyout (#206154) (#207903) # Backport This will backport the following commits from `main` to `8.x`: - [[Response Ops] [Rule Form] Add Show Request and Add Action screens to flyout (#206154)](#206154)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport)  Co-authored-by: Zacqary Adam Xeper <[email protected]>

…tracking (elastic#205944) ## Summary Part of elastic#195211 In preparation for the horizontal rule form layout, move the generation of the rule form steps into three hooks: - `useCommonRuleFormSteps`: private hook that generates a series of objects specifying the rule form steps, how to display them, and what order to display them in - `useRuleFormSteps`: hook that calls `useCommonRuleFormSteps` and transforms them into data for the standard vertical `EuiSteps`, along with progress tracking based on `onBlur` events - `useRuleFormHorizontalSteps`: hook that calls hook that calls `useCommonRuleFormSteps` and transforms them into data for `EuiStepsHorizontal`, plus navigation functions. ***These will be used in the smaller rule form flyout in a second PR*** Because `EuiStepsHorizontal` rely more heavily on the `EuiSteps` `status` property, I took this opportunity to improve progress tracking in the standard vertical steps. Most rule types will load the create page with Step 1: Rule Definition already being in a `danger` state, because an incomplete rule definition component immediately sends errors, and the error API doesn't distinguish between invalid data or incomplete data. This PR wraps each step in a `reportOnBlur` higher-order component, which will report the first time a step triggers an `onBlur` event. Steps with errors will now report `incomplete` until they first trigger an `onBlur`. The result: 1. The user loads the Create Rule page. Rule Definition is marked `incomplete` 2. The user interacts with Rule Definition, but does not yet complete the definition. 3. The user interacts with the Actions step, the Rule Details step, or another part of the page. The Rule Definition is now marked `danger`. This is inelegant compared to an error API that can actually distinguish between an incomplete form and an invalid form, but it's an improvement for now. --------- Co-authored-by: Elastic Machine <[email protected]>

…nsive design and illustration to rule form page (elastic#206141) ## Summary Part of elastic#195211 Adds components for the new rule form flyout, and duplicates some of its design elements as responsive design on the Rule Page. This PR makes use of CSS `@container` queries, which EUI doesn't yet support natively. I've opened elastic/eui#8265 to get native EUI support for this functionality, but for now we can apply it through class names and SCSS. The reason we're using `@container` is so the Rule Form can be responsive regardless of whether it's bound by the window size (in the case of the Rule Page) or a container element on a larger screen (in the Rule Flyout). When responsive design just relies on `@media screen` queries, we can have a situation where we're trying to render the rule form in a 500px wide flyout, but because the window is 1920px wide, it still tries to apply wide screen styling. `@container` instead responds to the width of an enclosing element, which can either be the body of the Rule Page, or the width of the Rule Flyout. ### Non-User Facing Changes - Adds the new rule flyout to `@kbn/response-ops-rule-form`. ***It is not yet actually user-facing anywhere in the application, this will be done in a second PR.*** <details> <summary><h4>Screenshots</h4></summary> <img width="508" alt="Screenshot 2025-01-08 at 4 29 55 PM" src="https://github.com/user-attachments/assets/7f03cd3a-5f37-4ac2-9992-ca4951664770" /> <img width="502" alt="Screenshot 2025-01-08 at 4 29 59 PM" src="https://github.com/user-attachments/assets/c0620fc2-83db-4603-90b7-1282e5b0e6ab" /> <img width="507" alt="Screenshot 2025-01-08 at 4 30 03 PM" src="https://github.com/user-attachments/assets/8440d551-46af-49e0-9c92-22d6b3ba1866" /> <img width="507" alt="Screenshot 2025-01-08 at 4 30 32 PM" src="https://github.com/user-attachments/assets/cf7493a7-6e4a-4e55-8027-89e9b36012fc" /> </details> ### User-Facing Changes These changes were added to the existing full page rule form to minimize the amount of code differences between the flyout and the full page - Adds some responsive styling to the rule form page to make it look more similar to the flyout when the browser window is narrow <details> <summary>Screenshot</summary> <img width="783" alt="Screenshot 2025-01-08 at 4 31 50 PM" src="https://github.com/user-attachments/assets/a3532b92-9f22-4e88-bcc3-e408fc53e64c" /> </details> - Adds the new illustrated "Add an action" empty prompt from the flyout designs to the existing rule form page <details> <summary>Screenshot</summary> <img width="1299" alt="Screenshot 2025-01-08 at 5 00 55 PM" src="https://github.com/user-attachments/assets/c4acd50d-9268-4874-b650-ecba532f3e9c" /> </details> ### Testing To test the new flyout, edit `packages/response-ops/rule_form/src/create_rule_form.tsx` and `packages/response-ops/rule_form/src/edit_rule_form.tsx` so that they render `<RuleFlyout>` instead of `<RulePage>`. <details> <summary><strong>Use this diff block</strong></summary> ```diff diff --git a/packages/response-ops/rule_form/src/create_rule_form.tsx b/packages/response-ops/rule_form/src/create_rule_form.tsx index 2f5e0472dcd..564744b96ec 100644 --- a/packages/response-ops/rule_form/src/create_rule_form.tsx +++ b/packages/response-ops/rule_form/src/create_rule_form.tsx @@ -31,6 +31,7 @@ import { parseRuleCircuitBreakerErrorMessage, } from './utils'; import { RULE_CREATE_SUCCESS_TEXT, RULE_CREATE_ERROR_TEXT } from './translations'; +import { RuleFlyout } from './rule_flyout'; export interface CreateRuleFormProps { ruleTypeId: string; @@ -199,7 +200,7 @@ export const CreateRuleForm = (props: CreateRuleFormProps) => { }), }} > - <RulePage isEdit={false} isSaving={isSaving} onCancel={onCancel} onSave={onSave} /> + <RuleFlyout isEdit={false} isSaving={isSaving} onCancel={onCancel} onSave={onSave} /> </RuleFormStateProvider> </div> ); diff --git a/packages/response-ops/rule_form/src/edit_rule_form.tsx b/packages/response-ops/rule_form/src/edit_rule_form.tsx index 392447114ed..41aecd7245a 100644 --- a/packages/response-ops/rule_form/src/edit_rule_form.tsx +++ b/packages/response-ops/rule_form/src/edit_rule_form.tsx @@ -26,6 +26,7 @@ import { import { RULE_EDIT_ERROR_TEXT, RULE_EDIT_SUCCESS_TEXT } from './translations'; import { getAvailableRuleTypes, parseRuleCircuitBreakerErrorMessage } from './utils'; import { DEFAULT_VALID_CONSUMERS, getDefaultFormData } from './constants'; +import { RuleFlyout } from './rule_flyout'; export interface EditRuleFormProps { id: string; @@ -193,7 +194,7 @@ export const EditRuleForm = (props: EditRuleFormProps) => { showMustacheAutocompleteSwitch, }} > - <RulePage isEdit={true} isSaving={isSaving} onSave={onSave} onCancel={onCancel} /> + <RuleFlyout isEdit={true} isSaving={isSaving} onSave={onSave} onCancel={onCancel} /> </RuleFormStateProvider> </div> ); ``` </details> ### Still Todo 1. Replace the action connector modal with an in-flyout UI as called for in the [design spec](https://www.figma.com/design/zetHXnUP0YnDG4YmvPwRb8/Adapt-new-Rule-form-to-work-in-flyout) 2. Add the Show Request UI 3. Replace all instances of the v1 rule flyout with this new one (it's used heavily in solutions, not in Stack Management) ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios

… flyout (elastic#206154) ## Summary Part of elastic#195211 - Adds Show Request screen to the new rule form flyout <details> <summary>Screenshot</summary> <img width="585" alt="Screenshot 2025-01-10 at 1 30 15 PM" src="https://github.com/user-attachments/assets/72500b0d-d959-4d17-944e-a7dc0894fb98" /> </details> - Renders the action connectors UI within the flyout instead of opening a modal <details> <summary>Screenshot</summary> <img width="505" alt="Screenshot 2025-01-10 at 1 28 38 PM" src="https://github.com/user-attachments/assets/b5b464c0-7359-43ab-bea1-93d2981a5794" /> </details> - Duplicates the dropdown filter design from the flyout UI within the action connectors modal when displayed on a smaller screen <details> <summary>Screenshot</summary> <img width="809" alt="Screenshot 2025-01-10 at 1 30 28 PM" src="https://github.com/user-attachments/assets/5ef28458-1b6d-4a29-961d-fbcc1640e706" /> </details> ### Implementation notes In order to get the action connectors UI to render the same way in both a modal and the flyout, without duplicating a large amount of code, I had to introduce a little bit of complexity. Within the Rule Page, it's as simple as opening the UI inside a modal, but the flyout cannot open a second flyout; it has to know when and how to completely replace its own contents. - The bulk of the action connectors UI is now moved to `<RuleActionsConnectorsBody>`. `<RuleActionsConnectorsModal>` and `<RuleFlyoutSelectConnector>` act as wrappers for this component. - The `<RuleActions>` step no longer handles rendering the connector UI, because it's not at a high enough level to know if it's in the `<RulePage>` or the `<RuleFlyout>`. Instead, it simply sends a signal up the context hierarchy to `setIsConnectorsScreenVisible`. - A new context called `RuleFormScreenContext` keeps track of `isConnectorsScreenVisible`, a state for whether or not the action connectors "screen" is open, regardless of whether that screen is displayed in a modal or a flyout. - The Rule Page uses `isConnectorsScreenVisible` to determine whether to render the modal. This works the same way as it used to, but handled by the `<RulePage>` instead of the `<RuleActions>` component. - The Rule Flyout uses `isConnectorsScreenVisible` to determine whether to continue to render `<RuleFlyoutBody>` or to completely replace its contents with `<RuleFlyoutSelectConnector>` For consistency, this PR also moves the Show Request modal/flyout screen into the same system. ### Testing To test the new flyout, edit `packages/response-ops/rule_form/src/create_rule_form.tsx` and `packages/response-ops/rule_form/src/edit_rule_form.tsx` so that they render `<RuleFlyout>` instead of `<RulePage>`. <details> <summary><strong>Use this diff block</strong></summary> ```diff diff --git a/packages/response-ops/rule_form/src/create_rule_form.tsx b/packages/response-ops/rule_form/src/create_rule_form.tsx index 2f5e0472dcd..564744b96ec 100644 --- a/packages/response-ops/rule_form/src/create_rule_form.tsx +++ b/packages/response-ops/rule_form/src/create_rule_form.tsx @@ -31,6 +31,7 @@ import { parseRuleCircuitBreakerErrorMessage, } from './utils'; import { RULE_CREATE_SUCCESS_TEXT, RULE_CREATE_ERROR_TEXT } from './translations'; +import { RuleFlyout } from './rule_flyout'; export interface CreateRuleFormProps { ruleTypeId: string; @@ -199,7 +200,7 @@ export const CreateRuleForm = (props: CreateRuleFormProps) => { }), }} > - <RulePage isEdit={false} isSaving={isSaving} onCancel={onCancel} onSave={onSave} /> + <RuleFlyout isEdit={false} isSaving={isSaving} onCancel={onCancel} onSave={onSave} /> </RuleFormStateProvider> </div> ); diff --git a/packages/response-ops/rule_form/src/edit_rule_form.tsx b/packages/response-ops/rule_form/src/edit_rule_form.tsx index 392447114ed..41aecd7245a 100644 --- a/packages/response-ops/rule_form/src/edit_rule_form.tsx +++ b/packages/response-ops/rule_form/src/edit_rule_form.tsx @@ -26,6 +26,7 @@ import { import { RULE_EDIT_ERROR_TEXT, RULE_EDIT_SUCCESS_TEXT } from './translations'; import { getAvailableRuleTypes, parseRuleCircuitBreakerErrorMessage } from './utils'; import { DEFAULT_VALID_CONSUMERS, getDefaultFormData } from './constants'; +import { RuleFlyout } from './rule_flyout'; export interface EditRuleFormProps { id: string; @@ -193,7 +194,7 @@ export const EditRuleForm = (props: EditRuleFormProps) => { showMustacheAutocompleteSwitch, }} > - <RulePage isEdit={true} isSaving={isSaving} onSave={onSave} onCancel={onCancel} /> + <RuleFlyout isEdit={true} isSaving={isSaving} onSave={onSave} onCancel={onCancel} /> </RuleFormStateProvider> </div> ); ``` </details> ### Still Todo 1. Replace all instances of the v1 rule flyout with this new one (it's used heavily in solutions, not in Stack Management) ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios --------- Co-authored-by: Elastic Machine <[email protected]>

cnasikas added Feature:Alerting/RulesManagement Issues related to the Rules Management UX Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) labels Oct 7, 2024

cnasikas mentioned this issue Oct 16, 2024

[Observability] Use the new rule form page when creating rules from within the observability application #195574

Closed

cnasikas assigned Zacqary Oct 21, 2024

cnasikas mentioned this issue Nov 1, 2024

[RAM] [Rule Form V2] Integrate create form into flyout UI #179108

Closed

Zacqary mentioned this issue Nov 1, 2024

[ResponseOps][Rules] Move Rule Form code into @kbn/response-ops-rule-form #198725

Merged

1 task

Zacqary mentioned this issue Jan 14, 2025

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

Open

2 tasks

Zacqary linked a pull request Jan 31, 2025 that will close this issue

[Response Ops] [Rule Form] Remove V1 Rule Form Flyout #209171

Draft

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[ResponseOps][Rules] Use the new rule form to the create rules flyout #195211

[ResponseOps][Rules] Use the new rule form to the create rules flyout #195211

cnasikas commented Oct 7, 2024 •

edited by Zacqary

Loading

DoD

elasticmachine commented Oct 7, 2024

Zacqary commented Oct 24, 2024

cnasikas commented Oct 25, 2024

[ResponseOps][Rules] Use the new rule form to the create rules flyout #195211

[ResponseOps][Rules] Use the new rule form to the create rules flyout #195211

Comments

cnasikas commented Oct 7, 2024 • edited by Zacqary Loading

DoD

elasticmachine commented Oct 7, 2024

Zacqary commented Oct 24, 2024

cnasikas commented Oct 25, 2024

cnasikas commented Oct 7, 2024 •

edited by Zacqary

Loading