-
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
[Security Solution] Coverage Overview Dashboard #161556
[Security Solution] Coverage Overview Dashboard #161556
Conversation
Pinging @elastic/security-solution (Team: SecuritySolution) |
Pinging @elastic/security-detections-response (Team:Detections and Resp) |
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.
@dplumlee thank you for implementing such a complex dashboard 👍
I like that you reused EUI components as much as possible to avoid building custom components and properly split the business logic between the components. It's clear what component responsible for what functionality.
Some time was spend to test the implementation so I revealed some problems
- Enable All Disabled rules does nothing. Basically it should be quite straightforward to implement this functionality via bulk actions. It feel like it should be part of this PR. If you wanna split it just don't forget to add a note about it.
- Dashboard's page opens with a delay when clicked on the dashboard's card on the security's dashboard page. It's better to double check on the cause as if it takes too much time without any visual updates users may complain. Or it can tell about performance issues.
- There is no visual loading state when loading the page and switching between collapsed and expanded state. Switching doesn't happed instantly and may be an issue.
- Everything related to available rules should be removed from UI as it's not required for milestone 1.
On top of that I've noticed
memo()
component's wrapper used withuseMemo()
but it's unclear if it gives some improvement. I'd verify it as we may have a performance issue.styled-components
used for custom styles instead of emotion. As EUI plans to use only emotion we could follow the same way and avoid styled-component in the new code for now.- Unit tests testing the component renders don't actually give good coverage. Let's remove them or add useful scenarios.
...urity_solution/public/detection_engine/rule_management_ui/pages/coverage_overview/helpers.ts
Outdated
Show resolved
Hide resolved
...urity_solution/public/detection_engine/rule_management_ui/pages/coverage_overview/helpers.ts
Outdated
Show resolved
Hide resolved
...urity_solution/public/detection_engine/rule_management_ui/pages/coverage_overview/helpers.ts
Outdated
Show resolved
Hide resolved
...urity_solution/public/detection_engine/rule_management_ui/pages/coverage_overview/helpers.ts
Outdated
Show resolved
Hide resolved
...curity_solution/public/detection_engine/rule_management_ui/pages/coverage_overview/index.tsx
Outdated
Show resolved
Hide resolved
* | ||
* @returns A coverage overview cache invalidation callback | ||
*/ | ||
export const useInvalidateFetchCoverageOverviewQuery = () => { |
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.
useInvalidateFetchCoverageOverviewQuery
has to be call upon rule creation (prebuilt rules installation), deletion, enabling and disabling as it impacts the dashboard. On top of that rule editing may change MITRE ATT&CK bindings so it also should be taken into account.
For example check where useInvalidateFindRulesQuery
used so it will help to find proper places for coverage overview invalidation.
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.
I think all these locations have been taken care of now
); | ||
}; | ||
|
||
export const CoverageOverviewFiltersPanel = memo(CoverageOverviewFiltersPanelComponent); |
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.
Obviously having all components wrapped in memo()
and additionally use useMemo()
in CoverageOverviewPageComponent
won't improve performance. The main performance hit is reflow and we have to avoid it whenever possible so having an extra render usually might not be an issue.
Ideally we need to compare performance without using memo
and useMemo
and with them to see if we improve something as it doesn't work when references aren't stable and change each render.
It should be safe to get rid of memo()
wrapper around components in the folder.
...blic/detection_engine/rule_management_ui/pages/coverage_overview/technique_panel_popover.tsx
Outdated
Show resolved
Hide resolved
...blic/detection_engine/rule_management_ui/pages/coverage_overview/technique_panel_popover.tsx
Outdated
Show resolved
Hide resolved
@elasticmachine merge upstream |
@elasticmachine merge upstream |
expected head sha didn’t match current head ref. |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
@elasticmachine merge upstream |
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
History
To update your PR or re-run it, just comment with: cc @dplumlee |
Summary
Addresses #158243
Creates first stage of the coverage overview dashboard and integrates it with the corresponding API.
Screenshots
Checklist
Delete any items that are not applicable to this PR.
For maintainers