[Security Solution] Use new expandable flyout in alert preview

[christineweng]

Summary

This PR updates the alert preview in Create rule -> Rule preview to use the new expandable alert flyout:

• Switched timeline wrapper to be visible on create rule page. This allows us to keep all the timeline navigation in the new expandable alert flyout
• Disabled alert specific components, when flyout is open in create rule:
  • Alert status is not shown
  • Rule summary preview is disabled
  • Title link to rule details page is removed
  • Exclude filter in/filter out hover actions in highlighted fields
  • New placeholder text for investigation guide and response: we should not show link to documentation when user is setting up a rule

With feature flag on:

Screen.Recording.2023-11-16.at.4.21.26.PM.mov

How to test

• Add xpack.securitySolution.enableExperimental: ['expandableFlyoutInCreateRuleEnabled' ] to kibana.yml.dev
• Go to Rules page -> Detection rules (SIEM) => Create rule
• Pick a rule type and populate the query, click Continue
• On the right hand side, click Refresh, some alerts should appear in the table
• Click expand on a row

Checklist

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

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

[PhilippeOberti]

Left a few comments. The code looks good overall and the UI behaves how I'm expecting.

I think this would be a good candidate for some Cypress tests? I haven't checked if the rule page already has some, but it could be worth spending some time looking at this?

[nikitaindik]

Thanks @christineweng for adding this neat feature! I checked the code and tested it manually. Couple of things I noticed.

1. Would it make sense not to render sections and tabs unavailable in alert flyout? For example, the "Response" collapsible section or investigation guide in the Investigation section / left panel tab. This might make the flyout a little less complex visually.

2. Nit: The title of the flyout says "Preview Rule" which feels a bit technical. Kind of exposes the fact that we are creating a one-off rule under the hood to generate alerts (as I understand). Maybe we can hide the title or change it to something like "Alert Details" or "Alert Preview"? What do you think?

3. Minor: If you reload a page with the flyout open, the flyout will still be displayed after reloading. This might be a little confusing because index patterns and query are reset after reload. Does it happen because we store the flyout state in the URL? If yes, do we need to store it there for the preview flyout?
   Also, if you navigate back to the rule management or rule details page with the flyout open, the flyout will still be displayed. The alert preview opened from the rule details page behaves the same, so must be a common issue.

[PhilippeOberti]

Hey @nikitaindik thanks for these comments, let me answer them as Christine is on PTO this week

1. Would it make sense not to render sections and tabs unavailable in alert flyout? For example, the "Response" collapsible section or investigation guide in the Investigation section / left panel tab. This might make the flyout a little less complex visually.

We had discussions back and forth with product and UIUX and we ended up deciding to keep the flyout identical but just with the sections disabled, instead of hiding things. The 2 reasons were:

• slightly less code changes doing it this way
• keep consistency so that the user knows all the functionality that will be available when used on an actual alert

2. Nit: The title of the flyout says "Preview Rule" which feels a bit technical. Kind of exposes the fact that we are creating a one-off rule under the hood to generate alerts (as I understand). Maybe we can hide the title or change it to something like "Alert Details" or "Alert Preview"? What do you think?

I can see that using Alert Preview would make more sense here. Let me confirm this with product and UIUX!

3. Minor: If you reload a page with the flyout open, the flyout will still be displayed after reloading. This might be a little confusing because index patterns and query are reset after reload. Does it happen because we store the flyout state in the URL? If yes, do we need to store it there for the preview flyout?

Good point! This is a feature that we built in, but maybe it doesn't make sense for this preview alerts. Let us check on that!

Also, if you navigate back to the rule management or rule details page with the flyout open, the flyout will still be displayed. The alert preview opened from the rule details page behaves the same, so must be a common issue.

Yeah this is probably also related to the point above, we'll check on that as well, thanks!

[PhilippeOberti]

@christineweng Now that the header redesign PR is merged, we're showing the rule link again, which I think in this creation rule case we should not. Clicking on the link navigates to a page for a rule that doesn't exist yet. I feel like we should have a UI similar to Event details (black text no link)

[PhilippeOberti]

I reviewed the code again after the last commit. Everything looks good. Let's discuss this comment and that one when you come back from PTO!

[yctercero]

Thanks so much for all the work here, @christineweng !

Haven't looked at the code, but played around with it and just have a couple UX questions/comments. There seem to be a couple areas where the user can click and get taken away from the rule creation flow. I don't think we should include any links that would take the user away from this flow.

• There are some areas in the flyout that allow you to click the rule name Preview rule that navigates the user away from rule creation to the rule details page that doesn't load as the rule doesn't yet exist

• I see a bunch of calls fetch a rule that doesn't exist. I didn't trace where it's coming from but is happening when I have the flyout open.

• There are some areas that still contain the filter in/out

• The timeline persists even after moving away from rule creation and this could be a bit confusing as it is referencing data that is no longer persisted (the preview index cleans up frequently). I worry about it getting confusing carrying over preview investigations into actual investigation flows.

I am happy to hop on a zoom next week with @paulewing and others to sort out some of these questions!

[christineweng]

@yctercero thank you for the comments! I did some research and added some notes/observations below.

• There are some areas in the flyout that allow you to click the rule name Preview rule that navigates the user away from rule creation to the rule details page that doesn't load as the rule doesn't yet exist

Great catch! I think session viewer (from the screenshot in your comments) and the new title (from @PhilippeOberti's comment) are the only two places I found a rule details link, let me know if I miss anything

• I see a bunch of calls fetch a rule that doesn't exist. I didn't trace where it's coming from but is happening when I have the flyout open.

The 404's are coming from useRuleWithFallback here. Similar failed requests appear in the old flyout as well, the same hook is used here. I don't think we can avoid using that hook though, since we still need the highlighted fields.

• There are some areas that still contain the filter in/out

That is correct, the component in the screenshot is owned by a different team, to introduce the preview logic there is more involved and make sense to do it in a separate PR. I'll confirm with product & UIUX if that's something we should prioritize

• The timeline persists even after moving away from rule creation and this could be a bit confusing as it is referencing data that is no longer persisted (the preview index cleans up frequently). I worry about it getting confusing carrying over preview investigations into actual investigation flows.

I am happy to hop on a zoom next week with @paulewing and others to sort out some of these questions!

• Regarding the preview index: my understanding is the preview index is purposely hidden in timeline, i.e. we cannot query by a preview alert id. Any add to timeline actions only add value pairs to timeline, so cleaning up the preview index shouldn't impact these interactions?

[christineweng]

@nikitaindik Thank you for the review! There are some effort on the url sync in parallel, so I put this feature behind a feature flag until the other PR is merged. Please see answer to your feedback below.

1. Would it make sense not to render sections and tabs unavailable in alert flyout? For example, the "Response" collapsible section or investigation guide in the Investigation section / left panel tab. This might make the flyout a little less complex visually.

See @PhilippeOberti's response here let me know if you have more questions/concerns

2. Nit: The title of the flyout says "Preview Rule" which feels a bit technical. Kind of exposes the fact that we are creating a one-off rule under the hood to generate alerts (as I understand). Maybe we can hide the title or change it to something like "Alert Details" or "Alert Preview"? What do you think?

Great point, I talked to @paulewing and the guidance was to go with the existing Preview rule, to stay consistent with how it is currently shown. It will be a quick change once we chat with docs :)

3. Minor: If you reload a page with the flyout open, the flyout will still be displayed after reloading. This might be a little confusing because index patterns and query are reset after reload. Does it happen because we store the flyout state in the URL? If yes, do we need to store it there for the preview flyout?
   Also, if you navigate back to the rule management or rule details page with the flyout open, the flyout will still be displayed. The alert preview opened from the rule details page behaves the same, so must be a common issue.

currently there is a PR in progress to revamp how we do url and store the flyout state in the url history. Having correct history should fix the second behavior (going back and flyout still shows up). Regarding the refresh, I added a to-do to check that it works properly before turning on the feature flag.

[christineweng]

@yctercero @nikitaindik @PhilippeOberti just to bring to your attention, while the new flyout in preview is behind a feature flag, making timeline visible is not behind a feature flag. but the old flyout does not have any timeline hover actions, so it won't interact with it.

Some of your comments are not addressed in this PR either because there is on-going work from other team members, or makes more sense to do a separate PR. they are being tracked in the issue. If you have questions or concerns related to timeline in create rule, feel free to post here and I can add to the tracking :)

[PhilippeOberti]

change LGTM, tested the feature flag, thanks for putting it in place!

[nikitaindik]

Thanks for addressing the feedback. Approved!

Will refresh with main now to rerun the build.

[sphilipse]

approving for CI auto-commit

[kibana-ci]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: e36128b

Failed CI Steps

• Defend Workflows Cypress Tests on Serverless #2

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	12.8MB	12.8MB	+3.8KB
serverlessSearch	369.1KB	369.2KB	+147.0B
total			+3.9KB

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
securitySolution	65.3KB	65.4KB	+39.0B

History

• 💛 Build #177073 was flaky bc8e16d
• 💛 Build #176716 was flaky caa9f06
• 💔 Build #173294 failed 664ec59
• 💛 Build #172903 was flaky 40a01d1
• 💛 Build #172382 was flaky f609e3d8e7e0bfc3774f2222e14af7d17a0c8ddf
• 💚 Build #172372 succeeded 4db2e3d07c868efe7f6a464d87a937cf32d2f739

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @christineweng