Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RAM] [Rule Form V2] Add new rule type selection modal #179285

Merged
merged 28 commits into from
Apr 3, 2024

Conversation

Zacqary
Copy link
Contributor

@Zacqary Zacqary commented Mar 22, 2024

Summary

Closes #179104

Stack Management Rules Page

Screen.Recording.2024-03-22.at.1.51.06.PM.mov

Observability Rules Page

Screenshot 2024-03-22 at 1 52 18 PM

This adds the new Rule Type Flyout from the Create Rule Flow v2 project. As of this PR, it simply replaces the rule type selection flow from the existing v1 flyout, and opens the v1 flyout when the user selects a rule type.

This functionality works well enough with existing v1 code that I'm comfortable not putting this modal behind a feature flag. Future UI additions for Create Rule v2, such as the full-page experience, will be behind feature flags.

Checklist

Delete any items that are not applicable to this PR.

@Zacqary Zacqary added Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) Feature:Alerting/RulesManagement Issues related to the Rules Management UX v8.14.0 labels Mar 22, 2024
@apmmachine
Copy link
Contributor

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

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

@Zacqary
Copy link
Contributor Author

Zacqary commented Mar 22, 2024

Watching the screen recording back I realized I didn't like the empty prompt, so here's a new one:

Screenshot 2024-03-22 at 2 06 16 PM

@Zacqary Zacqary marked this pull request as ready for review March 25, 2024 18:21
@Zacqary Zacqary requested review from a team as code owners March 25, 2024 18:21
@elasticmachine
Copy link
Contributor

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

@Zacqary Zacqary added release_note:feature Makes this part of the condensed release notes Team:obs-ux-management Observability Management User Experience Team labels Mar 25, 2024
@elasticmachine
Copy link
Contributor

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

@maryam-saeidi maryam-saeidi self-requested a review March 26, 2024 10:08
@maryam-saeidi
Copy link
Member

@Zacqary When I run this branch locally, I see some errors in Kibana server, do you get the same locally?

       │          ERROR in /Users/maryam.saeidi/WebstormProjects/kibana-pr/packages/kbn-alerts-ui-shared/src/rule_type_modal/components/index.tsx
       │          Module not found: Error: Can't resolve '../common/hooks' in '/Users/maryam.saeidi/WebstormProjects/kibana-pr/packages/kbn-alerts-ui-shared/src/rule_type_modal/components'
       │          resolve '../common/hooks' in '/Users/maryam.saeidi/WebstormProjects/kibana-pr/packages/kbn-alerts-ui-shared/src/rule_type_modal/components'
       │            using description file: /Users/maryam.saeidi/WebstormProjects/kibana-pr/packages/kbn-alerts-ui-shared/package.json (relative path: ./src/rule_type_modal/components)
       │              Field 'browser' doesn't contain a valid alias configuration
       │              using description file: /Users/maryam.saeidi/WebstormProjects/kibana-pr/packages/kbn-alerts-ui-shared/package.json (relative path: ./src/rule_type_modal/common/hooks)
       │                no extension
       │                  Field 'browser' doesn't contain a valid alias configuration
       │                  /Users/maryam.saeidi/WebstormProjects/kibana-pr/packages/kbn-alerts-ui-shared/src/rule_type_modal/common/hooks doesn't exist
       │                .js

@maryam-saeidi
Copy link
Member

Also, when I check the rule creation flyout in observability, I don't see what you showed in the PR description, is this expected or should I enable a feature flag for seeing this view?

Screen.Recording.2024-03-26.at.11.15.01.mov

In the view that you shared, I wonder if we can show the first category available in the left-hand menu instead of showing the rule types now found: 🤔

@Zacqary
Copy link
Contributor Author

Zacqary commented Mar 26, 2024

@maryam-saeidi Pushed a fix, if you check out the branch again the errors should disappear and you'll be able to see the new modal in Observability

@Zacqary Zacqary requested review from JiaweiWu and doakalexi March 26, 2024 16:08
Copy link
Contributor

@doakalexi doakalexi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested locally and works as expected, LGTM
It would be good to add tests for the rule type list, rule type modal, and the load rule types hook.

@Zacqary Zacqary requested a review from a team as a code owner March 28, 2024 21:53
@Zacqary
Copy link
Contributor Author

Zacqary commented Mar 29, 2024

@doakalexi Integration tests that depend on the rule type selection from V1 have all been updated. I abstracted out most of the complex functionality of the rule type component into the helper function and covered that with Jest tests, and I wasn't able to think of other testing scenarios for the modal and list components that wouldn't amount to just repeating the code in test form. Is there something you can think of that I missed?

@doakalexi
Copy link
Contributor

@doakalexi Integration tests that depend on the rule type selection from V1 have all been updated. I abstracted out most of the complex functionality of the rule type component into the helper function and covered that with Jest tests, and I wasn't able to think of other testing scenarios for the modal and list components that wouldn't amount to just repeating the code in test form. Is there something you can think of that I missed?

