[Security Solution] extract dataView from GroupedAlertsTable#220681
Merged
PhilippeOberti merged 3 commits intoelastic:mainfrom May 23, 2025
Merged
Conversation
PhilippeOberti
force-pushed
the
extract-dataview-from-groupedalertstable
branch
from
3df9db9 to
2b5895c
Compare
PhilippeOberti
added
release_note:skip
Contributor
|
Pinging @elastic/security-threat-hunting-investigations (Team:Threat Hunting:Investigations) |
PhilippeOberti
force-pushed
the
extract-dataview-from-groupedalertstable
branch
2 times, most recently
from
01d5e74 to
1e560c1
Compare
janmonschke
reviewed
May 12, 2025
...rity/plugins/security_solution/public/detections/components/alerts_table/alerts_grouping.tsx
Outdated
Show resolved
Hide resolved
janmonschke
approved these changes
May 12, 2025
Contributor
janmonschke
left a comment
janmonschke
left a comment
There was a problem hiding this comment.
One small comment about useMemo but looks good otherwise
PhilippeOberti
force-pushed
the
extract-dataview-from-groupedalertstable
branch
from
1e560c1 to
ceaed6a
Compare
jkelas
reviewed
May 20, 2025
Contributor
jkelas
left a comment
jkelas
left a comment
There was a problem hiding this comment.
I checked that the functionality in the Rules Details pages works as expected, no UI changes were introduced, all looks good. The code is fine.
However, I would like to use more consistent naming for variables, please see my comment in the file.
...ugins/security_solution/public/detection_engine/rule_details_ui/pages/rule_details/index.tsx
Show resolved
Hide resolved
jkelas
approved these changes
May 23, 2025
Contributor
jkelas
left a comment
jkelas
left a comment
There was a problem hiding this comment.
The code is fine, the behavior is as expected, and my doubt about naming inconsistency was cleared by the author, so I am approving the PR.
Contributor
💚 Build Succeeded
Metrics [docs]Async chunks
History
|
akowalska622
pushed a commit
to akowalska622/kibana
that referenced
this pull request
May 29, 2025
…#220681) ## Summary Similar to the following previous PRs([this one](elastic#216572) and [that one](elastic#219878)), this PR aims at removing some logic built-in to the `GroupedAlertsTable` and pass the information via props. It makes this reusable component a lot easier to use in different scenarios. In this current case, we're removing the retrieval of the dataView within the `GroupedAlertsTable`. We now rely on the `DataViewSpec` object passed via prop instead. This allows us to get rid of the following props: - `signalIndexName`, which we now retrieve from the DataViewSpec object directly - `runtimeMappings`, which we also now retrieve from the DataViewSpec object directly This solves one issue, which was related to the fact that the `GroupedAlertsTable` was retrieving the `detections` dataView internally, so there was a high chance that the `signalIndexName` and `runtimeMappins` passed via props would not match the hardcoded `detections` dataView retrieved internally... which is very confusing! We are having this problem in the AI4DSOC Alert summary page, which creates a adhoc dataView just for alerts... **_No UI or behavior change are introduced in this PR!_** Alerts page https://github.com/user-attachments/assets/a4e0c1a6-fa91-4b1e-881c-56d95667e84b Rule details page https://github.com/user-attachments/assets/6d93e7d0-0446-4ecb-aa37-4ab266b62686 AI4DSOC Alert summary page https://github.com/user-attachments/assets/7354bad2-64d1-4722-94c3-ae2d9b72fcab ### 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
Contributor
Author
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
PhilippeOberti
added a commit
to PhilippeOberti/kibana
that referenced
this pull request
Jun 3, 2025
…#220681) ## Summary Similar to the following previous PRs([this one](elastic#216572) and [that one](elastic#219878)), this PR aims at removing some logic built-in to the `GroupedAlertsTable` and pass the information via props. It makes this reusable component a lot easier to use in different scenarios. In this current case, we're removing the retrieval of the dataView within the `GroupedAlertsTable`. We now rely on the `DataViewSpec` object passed via prop instead. This allows us to get rid of the following props: - `signalIndexName`, which we now retrieve from the DataViewSpec object directly - `runtimeMappings`, which we also now retrieve from the DataViewSpec object directly This solves one issue, which was related to the fact that the `GroupedAlertsTable` was retrieving the `detections` dataView internally, so there was a high chance that the `signalIndexName` and `runtimeMappins` passed via props would not match the hardcoded `detections` dataView retrieved internally... which is very confusing! We are having this problem in the AI4DSOC Alert summary page, which creates a adhoc dataView just for alerts... **_No UI or behavior change are introduced in this PR!_** Alerts page https://github.com/user-attachments/assets/a4e0c1a6-fa91-4b1e-881c-56d95667e84b Rule details page https://github.com/user-attachments/assets/6d93e7d0-0446-4ecb-aa37-4ab266b62686 AI4DSOC Alert summary page https://github.com/user-attachments/assets/7354bad2-64d1-4722-94c3-ae2d9b72fcab ### 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 (cherry picked from commit 8ca9057) # Conflicts: # x-pack/solutions/security/plugins/security_solution/public/data_view_manager/hooks/use_data_view_spec.ts # x-pack/solutions/security/plugins/security_solution/public/detection_engine/rule_details_ui/pages/rule_details/index.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/components/alert_summary/table/table_section.test.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/components/alert_summary/table/table_section.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/components/alerts_table/alerts_grouping.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/pages/alerts/detection_engine.tsx # x-pack/solutions/security/plugins/security_solution/public/entity_analytics/components/top_risk_score_contributors_alerts/index.tsx
PhilippeOberti
added a commit
to PhilippeOberti/kibana
that referenced
this pull request
Jun 3, 2025
…#220681) ## Summary Similar to the following previous PRs([this one](elastic#216572) and [that one](elastic#219878)), this PR aims at removing some logic built-in to the `GroupedAlertsTable` and pass the information via props. It makes this reusable component a lot easier to use in different scenarios. In this current case, we're removing the retrieval of the dataView within the `GroupedAlertsTable`. We now rely on the `DataViewSpec` object passed via prop instead. This allows us to get rid of the following props: - `signalIndexName`, which we now retrieve from the DataViewSpec object directly - `runtimeMappings`, which we also now retrieve from the DataViewSpec object directly This solves one issue, which was related to the fact that the `GroupedAlertsTable` was retrieving the `detections` dataView internally, so there was a high chance that the `signalIndexName` and `runtimeMappins` passed via props would not match the hardcoded `detections` dataView retrieved internally... which is very confusing! We are having this problem in the AI4DSOC Alert summary page, which creates a adhoc dataView just for alerts... **_No UI or behavior change are introduced in this PR!_** Alerts page https://github.com/user-attachments/assets/a4e0c1a6-fa91-4b1e-881c-56d95667e84b Rule details page https://github.com/user-attachments/assets/6d93e7d0-0446-4ecb-aa37-4ab266b62686 AI4DSOC Alert summary page https://github.com/user-attachments/assets/7354bad2-64d1-4722-94c3-ae2d9b72fcab ### 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 (cherry picked from commit 8ca9057) # Conflicts: # x-pack/solutions/security/plugins/security_solution/public/data_view_manager/hooks/use_data_view_spec.ts # x-pack/solutions/security/plugins/security_solution/public/detection_engine/rule_details_ui/pages/rule_details/index.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/components/alert_summary/table/table_section.test.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/components/alert_summary/table/table_section.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/components/alerts_table/alerts_grouping.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/pages/alerts/detection_engine.tsx # x-pack/solutions/security/plugins/security_solution/public/entity_analytics/components/top_risk_score_contributors_alerts/index.tsx
PhilippeOberti
added a commit
to PhilippeOberti/kibana
that referenced
this pull request
Jun 3, 2025
…#220681) ## Summary Similar to the following previous PRs([this one](elastic#216572) and [that one](elastic#219878)), this PR aims at removing some logic built-in to the `GroupedAlertsTable` and pass the information via props. It makes this reusable component a lot easier to use in different scenarios. In this current case, we're removing the retrieval of the dataView within the `GroupedAlertsTable`. We now rely on the `DataViewSpec` object passed via prop instead. This allows us to get rid of the following props: - `signalIndexName`, which we now retrieve from the DataViewSpec object directly - `runtimeMappings`, which we also now retrieve from the DataViewSpec object directly This solves one issue, which was related to the fact that the `GroupedAlertsTable` was retrieving the `detections` dataView internally, so there was a high chance that the `signalIndexName` and `runtimeMappins` passed via props would not match the hardcoded `detections` dataView retrieved internally... which is very confusing! We are having this problem in the AI4DSOC Alert summary page, which creates a adhoc dataView just for alerts... **_No UI or behavior change are introduced in this PR!_** Alerts page https://github.com/user-attachments/assets/a4e0c1a6-fa91-4b1e-881c-56d95667e84b Rule details page https://github.com/user-attachments/assets/6d93e7d0-0446-4ecb-aa37-4ab266b62686 AI4DSOC Alert summary page https://github.com/user-attachments/assets/7354bad2-64d1-4722-94c3-ae2d9b72fcab ### 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 (cherry picked from commit 8ca9057) # Conflicts: # x-pack/solutions/security/plugins/security_solution/public/data_view_manager/hooks/use_data_view_spec.ts # x-pack/solutions/security/plugins/security_solution/public/detection_engine/rule_details_ui/pages/rule_details/index.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/components/alert_summary/table/table_section.test.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/components/alert_summary/table/table_section.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/components/alerts_table/alerts_grouping.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/pages/alerts/detection_engine.tsx # x-pack/solutions/security/plugins/security_solution/public/entity_analytics/components/top_risk_score_contributors_alerts/index.tsx
PhilippeOberti
added a commit
to PhilippeOberti/kibana
that referenced
this pull request
Jun 4, 2025
…#220681) ## Summary Similar to the following previous PRs([this one](elastic#216572) and [that one](elastic#219878)), this PR aims at removing some logic built-in to the `GroupedAlertsTable` and pass the information via props. It makes this reusable component a lot easier to use in different scenarios. In this current case, we're removing the retrieval of the dataView within the `GroupedAlertsTable`. We now rely on the `DataViewSpec` object passed via prop instead. This allows us to get rid of the following props: - `signalIndexName`, which we now retrieve from the DataViewSpec object directly - `runtimeMappings`, which we also now retrieve from the DataViewSpec object directly This solves one issue, which was related to the fact that the `GroupedAlertsTable` was retrieving the `detections` dataView internally, so there was a high chance that the `signalIndexName` and `runtimeMappins` passed via props would not match the hardcoded `detections` dataView retrieved internally... which is very confusing! We are having this problem in the AI4DSOC Alert summary page, which creates a adhoc dataView just for alerts... **_No UI or behavior change are introduced in this PR!_** Alerts page https://github.com/user-attachments/assets/a4e0c1a6-fa91-4b1e-881c-56d95667e84b Rule details page https://github.com/user-attachments/assets/6d93e7d0-0446-4ecb-aa37-4ab266b62686 AI4DSOC Alert summary page https://github.com/user-attachments/assets/7354bad2-64d1-4722-94c3-ae2d9b72fcab ### 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 (cherry picked from commit 8ca9057) # Conflicts: # x-pack/solutions/security/plugins/security_solution/public/data_view_manager/hooks/use_data_view_spec.ts # x-pack/solutions/security/plugins/security_solution/public/detection_engine/rule_details_ui/pages/rule_details/index.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/components/alert_summary/table/table_section.test.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/components/alert_summary/table/table_section.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/components/alerts_table/alerts_grouping.tsx # x-pack/solutions/security/plugins/security_solution/public/detections/pages/alerts/detection_engine.tsx # x-pack/solutions/security/plugins/security_solution/public/entity_analytics/components/top_risk_score_contributors_alerts/index.tsx
PhilippeOberti
added a commit
that referenced
this pull request
Jun 4, 2025
…220681) (#222475) # Backport This will backport the following commits from `main` to `8.19`: - [[Security Solution] extract dataView from GroupedAlertsTable (#220681)](#220681) <!--- Backport version: 10.0.0 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Philippe Oberti","email":"philippe.oberti@elastic.co"},"sourceCommit":{"committedDate":"2025-05-23T17:03:49Z","message":"[Security Solution] extract dataView from GroupedAlertsTable (#220681)\n\n## Summary\n\nSimilar to the following previous PRs([this\none](#216572) and [that\none](#219878)), this PR aims at\nremoving some logic built-in to the `GroupedAlertsTable` and pass the\ninformation via props. It makes this reusable component a lot easier to\nuse in different scenarios.\n\nIn this current case, we're removing the retrieval of the dataView\nwithin the `GroupedAlertsTable`. We now rely on the `DataViewSpec`\nobject passed via prop instead. This allows us to get rid of the\nfollowing props:\n- `signalIndexName`, which we now retrieve from the DataViewSpec object\ndirectly\n- `runtimeMappings`, which we also now retrieve from the DataViewSpec\nobject directly\n\nThis solves one issue, which was related to the fact that the\n`GroupedAlertsTable` was retrieving the `detections` dataView\ninternally, so there was a high chance that the `signalIndexName` and\n`runtimeMappins` passed via props would not match the hardcoded\n`detections` dataView retrieved internally... which is very confusing!\nWe are having this problem in the AI4DSOC Alert summary page, which\ncreates a adhoc dataView just for alerts...\n\n**_No UI or behavior change are introduced in this PR!_**\n\nAlerts page\n\n\nhttps://github.com/user-attachments/assets/a4e0c1a6-fa91-4b1e-881c-56d95667e84b\n\nRule details page\n\n\nhttps://github.com/user-attachments/assets/6d93e7d0-0446-4ecb-aa37-4ab266b62686\n\nAI4DSOC Alert summary page\n\n\nhttps://github.com/user-attachments/assets/7354bad2-64d1-4722-94c3-ae2d9b72fcab\n\n### Checklist\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios","sha":"8ca90573d6266dbad79db14839c5363b23a084d3","branchLabelMapping":{"^v9.1.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","backport:skip","Team:Threat Hunting:Investigations","v9.1.0"],"title":"[Security Solution] extract dataView from GroupedAlertsTable","number":220681,"url":"https://github.com/elastic/kibana/pull/220681","mergeCommit":{"message":"[Security Solution] extract dataView from GroupedAlertsTable (#220681)\n\n## Summary\n\nSimilar to the following previous PRs([this\none](#216572) and [that\none](#219878)), this PR aims at\nremoving some logic built-in to the `GroupedAlertsTable` and pass the\ninformation via props. It makes this reusable component a lot easier to\nuse in different scenarios.\n\nIn this current case, we're removing the retrieval of the dataView\nwithin the `GroupedAlertsTable`. We now rely on the `DataViewSpec`\nobject passed via prop instead. This allows us to get rid of the\nfollowing props:\n- `signalIndexName`, which we now retrieve from the DataViewSpec object\ndirectly\n- `runtimeMappings`, which we also now retrieve from the DataViewSpec\nobject directly\n\nThis solves one issue, which was related to the fact that the\n`GroupedAlertsTable` was retrieving the `detections` dataView\ninternally, so there was a high chance that the `signalIndexName` and\n`runtimeMappins` passed via props would not match the hardcoded\n`detections` dataView retrieved internally... which is very confusing!\nWe are having this problem in the AI4DSOC Alert summary page, which\ncreates a adhoc dataView just for alerts...\n\n**_No UI or behavior change are introduced in this PR!_**\n\nAlerts page\n\n\nhttps://github.com/user-attachments/assets/a4e0c1a6-fa91-4b1e-881c-56d95667e84b\n\nRule details page\n\n\nhttps://github.com/user-attachments/assets/6d93e7d0-0446-4ecb-aa37-4ab266b62686\n\nAI4DSOC Alert summary page\n\n\nhttps://github.com/user-attachments/assets/7354bad2-64d1-4722-94c3-ae2d9b72fcab\n\n### Checklist\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios","sha":"8ca90573d6266dbad79db14839c5363b23a084d3"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/220681","number":220681,"mergeCommit":{"message":"[Security Solution] extract dataView from GroupedAlertsTable (#220681)\n\n## Summary\n\nSimilar to the following previous PRs([this\none](#216572) and [that\none](#219878)), this PR aims at\nremoving some logic built-in to the `GroupedAlertsTable` and pass the\ninformation via props. It makes this reusable component a lot easier to\nuse in different scenarios.\n\nIn this current case, we're removing the retrieval of the dataView\nwithin the `GroupedAlertsTable`. We now rely on the `DataViewSpec`\nobject passed via prop instead. This allows us to get rid of the\nfollowing props:\n- `signalIndexName`, which we now retrieve from the DataViewSpec object\ndirectly\n- `runtimeMappings`, which we also now retrieve from the DataViewSpec\nobject directly\n\nThis solves one issue, which was related to the fact that the\n`GroupedAlertsTable` was retrieving the `detections` dataView\ninternally, so there was a high chance that the `signalIndexName` and\n`runtimeMappins` passed via props would not match the hardcoded\n`detections` dataView retrieved internally... which is very confusing!\nWe are having this problem in the AI4DSOC Alert summary page, which\ncreates a adhoc dataView just for alerts...\n\n**_No UI or behavior change are introduced in this PR!_**\n\nAlerts page\n\n\nhttps://github.com/user-attachments/assets/a4e0c1a6-fa91-4b1e-881c-56d95667e84b\n\nRule details page\n\n\nhttps://github.com/user-attachments/assets/6d93e7d0-0446-4ecb-aa37-4ab266b62686\n\nAI4DSOC Alert summary page\n\n\nhttps://github.com/user-attachments/assets/7354bad2-64d1-4722-94c3-ae2d9b72fcab\n\n### Checklist\n\n- [x] [Unit or functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere updated or added to match the most common scenarios","sha":"8ca90573d6266dbad79db14839c5363b23a084d3"}}]}] BACKPORT-->
delanni
added a commit
that referenced
this pull request
Jun 5, 2025
## Summary There's a type error on 8.19 coming from a backport that didn't apply on a file. Probably the file wasn't present at the time when the backport was issued. As a solution I've copied the state of the file and it's unit test from main. (cc: @PhilippeOberti ) Original PR: #220681 Backport PR: #222475
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Similar to the following previous PRs(this one and that one), this PR aims at removing some logic built-in to the
GroupedAlertsTableand pass the information via props. It makes this reusable component a lot easier to use in different scenarios.In this current case, we're removing the retrieval of the dataView within the
GroupedAlertsTable. We now rely on theDataViewSpecobject passed via prop instead. This allows us to get rid of the following props:signalIndexName, which we now retrieve from the DataViewSpec object directlyruntimeMappings, which we also now retrieve from the DataViewSpec object directlyThis solves one issue, which was related to the fact that the
GroupedAlertsTablewas retrieving thedetectionsdataView internally, so there was a high chance that thesignalIndexNameandruntimeMappinspassed via props would not match the hardcodeddetectionsdataView retrieved internally... which is very confusing!We are having this problem in the AI4DSOC Alert summary page, which creates a adhoc dataView just for alerts...
No UI or behavior change are introduced in this PR!
Alerts page
Screen.Recording.2025-05-09.at.2.45.02.PM.mov
Rule details page
Screen.Recording.2025-05-09.at.2.45.23.PM.mov
AI4DSOC Alert summary page
Screen.Recording.2025-05-09.at.2.47.01.PM.mov
Checklist