[Security Solution][Alert details] - refactor UI on insights

[PhilippeOberti]

Summary

This PR refactors the Insights section of the expandable flyout for alerts and events.

The changes are applied to the following section:

• Threat Intelligence: when the user clicks on the number, we open the left section to the Insights Threat Intelligence tab
• Correlations: when the user clicks on the number, we open the left section to the Insights Correlations tab
• Prevalence: no user interactions

When in preview mode, none of the number are clickable and the buttons are disabled.

New UI

Normal flyout	Preview flyout

UX flows to expand the flyout

Screen.Recording.2024-10-22.at.6.02.33.PM.mov

https://github.com/elastic/security-team/issues/7033

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

Pinging @elastic/security-threat-hunting-investigations (Team:Threat Hunting:Investigations)

[christineweng]

For some reason I thought the link in correlations should open timeline... else isn't it the same as clicking the header?

[PhilippeOberti]

For some reason I thought the link in correlations should open timeline... else isn't it the same as clicking the header?

Yeah in the ticket I had written a bullet point to discuss these with Paul and Fernanda. On one side I understand how timeline could be nice here, but then it would make the flyout expanded section a bit useless... I'll ask about it on Slack!

[PhilippeOberti]

For some reason I thought the link in correlations should open timeline... else isn't it the same as clicking the header?

Yeah in the ticket I had written a bullet point to discuss these with Paul and Fernanda. On one side I understand how timeline could be nice here, but then it would make the flyout expanded section a bit useless... I'll ask about it on Slack!

after discussing this on Slack, this is the expected behavior for now.

[christineweng]

what do you think about abstracting all the left panel calls into a hook/helper function? kind of like the cell actions. I see quite a bit of duplication like the params and keys.
Just a thought, could do it in this PR or a separate refactor, wdyt?

[PhilippeOberti]

I'm not against abstracting, I just wonder to what extend do we push this?

• it seems that the id prop is always the same indeed.
• for the path prop I think it's different enough that it would be passed in to that hook/helper method
• for the params prop, we mostly use eventId, scopeId and indexName, and while those are mainly retrieved from the useDocumentDetailsContext hook, there are instances where they're passed down via props to the component. Would we have then as props to the hook/helper method and default those values internally using the useDocumentDetailsContext if they're undefined?

[christineweng]

Would we have then as props to the hook/helper method and default those values internally using the useDocumentDetailsContext if they're undefined?
No, the helper is only for opening left/right in the same context. The simplification would only apply to all the overview headers. Preview or any new flyouts still need a full openLeftPanel call.

I thought about having it part of context, so that more accessible. But obviously the naming convention needs to be distinguishable to the expandable flyout api. Another benefit is we wouldn't need to mock the context values every time.

openLeftPanel({
  id: DocumentDetailsLeftPanelKey,
      path: {
        tab: LeftPanelInsightsTab,
        subTab: CORRELATIONS_TAB_ID,
      },
      params: {
        id: eventId,
        indexName,
        scopeId,
      },
    });

to something like

openLeft({tab: LeftPanelInsightsTab,subTab: CORRELATIONS_TAB_ID})

[christineweng]

Code looks good to me. Thanks @PhilippeOberti for responding to my comments.

Only thing I noticed during desk testing: the ... is uncommon is still present, should they be removed?

[christineweng]

Would we have then as props to the hook/helper method and default those values internally using the useDocumentDetailsContext if they're undefined?
No, the helper is only for opening left/right in the same context. The simplification would only apply to all the overview headers. Preview or any new flyouts still need a full openLeftPanel call.

I thought about having it part of context, so that more accessible. But obviously the naming convention needs to be distinguishable to the expandable flyout api. Another benefit is we wouldn't need to mock the context values every time.

openLeftPanel({
  id: DocumentDetailsLeftPanelKey,
      path: {
        tab: LeftPanelInsightsTab,
        subTab: CORRELATIONS_TAB_ID,
      },
      params: {
        id: eventId,
        indexName,
        scopeId,
      },
    });

to something like

openLeft({tab: LeftPanelInsightsTab,subTab: CORRELATIONS_TAB_ID})

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 2b34b9b
• Storybooks Preview

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	21.0MB	21.0MB	+1.7KB

History

• 💔 Build #246794 failed 75c50ae
• 💔 Build #246516 failed 2f02ae2
• 💚 Build #245108 succeeded 9a78583a921264c329597cf2b6fbf25fbef7b4c1
• 💔 Build #244906 failed 08b91c73b87972067cf370f0aefdbc3a4b835a16
• 💔 Build #244884 failed 703b8a1d6d707520f1184020786742c49cf3fd67

[kibanamachine]

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/11598606773

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation