[Security Solution][THI] Create hook to fetch security default patterns and replace useTimelineFilters usage

[christineweng]

Summary

Ref: #225925, #226312

This PR creates a hook to return the id and index patterns of the security default data view. This is the default indices specified in advanced settings plus alert index. They are meant to be static across sessions, versus the SourcererScopeName.default is based on the data view selected in the data view picker.

Additionally, there are features that require security default patterns. It was previously done via useTimelineFilters, but it relies on the analyzer scope - when user changes the data view in analyzer, features like the prevalence table, ancestry correlations and entity analytic flyouts are impacted.

Changes inclue:

• Created a useSecurityDefaultPatterns hook in data view manager
• Removed selectedPatterns in useTimelineFilters
• Replaced the index patterns with the security default patterns where applicable
• Renamed some variables to be more explicit, and separate from the patterns return based on SourcererScopeName.default

Enable newDataViewPickerEnabled

After

Investigating an event always opens timeline with the default security data view. Opening a timeline from timelines page should have the specified data view

Screen.Recording.2025-07-02.at.5.07.55.PM.mov

Changing data view in analyzer does not change the results observed host table

Screen.Recording.2025-07-02.at.5.57.37.PM.mov

Checklist

• Unit or functional tests were updated or added to match the most common scenarios
• The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines

[elasticmachine]

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

[PhilippeOberti]

Desk tested and everything seems to be working as expected!
I left a few comments on the code but those are a bit subjective and non blockers 😄
Great job fixing 2 bugs at the same time!

[PhilippeOberti]

Isn't this kind of a duplicate of this other hook?

[lgestc]

is it not feasible to just useDataView() and respective props?

[christineweng]

@PhilippeOberti @lgestc Thanks for the review! I'm not sure the comments are around the logic or the implementation, so I include both:

• The timeline data view bug is due to the fact that it pulls the data view based on scope name. The scope name corresponds to the selection in that data view picker (in this case explore). So when we change the data view in explore, create_timeline uses another data view. timeline should always start with the default security data view, so we have to find a way to do this without needing a scope

const experimentalSelectedPatterns = useSelectedPatterns(DataViewManagerScopeName.default);

• The implementation is then to have a separate hook to do that. All of our existing hooks receive a scope name as prop. each scope represents a data view picker (and they are subject to change from user interaction). To support both scope name and a specific data view, the prop type needs to be changed to DataViewManagerScopeName | string

From

export const useDataView = (dataViewManagerScope: DataViewManagerScopeName): 
{ dataView: DataView; status: SharedDataViewSelectionState['status'] } => {
  ...

To:

export const useDataView = (dataViewManagerScope: DataViewManagerScopeName | string ):
 { dataView: DataView; status: SharedDataViewSelectionState['status'] } => {
  ...

I personally think it's a overkill and requires more validation later on. We do store the default data view id in data view manager redux, just not the patterns. We could store the patterns in redux as well, this is how sourcerer works (it stores the entire default data view in redux).

const { id: oldDataViewId, patternList: oldSelectedPatterns } = useSelector(
    sourcererSelectors.defaultDataView
  ) ?? { id: '', patternList: [] };

Let me know if I miss something, happy to discuss live as well

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 06e5071

Failed CI Steps

• FTR Configs #26

Test Failures

• [job] [logs] FTR Configs #26 / serverless observability UI - feature flags ES Query rule - consumers only logs privileges navigates to the rules page

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
securitySolution	7785	7786	+1

Async chunks

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

id	before	after	diff
securitySolution	9.8MB	9.8MB	+1.5KB

History

• 💔 Build #315238 failed 35e06aa

cc @christineweng

[PhilippeOberti]

Thanks for making all the changes @christineweng , code LGTM!

[machadoum]

Thank you!

This is interesting, I wasn't even aware that flyouts are using the security data view instead of the selected one.

[kibanamachine]

Starting backport for target branches: 8.19, 9.1

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

[kibanamachine]

💔 Some backports could not be created

Status	Branch	Result
❌	8.19	Backport failed because of merge conflicts
✅	9.1

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

Manual backport

To create the backport manually run:

node scripts/backport --pr 226314

Questions ?

Please refer to the Backport tool documentation

[christineweng]

💚 All backports created successfully

Status	Branch	Result
✅	8.19

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

Questions ?

Please refer to the Backport tool documentation

[kibanamachine]

Looks like this PR has backport PRs but they still haven't been merged. Please merge them ASAP to keep the branches relatively in sync.
cc: @christineweng