Sounds good! Just wanted to make sure everything that maybe needed tests had them.

Copy link
Member

@lukasolson lukasolson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DataDiscovery code changes LGTM

@Zacqary
Copy link
Contributor Author

Zacqary commented Apr 1, 2024

@elasticmachine merge upstream

Copy link
Member

@maryam-saeidi maryam-saeidi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested locally and worked as expected!

Just one comment:
In the new implementation, I didn't see the ability to change the rule type as we did it previously:

Before Now
Screenshot 2024-04-02 at 10 40 03 Screenshot 2024-04-02 at 10 49 38

@Zacqary
Copy link
Contributor Author

Zacqary commented Apr 2, 2024

@maryam-saeidi Yes, removing the X button is intentional because we're no longer listing the rule types in the flyout. To change the rule type, the user will need to go back to the new modal.

In V2 Observability will link to the full page, from which the user can only change rule types by clicking the Return link to bring them back to the rules list, which is a similar experience to what we're pushing in this PR. As far as I know the usability studies design did showed that the extra clicks required weren't a problem.

}
return true;
});
const ruleTypesFilteredBySearchAndProducer = ruleTypesFilteredBySearch.filter((ruleType) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's filter by the producer first, as this might reduce the number of rule types we need to search through

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't do this for UX reasons. Test cases explain it but I'll add a comment

registeredRuleTypes,
...props
}) => {
const [selectedProducer, setSelectedProducer] = useState<string | null>(null);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

perhaps AlertConsumers instead of string?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Producers aren't the same as consumers, and we don't have clear typedefs for these

}

const producerToDisplayName = (producer: string) => {
return Reflect.get(PRODUCER_DISPLAY_NAMES, producer) ?? producer;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

never seen Reflect.get before haha, is this any different than accessing the object normally?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gets around Typescript complaints about dynamically indexing an object with an unknown string.

@Zacqary Zacqary requested a review from maryam-saeidi April 2, 2024 22:33
@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
alerting 156 164 +8
observability 476 484 +8
securitySolution 5042 5050 +8
triggersActionsUi 690 698 +8
total +32

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id before after diff
@kbn/alerts-ui-shared 90 82 -8

Async chunks

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

id before after diff
alerting 89.2KB 90.7KB +1.5KB
observability 262.7KB 270.4KB +7.7KB
securitySolution 16.6MB 16.6MB +1.3KB
triggersActionsUi 1.6MB 1.6MB +210.0B
total +10.7KB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id before after diff
@kbn/alerts-ui-shared 1 2 +1

Page load bundle

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

id before after diff
triggersActionsUi 108.7KB 116.2KB +7.4KB
Unknown metric groups

API count

id before after diff
@kbn/alerts-ui-shared 95 87 -8

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

Copy link
Member

@maryam-saeidi maryam-saeidi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@jasonrhodes
Copy link
Member

Questions from our alerting weekly meeting:

  • What does this modal look like in serverless (observability project)?
  • Does the search box in the modal search the description text (like the existing flyout search does today)?

@Zacqary
Copy link
Contributor Author

Zacqary commented Apr 3, 2024

@jasonrhodes

Does the search box in the modal search the description text (like the existing flyout search does today)?

Yes. See these lines of the search code:

 if (searchString) {
      const lowerCaseSearchString = searchString.toLowerCase();
      return (
        ruleType.name.toLowerCase().includes(lowerCaseSearchString) ||
        (ruleType.description && ruleType.description.toLowerCase().includes(lowerCaseSearchString))
      );
    }

What does this modal look like in serverless (observability project)?

Screenshot 2024-04-03 at 11 55 17 AM

Producers are all listed as Observability so we don't get the categories present on the traditional system. I'll open an issue around that.

@Zacqary
Copy link
Contributor Author

Zacqary commented Apr 3, 2024

@jasonrhodes Tracking the serverless category issue in #179963

@Zacqary Zacqary merged commit 658cbde into elastic:main Apr 3, 2024
17 checks passed
@kibanamachine kibanamachine added the backport:skip This commit does not require backporting label Apr 3, 2024
@jasonrhodes
Copy link
Member

@vinaychandrasekhar please see above answers, thanks!

@jasonrhodes
Copy link
Member

I spoke with @vinaychandrasekhar and we both agree, we're good with this shipping in 8.14, provided categorization is removed from the flyout for observability context. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting Feature:Alerting/RulesManagement Issues related to the Rules Management UX release_note:feature Makes this part of the condensed release notes Team:obs-ux-management Observability Management User Experience Team Team:ResponseOps Label for the ResponseOps team (formerly the Cases and Alerting teams) v8.14.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[RAM] [Rule Form V2] Add rule type selection modal
10 participants