[AI4DSOC][Security Solution] Extract takeActions logic outside the detections grouping alerts table#219878
Merged
PhilippeOberti merged 2 commits intoelastic:mainfrom May 2, 2025
Conversation
PhilippeOberti
added
release_note:skip
Collaborator
🎉 Snyk checks have passed. No issues have been found so far.✅ security/snyk check is complete. No issues have been found. (View Details) ✅ license/snyk check is complete. No issues have been found. (View Details) |
PhilippeOberti
added
the
Team:Threat Hunting:Investigations
PhilippeOberti
force-pushed
the
take-action-grouping-table
branch
from
7972d07 to
43b8200
Compare
Contributor
|
Pinging @elastic/security-threat-hunting-investigations (Team:Threat Hunting:Investigations) |
maximpn
approved these changes
May 2, 2025
Contributor
maximpn
left a comment
maximpn
left a comment
There was a problem hiding this comment.
@PhilippeOberti I looked through the diff and I haven't found anything critical. Local testing confirmed the take action context menu works as expected on the alert table.
I left comments concerning code readability.
...ugins/security_solution/public/detection_engine/rule_details_ui/pages/rule_details/index.tsx
Outdated
Show resolved
Hide resolved
.../plugins/security_solution/public/detections/components/alerts_table/alerts_sub_grouping.tsx
Outdated
Show resolved
Hide resolved
.../plugins/security_solution/public/detections/components/alerts_table/alerts_sub_grouping.tsx
Outdated
Show resolved
Hide resolved
...rity/plugins/security_solution/public/detections/components/alerts_table/alerts_grouping.tsx
Outdated
Show resolved
Hide resolved
...ugins/security_solution/public/detections/hooks/alerts_table/use_group_take_action_items.tsx
Show resolved
Hide resolved
...ugins/security_solution/public/detections/hooks/alerts_table/use_group_take_action_items.tsx
Show resolved
Hide resolved
...ugins/security_solution/public/detections/hooks/alerts_table/use_group_take_action_items.tsx
Outdated
Show resolved
Hide resolved
...ugins/security_solution/public/detection_engine/rule_details_ui/pages/rule_details/index.tsx
Show resolved
Hide resolved
…tections grouping alerts table
PhilippeOberti
force-pushed
the
take-action-grouping-table
branch
from
43b8200 to
4022b66
Compare
Contributor
💛 Build succeeded, but was flaky
Failed CI StepsMetrics [docs]Async chunks
Page load bundle
History
|
christineweng
approved these changes
May 2, 2025
Contributor
christineweng
left a comment
christineweng
left a comment
There was a problem hiding this comment.
Thanks for cleaning this up!
Contributor
|
Starting backport for target branches: 8.19 https://github.com/elastic/kibana/actions/runs/14802391800 |
Contributor
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
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
that referenced
this pull request
May 2, 2025
… the detections grouping alerts table (#219878) (#220001) # Backport This will backport the following commits from `main` to `8.19`: - [[AI4DSOC][Security Solution] Extract takeActions logic outside the detections grouping alerts table (#219878)](#219878) <!--- Backport version: 9.6.6 --> ### 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-02T19:57:41Z","message":"[AI4DSOC][Security Solution] Extract takeActions logic outside the detections grouping alerts table (#219878)\n\n## Summary\n\nThis PR continues the effort started in [this previous\nPR](#216572). The AI4DSOC effort\nrevealed a limitation with the current GroupedAlertsTable: it currently\nalways displays the `Take actions` button at each group level, and the\navailable actions are\n- Mark as opened\n- Mark as acknowledged\n- Marck as closed\n\nIn AI4DSOC though those actions are not available.\n\nWhile it would have been easy and simple to just disable the actions\nsomehow internally to the GroupedAlertsTable, this is not the correct\napproach. Like done in the prior PR mentioned above, the approach here\nconsists of making this an opt-in prop to the component. This means that\nwe now have a new `groupTakeActionItems` prop that developers have to\nprovide if they want the `Take actions` button to be displayed. This\n`groupTakeActionItems` will return n array of `EuiContextMenuItem`\ncomponents that will be rendered in the menu\n\n**_The 3 places where this `Take actions` exist today have been updated\naccordingly, to ensure to change in the logic or UI:_**\n- alerts table\n- rule details page\n- entity analytis risk score\n\n\nhttps://github.com/user-attachments/assets/24ff489d-ca66-457d-bd03-f09a04f67d2a\n\n\nhttps://github.com/user-attachments/assets/9324029d-f653-42bd-bca1-73a25d46c476\n\n**_The Alert summary page visible in AI4DSOC (`searchAiLake` tier) no\nlonger displays the `Take actions` button._**\n\n\n\n### Notes\n\nSome code documentation and very minor cleanup was also performed.\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\n\nRelates to https://github.com/elastic/security-team/issues/11973","sha":"22fbe0087da0e7aaf7284e413db3aa9bee387aea","branchLabelMapping":{"^v9.1.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:Threat Hunting:Investigations","backport:version","v9.1.0","v8.19.0"],"title":"[AI4DSOC][Security Solution] Extract takeActions logic outside the detections grouping alerts table","number":219878,"url":"https://github.com/elastic/kibana/pull/219878","mergeCommit":{"message":"[AI4DSOC][Security Solution] Extract takeActions logic outside the detections grouping alerts table (#219878)\n\n## Summary\n\nThis PR continues the effort started in [this previous\nPR](#216572). The AI4DSOC effort\nrevealed a limitation with the current GroupedAlertsTable: it currently\nalways displays the `Take actions` button at each group level, and the\navailable actions are\n- Mark as opened\n- Mark as acknowledged\n- Marck as closed\n\nIn AI4DSOC though those actions are not available.\n\nWhile it would have been easy and simple to just disable the actions\nsomehow internally to the GroupedAlertsTable, this is not the correct\napproach. Like done in the prior PR mentioned above, the approach here\nconsists of making this an opt-in prop to the component. This means that\nwe now have a new `groupTakeActionItems` prop that developers have to\nprovide if they want the `Take actions` button to be displayed. This\n`groupTakeActionItems` will return n array of `EuiContextMenuItem`\ncomponents that will be rendered in the menu\n\n**_The 3 places where this `Take actions` exist today have been updated\naccordingly, to ensure to change in the logic or UI:_**\n- alerts table\n- rule details page\n- entity analytis risk score\n\n\nhttps://github.com/user-attachments/assets/24ff489d-ca66-457d-bd03-f09a04f67d2a\n\n\nhttps://github.com/user-attachments/assets/9324029d-f653-42bd-bca1-73a25d46c476\n\n**_The Alert summary page visible in AI4DSOC (`searchAiLake` tier) no\nlonger displays the `Take actions` button._**\n\n\n\n### Notes\n\nSome code documentation and very minor cleanup was also performed.\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\n\nRelates to https://github.com/elastic/security-team/issues/11973","sha":"22fbe0087da0e7aaf7284e413db3aa9bee387aea"}},"sourceBranch":"main","suggestedTargetBranches":["8.19"],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/219878","number":219878,"mergeCommit":{"message":"[AI4DSOC][Security Solution] Extract takeActions logic outside the detections grouping alerts table (#219878)\n\n## Summary\n\nThis PR continues the effort started in [this previous\nPR](#216572). The AI4DSOC effort\nrevealed a limitation with the current GroupedAlertsTable: it currently\nalways displays the `Take actions` button at each group level, and the\navailable actions are\n- Mark as opened\n- Mark as acknowledged\n- Marck as closed\n\nIn AI4DSOC though those actions are not available.\n\nWhile it would have been easy and simple to just disable the actions\nsomehow internally to the GroupedAlertsTable, this is not the correct\napproach. Like done in the prior PR mentioned above, the approach here\nconsists of making this an opt-in prop to the component. This means that\nwe now have a new `groupTakeActionItems` prop that developers have to\nprovide if they want the `Take actions` button to be displayed. This\n`groupTakeActionItems` will return n array of `EuiContextMenuItem`\ncomponents that will be rendered in the menu\n\n**_The 3 places where this `Take actions` exist today have been updated\naccordingly, to ensure to change in the logic or UI:_**\n- alerts table\n- rule details page\n- entity analytis risk score\n\n\nhttps://github.com/user-attachments/assets/24ff489d-ca66-457d-bd03-f09a04f67d2a\n\n\nhttps://github.com/user-attachments/assets/9324029d-f653-42bd-bca1-73a25d46c476\n\n**_The Alert summary page visible in AI4DSOC (`searchAiLake` tier) no\nlonger displays the `Take actions` button._**\n\n\n\n### Notes\n\nSome code documentation and very minor cleanup was also performed.\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\n\nRelates to https://github.com/elastic/security-team/issues/11973","sha":"22fbe0087da0e7aaf7284e413db3aa9bee387aea"}},{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT-->
1 task
PhilippeOberti
added a commit
that referenced
this pull request
May 23, 2025
## Summary Similar to the following previous PRs([this one](#216572) and [that one](#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
akowalska622
pushed a commit
to akowalska622/kibana
that referenced
this pull request
May 29, 2025
…tections grouping alerts table (elastic#219878) ## Summary This PR continues the effort started in [this previous PR](elastic#216572). The AI4DSOC effort revealed a limitation with the current GroupedAlertsTable: it currently always displays the `Take actions` button at each group level, and the available actions are - Mark as opened - Mark as acknowledged - Marck as closed In AI4DSOC though those actions are not available. While it would have been easy and simple to just disable the actions somehow internally to the GroupedAlertsTable, this is not the correct approach. Like done in the prior PR mentioned above, the approach here consists of making this an opt-in prop to the component. This means that we now have a new `groupTakeActionItems` prop that developers have to provide if they want the `Take actions` button to be displayed. This `groupTakeActionItems` will return n array of `EuiContextMenuItem` components that will be rendered in the menu **_The 3 places where this `Take actions` exist today have been updated accordingly, to ensure to change in the logic or UI:_** - alerts table - rule details page - entity analytis risk score https://github.com/user-attachments/assets/24ff489d-ca66-457d-bd03-f09a04f67d2a https://github.com/user-attachments/assets/9324029d-f653-42bd-bca1-73a25d46c476 **_The Alert summary page visible in AI4DSOC (`searchAiLake` tier) no longer displays the `Take actions` button._**  ### Notes Some code documentation and very minor cleanup was also performed. ### 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 Relates to elastic/security-team#11973
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
qn895
pushed a commit
to qn895/kibana
that referenced
this pull request
Jun 3, 2025
…tections grouping alerts table (elastic#219878) ## Summary This PR continues the effort started in [this previous PR](elastic#216572). The AI4DSOC effort revealed a limitation with the current GroupedAlertsTable: it currently always displays the `Take actions` button at each group level, and the available actions are - Mark as opened - Mark as acknowledged - Marck as closed In AI4DSOC though those actions are not available. While it would have been easy and simple to just disable the actions somehow internally to the GroupedAlertsTable, this is not the correct approach. Like done in the prior PR mentioned above, the approach here consists of making this an opt-in prop to the component. This means that we now have a new `groupTakeActionItems` prop that developers have to provide if they want the `Take actions` button to be displayed. This `groupTakeActionItems` will return n array of `EuiContextMenuItem` components that will be rendered in the menu **_The 3 places where this `Take actions` exist today have been updated accordingly, to ensure to change in the logic or UI:_** - alerts table - rule details page - entity analytis risk score https://github.com/user-attachments/assets/24ff489d-ca66-457d-bd03-f09a04f67d2a https://github.com/user-attachments/assets/9324029d-f653-42bd-bca1-73a25d46c476 **_The Alert summary page visible in AI4DSOC (`searchAiLake` tier) no longer displays the `Take actions` button._**  ### Notes Some code documentation and very minor cleanup was also performed. ### 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 Relates to elastic/security-team#11973
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-->
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
7 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
This PR continues the effort started in this previous PR. The AI4DSOC effort revealed a limitation with the current GroupedAlertsTable: it currently always displays the
Take actionsbutton at each group level, and the available actions areIn AI4DSOC though those actions are not available.
While it would have been easy and simple to just disable the actions somehow internally to the GroupedAlertsTable, this is not the correct approach. Like done in the prior PR mentioned above, the approach here consists of making this an opt-in prop to the component. This means that we now have a new
groupTakeActionItemsprop that developers have to provide if they want theTake actionsbutton to be displayed. ThisgroupTakeActionItemswill return n array ofEuiContextMenuItemcomponents that will be rendered in the menuThe 3 places where this
Take actionsexist today have been updated accordingly, to ensure to change in the logic or UI:group_take_action-alerts_page.mov
group_take_action-rule-details-page.mov
The Alert summary page visible in AI4DSOC (
searchAiLaketier) no longer displays theTake actionsbutton.Notes
Some code documentation and very minor cleanup was also performed.
Checklist
Relates to https://github.com/elastic/security-team/issues/11973