[Security Solution][Grouped table] allow changing default groups, buttonContent and extraAction via props (for AI4DSOC)#216572
Merged
PhilippeOberti merged 6 commits intoelastic:mainfrom Apr 3, 2025
Conversation
Contributor
Author
Files by Code Ownerelastic/kibana-localization
elastic/security-detection-rule-management
elastic/security-entity-analytics
elastic/security-solution
elastic/security-threat-hunting-explore
elastic/security-threat-hunting-investigations
|
PhilippeOberti
added
release_note:skip
Contributor
|
Pinging @elastic/security-threat-hunting-investigations (Team:Threat Hunting:Investigations) |
tiansivive
reviewed
Apr 1, 2025
...ity_solution/public/entity_analytics/components/top_risk_score_contributors_alerts/index.tsx
Show resolved
Hide resolved
tiansivive
approved these changes
Apr 1, 2025
Contributor
tiansivive
left a comment
tiansivive
left a comment
There was a problem hiding this comment.
LGTM from Entity Analytics
...ublic/detections/components/alerts_table/grouping_settings/default_group_panel_renderers.tsx
Outdated
Show resolved
Hide resolved
kqualters-elastic
approved these changes
Apr 1, 2025
Contributor
kqualters-elastic
left a comment
kqualters-elastic
left a comment
There was a problem hiding this comment.
Desk testing it revealed some stuff that's probably rendering more than it needs to, but that's a separate and existing problem ha. LGTM 👍
PhilippeOberti
force-pushed
the
table-grouping-defaults
branch
from
87e6869 to
b2d2731
Compare
PhilippeOberti
force-pushed
the
table-grouping-defaults
branch
from
2230e6a to
9757f86
Compare
jkelas
force-pushed
the
table-grouping-defaults
branch
from
9757f86 to
9264b90
Compare
jkelas
reviewed
Apr 2, 2025
Contributor
jkelas
left a comment
jkelas
left a comment
There was a problem hiding this comment.
I found 2 issues:
- Additional comma in 'x-pack/solutions/security/plugins/security_solution/public/detection_engine/rule_details_ui/pages/rule_details/index.tsx` file, probably leading to a weird behavior when selecting this option (see the video)
- Sometimes when I click some group name, and then expand the group by options, the options is not selected (instead the None is selected) - see the video.
Screen.Recording.2025-04-02.at.13.05.05.mov
| }, | ||
| { | ||
| label: i18n.DESTINATION_ADDRESS, | ||
| key: 'destination.address,', |
Contributor
There was a problem hiding this comment.
There is some leftover comma after address, probably leading to this weird behavior when selecting destination.address as a group by:
Screen.Recording.2025-04-02.at.13.05.05.mov
Contributor
Author
There was a problem hiding this comment.
good catch, fixed in the last commit! 😄
PhilippeOberti
force-pushed
the
table-grouping-defaults
branch
from
9264b90 to
decce51
Compare
Contributor
Author
@jkelas I've played with it for the last hour and can't reproduce it at all. 😞 🤔 Is there a chance that this could have happened for you? |
…tonContent and extraAction via props (for AI4DSOC)
PhilippeOberti
force-pushed
the
table-grouping-defaults
branch
from
f83adcb to
6258c9f
Compare
2 tasks
jkelas
approved these changes
Apr 3, 2025
Contributor
jkelas
left a comment
jkelas
left a comment
There was a problem hiding this comment.
I verified the code, and after the fix it is good now.
I tested the behavior and it matches what I see on the main branch.
I am approving.
Contributor
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
Page load bundle
History
|
Contributor
|
Starting backport for target branches: 8.x https://github.com/elastic/kibana/actions/runs/14247375945 |
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
to PhilippeOberti/kibana
that referenced
this pull request
Apr 3, 2025
…tonContent and extraAction via props (for AI4DSOC) (elastic#216572) ## Summary This PR makes changes to the GroupedAlertTable code to support a behavior in the AI for the SOC Alert summary page that the current code cannot. In the new Alert summary page (see [mocks](https://www.figma.com/design/DYs7j4GQdAhg7aWTLI4R69/AI4DSOC?node-id=3284-69401&p=f&m=dev)) there are a few customization that we need to be able to do: - we need a different set of default groups to be shown in the dropdown - we need to be able to customize the title shown in the EuiAccordion in a way that would conflict with the current implementation - we need to also customize the group statistics shown in the EuiAccordion ### Challenge The current implementation within the GroupedAlertTable was not allowing full customization. - while the default groups could be changed, it was done via if/else conditions, using the `tableId` to know where the table was being used. This isn't a clean way to do this. The component shouldn't be aware of where it's being used... - regarding the title and group statistics, these were hardcoded and not customizable. While I could also have added if/else conditions to support the Alert summary page different behavior, this would only have built more tech debt... ### Approach Instead of continuing adding more if/else conditions, the approach in the PR adds 3 new props to the GroupedAlertTable: - `accordionButtonContent` allows to customize how the EuiAccordion `buttonContent` (title) is rendered - `accordionExtraActionGroupStats` allows to customize how the EuiAccordion `extraAction` (statistics) are rendered. This actually consists of 2 sub properties: - `renderer` which will drive the UI - aggregations which will be used to fetch the data - `defaultGroupingOptions` allows to customize the default values in the dropdown ### Notes **_The 3 places where the GroupedAlertTable is used have been updated to use the same default values. Their behavior should be unchanged. A follow up PR will implement the Alert summary variation._** In the new state, any new usage of the alerts table with no default values will provide the following behavior: - the EuiAccordion `buttonContent` will use [the default component](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-grouping/src/components/accordion_panel/index.tsx#L33) from the `kbn-grouping` package - the EuiAccordion `extraAction` will display only the number of alerts within the group - the default options in the `Group alerts by` dropdown will be `None` and `Custom field` https://github.com/user-attachments/assets/57563735-78ee-455f-aab6-806028aec713 https://github.com/user-attachments/assets/0659c74e-b4a0-4051-8fb7-25457424c06b ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md) - [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 Will help elastic/security-team#11973 (cherry picked from commit 0e633d7) # Conflicts: # x-pack/solutions/security/plugins/security_solution/public/detections/components/alerts_table/alerts_grouping.tsx
Contributor
I repeated the testing and I think the behavior matches what I see on the main branch also. I approved the PR. However I would like to ask @approksiu if this is a normal, expected behavior what I see on main. Please take a look at the videos below. I think it's either counterintuitive or buggy.
Please take a look at the videos I am attaching, it should be more clear there, and let me know what you think. Should I create a bug for this or is this fine? Screen.Recording.2025-04-03.at.08.27.35.movScreen.Recording.2025-04-03.at.08.35.06.mov |
Contributor
Author
@jkelas I just realized with your comment and videos that the I've always done multiple nested groups by selecting multiple options in the most top level... I check with others and that's how they've always done it as well. They actually never noticed the buttons in the nested groups 🤣 This is definitely a weird behavior, but has been here for many releases I think. I'll check with @YulNaumenko as she might remember if that was the case when the grouped alert table was originally created. It is definitely weird. The weirdest to me is why the nested button show Definitely something we need to improve:
|
PhilippeOberti
added a commit
that referenced
this pull request
Apr 3, 2025
…s, buttonContent and extraAction via props (for AI4DSOC) (#216572) (#217097) # Backport This will backport the following commits from `main` to `8.x`: - [[Security Solution][Grouped table] allow changing default groups, buttonContent and extraAction via props (for AI4DSOC) (#216572)](#216572) <!--- 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-04-03T15:53:30Z","message":"[Security Solution][Grouped table] allow changing default groups, buttonContent and extraAction via props (for AI4DSOC) (#216572)\n\n## Summary\n\nThis PR makes changes to the GroupedAlertTable code to support a\nbehavior in the AI for the SOC Alert summary page that the current code\ncannot.\nIn the new Alert summary page (see\n[mocks](https://www.figma.com/design/DYs7j4GQdAhg7aWTLI4R69/AI4DSOC?node-id=3284-69401&p=f&m=dev))\nthere are a few customization that we need to be able to do:\n- we need a different set of default groups to be shown in the dropdown\n- we need to be able to customize the title shown in the EuiAccordion in\na way that would conflict with the current implementation\n- we need to also customize the group statistics shown in the\nEuiAccordion\n\n### Challenge\n\nThe current implementation within the GroupedAlertTable was not allowing\nfull customization.\n- while the default groups could be changed, it was done via if/else\nconditions, using the `tableId` to know where the table was being used.\nThis isn't a clean way to do this. The component shouldn't be aware of\nwhere it's being used...\n- regarding the title and group statistics, these were hardcoded and not\ncustomizable. While I could also have added if/else conditions to\nsupport the Alert summary page different behavior, this would only have\nbuilt more tech debt...\n\n### Approach\n\nInstead of continuing adding more if/else conditions, the approach in\nthe PR adds 3 new props to the GroupedAlertTable:\n- `accordionButtonContent` allows to customize how the EuiAccordion\n`buttonContent` (title) is rendered\n- `accordionExtraActionGroupStats` allows to customize how the\nEuiAccordion `extraAction` (statistics) are rendered. This actually\nconsists of 2 sub properties:\n - `renderer` which will drive the UI\n - aggregations which will be used to fetch the data\n- `defaultGroupingOptions` allows to customize the default values in the\ndropdown\n\n### Notes\n\n**_The 3 places where the GroupedAlertTable is used have been updated to\nuse the same default values. Their behavior should be unchanged. A\nfollow up PR will implement the Alert summary variation._**\n\nIn the new state, any new usage of the alerts table with no default\nvalues will provide the following behavior:\n- the EuiAccordion `buttonContent` will use [the default\ncomponent](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-grouping/src/components/accordion_panel/index.tsx#L33)\nfrom the `kbn-grouping` package\n- the EuiAccordion `extraAction` will display only the number of alerts\nwithin the group\n- the default options in the `Group alerts by` dropdown will be `None`\nand `Custom field`\n\n\nhttps://github.com/user-attachments/assets/57563735-78ee-455f-aab6-806028aec713\n\n\nhttps://github.com/user-attachments/assets/0659c74e-b4a0-4051-8fb7-25457424c06b\n\n### Checklist\n\n- [x] Any text added follows [EUI's writing\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\nsentence case text and includes [i18n\nsupport](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)\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\nWill help https://github.com/elastic/security-team/issues/11973","sha":"0e633d777ade056c9f5eb367a1219a951af4ac61","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","Team:Threat Hunting:Investigations","Team:Security Generative AI","backport:version","v9.1.0","v8.19.0"],"title":"[Security Solution][Grouped table] allow changing default groups, buttonContent and extraAction via props (for AI4DSOC)","number":216572,"url":"https://github.com/elastic/kibana/pull/216572","mergeCommit":{"message":"[Security Solution][Grouped table] allow changing default groups, buttonContent and extraAction via props (for AI4DSOC) (#216572)\n\n## Summary\n\nThis PR makes changes to the GroupedAlertTable code to support a\nbehavior in the AI for the SOC Alert summary page that the current code\ncannot.\nIn the new Alert summary page (see\n[mocks](https://www.figma.com/design/DYs7j4GQdAhg7aWTLI4R69/AI4DSOC?node-id=3284-69401&p=f&m=dev))\nthere are a few customization that we need to be able to do:\n- we need a different set of default groups to be shown in the dropdown\n- we need to be able to customize the title shown in the EuiAccordion in\na way that would conflict with the current implementation\n- we need to also customize the group statistics shown in the\nEuiAccordion\n\n### Challenge\n\nThe current implementation within the GroupedAlertTable was not allowing\nfull customization.\n- while the default groups could be changed, it was done via if/else\nconditions, using the `tableId` to know where the table was being used.\nThis isn't a clean way to do this. The component shouldn't be aware of\nwhere it's being used...\n- regarding the title and group statistics, these were hardcoded and not\ncustomizable. While I could also have added if/else conditions to\nsupport the Alert summary page different behavior, this would only have\nbuilt more tech debt...\n\n### Approach\n\nInstead of continuing adding more if/else conditions, the approach in\nthe PR adds 3 new props to the GroupedAlertTable:\n- `accordionButtonContent` allows to customize how the EuiAccordion\n`buttonContent` (title) is rendered\n- `accordionExtraActionGroupStats` allows to customize how the\nEuiAccordion `extraAction` (statistics) are rendered. This actually\nconsists of 2 sub properties:\n - `renderer` which will drive the UI\n - aggregations which will be used to fetch the data\n- `defaultGroupingOptions` allows to customize the default values in the\ndropdown\n\n### Notes\n\n**_The 3 places where the GroupedAlertTable is used have been updated to\nuse the same default values. Their behavior should be unchanged. A\nfollow up PR will implement the Alert summary variation._**\n\nIn the new state, any new usage of the alerts table with no default\nvalues will provide the following behavior:\n- the EuiAccordion `buttonContent` will use [the default\ncomponent](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-grouping/src/components/accordion_panel/index.tsx#L33)\nfrom the `kbn-grouping` package\n- the EuiAccordion `extraAction` will display only the number of alerts\nwithin the group\n- the default options in the `Group alerts by` dropdown will be `None`\nand `Custom field`\n\n\nhttps://github.com/user-attachments/assets/57563735-78ee-455f-aab6-806028aec713\n\n\nhttps://github.com/user-attachments/assets/0659c74e-b4a0-4051-8fb7-25457424c06b\n\n### Checklist\n\n- [x] Any text added follows [EUI's writing\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\nsentence case text and includes [i18n\nsupport](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)\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\nWill help https://github.com/elastic/security-team/issues/11973","sha":"0e633d777ade056c9f5eb367a1219a951af4ac61"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/216572","number":216572,"mergeCommit":{"message":"[Security Solution][Grouped table] allow changing default groups, buttonContent and extraAction via props (for AI4DSOC) (#216572)\n\n## Summary\n\nThis PR makes changes to the GroupedAlertTable code to support a\nbehavior in the AI for the SOC Alert summary page that the current code\ncannot.\nIn the new Alert summary page (see\n[mocks](https://www.figma.com/design/DYs7j4GQdAhg7aWTLI4R69/AI4DSOC?node-id=3284-69401&p=f&m=dev))\nthere are a few customization that we need to be able to do:\n- we need a different set of default groups to be shown in the dropdown\n- we need to be able to customize the title shown in the EuiAccordion in\na way that would conflict with the current implementation\n- we need to also customize the group statistics shown in the\nEuiAccordion\n\n### Challenge\n\nThe current implementation within the GroupedAlertTable was not allowing\nfull customization.\n- while the default groups could be changed, it was done via if/else\nconditions, using the `tableId` to know where the table was being used.\nThis isn't a clean way to do this. The component shouldn't be aware of\nwhere it's being used...\n- regarding the title and group statistics, these were hardcoded and not\ncustomizable. While I could also have added if/else conditions to\nsupport the Alert summary page different behavior, this would only have\nbuilt more tech debt...\n\n### Approach\n\nInstead of continuing adding more if/else conditions, the approach in\nthe PR adds 3 new props to the GroupedAlertTable:\n- `accordionButtonContent` allows to customize how the EuiAccordion\n`buttonContent` (title) is rendered\n- `accordionExtraActionGroupStats` allows to customize how the\nEuiAccordion `extraAction` (statistics) are rendered. This actually\nconsists of 2 sub properties:\n - `renderer` which will drive the UI\n - aggregations which will be used to fetch the data\n- `defaultGroupingOptions` allows to customize the default values in the\ndropdown\n\n### Notes\n\n**_The 3 places where the GroupedAlertTable is used have been updated to\nuse the same default values. Their behavior should be unchanged. A\nfollow up PR will implement the Alert summary variation._**\n\nIn the new state, any new usage of the alerts table with no default\nvalues will provide the following behavior:\n- the EuiAccordion `buttonContent` will use [the default\ncomponent](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-grouping/src/components/accordion_panel/index.tsx#L33)\nfrom the `kbn-grouping` package\n- the EuiAccordion `extraAction` will display only the number of alerts\nwithin the group\n- the default options in the `Group alerts by` dropdown will be `None`\nand `Custom field`\n\n\nhttps://github.com/user-attachments/assets/57563735-78ee-455f-aab6-806028aec713\n\n\nhttps://github.com/user-attachments/assets/0659c74e-b4a0-4051-8fb7-25457424c06b\n\n### Checklist\n\n- [x] Any text added follows [EUI's writing\nguidelines](https://elastic.github.io/eui/#/guidelines/writing), uses\nsentence case text and includes [i18n\nsupport](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)\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\nWill help https://github.com/elastic/security-team/issues/11973","sha":"0e633d777ade056c9f5eb367a1219a951af4ac61"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT-->
Contributor
Author
Ok I confirmed with @YulNaumenko that this was not the intended behavior and was working correctly before. I quickly checked and the issue has been happening for a while though, as pulling down the I just looked at a I'm going to look into how we could make sure that the button does not show in nested groups, as the original intent was to be able to control grouping ONLY from the unique button rendered at the most top level. |
1 task
PhilippeOberti
added a commit
that referenced
this pull request
May 2, 2025
…tections grouping alerts table (#219878) ## Summary This PR continues the effort started in [this previous PR](#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
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 makes changes to the GroupedAlertTable code to support a behavior in the AI for the SOC Alert summary page that the current code cannot.
In the new Alert summary page (see mocks) there are a few customization that we need to be able to do:
Challenge
The current implementation within the GroupedAlertTable was not allowing full customization.
tableIdto know where the table was being used. This isn't a clean way to do this. The component shouldn't be aware of where it's being used...Approach
Instead of continuing adding more if/else conditions, the approach in the PR adds 3 new props to the GroupedAlertTable:
accordionButtonContentallows to customize how the EuiAccordionbuttonContent(title) is renderedaccordionExtraActionGroupStatsallows to customize how the EuiAccordionextraAction(statistics) are rendered. This actually consists of 2 sub properties:rendererwhich will drive the UIdefaultGroupingOptionsallows to customize the default values in the dropdownNotes
The 3 places where the GroupedAlertTable is used have been updated to use the same default values. Their behavior should be unchanged. A follow up PR will implement the Alert summary variation.
In the new state, any new usage of the alerts table with no default values will provide the following behavior:
buttonContentwill use the default component from thekbn-groupingpackageextraActionwill display only the number of alerts within the groupGroup alerts bydropdown will beNoneandCustom fieldScreen.Recording.2025-03-31.at.8.44.16.PM.mov
Screen.Recording.2025-04-01.at.6.56.27.PM.mov
Checklist
Will help https://github.com/elastic/security-team/issues/11973