-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[RAM] [Rule Form V2] Add new rule type selection modal #179285
Conversation
…lection-modal # Conflicts: # x-pack/plugins/observability_solution/observability/public/pages/rules/rules.tsx
🤖 GitHub commentsExpand to view the GitHub comments
Just comment with:
|
Pinging @elastic/response-ops (Team:ResponseOps) |
Pinging @elastic/obs-ux-management-team (Team:obs-ux-management) |
@Zacqary When I run this branch locally, I see some errors in Kibana server, do you get the same locally?
|
@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 |
There was a problem hiding this 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.
@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. |
There was a problem hiding this 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
@elasticmachine merge upstream |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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. |
...s/kbn-alerts-ui-shared/src/rule_type_modal/components/helpers/filter_and_count_rule_types.ts
Outdated
Show resolved
Hide resolved
} | ||
return true; | ||
}); | ||
const ruleTypesFilteredBySearchAndProducer = ruleTypesFilteredBySearch.filter((ruleType) => { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
packages/kbn-alerts-ui-shared/src/rule_type_modal/components/index.tsx
Outdated
Show resolved
Hide resolved
packages/kbn-alerts-ui-shared/src/rule_type_modal/components/index.tsx
Outdated
Show resolved
Hide resolved
registeredRuleTypes, | ||
...props | ||
}) => { | ||
const [selectedProducer, setSelectedProducer] = useState<string | null>(null); |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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
packages/kbn-alerts-ui-shared/src/rule_type_modal/components/rule_type_list.tsx
Outdated
Show resolved
Hide resolved
} | ||
|
||
const producerToDisplayName = (producer: string) => { | ||
return Reflect.get(PRODUCER_DISPLAY_NAMES, producer) ?? producer; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
packages/kbn-alerts-ui-shared/src/rule_type_modal/components/rule_type_list.tsx
Outdated
Show resolved
Hide resolved
packages/kbn-alerts-ui-shared/src/rule_type_modal/components/rule_type_list.tsx
Outdated
Show resolved
Hide resolved
packages/kbn-alerts-ui-shared/src/rule_type_modal/components/rule_type_modal.tsx
Outdated
Show resolved
Hide resolved
💚 Build Succeeded
Metrics [docs]Module Count
Public APIs missing comments
Async chunks
Public APIs missing exports
Page load bundle
History
To update your PR or re-run it, just comment with: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Questions from our alerting weekly meeting:
|
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))
);
}
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. |
@jasonrhodes Tracking the serverless category issue in #179963 |
@vinaychandrasekhar please see above answers, thanks! |
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! |
Summary
Closes #179104
Stack Management Rules Page
Screen.Recording.2024-03-22.at.1.51.06.PM.mov
Observability Rules Page
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.