Skip to content

Comments

[Security Solution] Rename use_data_view to use_data_view_spec#216461

Merged
lgestc merged 4 commits intoelastic:mainfrom
lgestc:rename_use_data_view_to_use_data_view_spec
Apr 1, 2025
Merged

[Security Solution] Rename use_data_view to use_data_view_spec#216461
lgestc merged 4 commits intoelastic:mainfrom
lgestc:rename_use_data_view_to_use_data_view_spec

Conversation

@lgestc
Copy link
Contributor

@lgestc lgestc commented Mar 31, 2025

Summary

Just naming things, the goal is to highlight the fact the hook returns the spec and not the DataView instance.
No testing is required as the change does not alter the logic.

@lgestc lgestc requested review from a team as code owners March 31, 2025 13:07
@lgestc lgestc changed the title rename use_data_view to use_data_view_spec [Security Solution] Rename use_data_view to use_data_view_spec Mar 31, 2025
@lgestc lgestc added release_note:skip Skip the PR/issue when compiling release notes backport:skip This PR does not require backporting 9.1 candidate Feature:Sourcerer Team:Threat Hunting:Investigations Security Solution Threat Hunting Investigations Team labels Mar 31, 2025
@elasticmachine
Copy link
Contributor

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

Copy link
Contributor

@PhilippeOberti PhilippeOberti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think about pushing this renaming a bit further? Right now you've renamed useDataView to useDataViewSpec, but I would also rename the returned dataView property to dataViewSpec so that it's clear what is being used in all the components the hook is used...

Right now this is what we have const { dataView } = useDataViewSpec(scope); and I fee like const { dataViewSpec } = useDataViewSpec(scope); would be even clearer.

Thoughts?

@lgestc lgestc requested a review from PhilippeOberti March 31, 2025 14:19
@lgestc
Copy link
Contributor Author

lgestc commented Mar 31, 2025

What do you think about pushing this renaming a bit further? Right now you've renamed useDataView to useDataViewSpec, but I would also rename the returned dataView property to dataViewSpec so that it's clear what is being used in all the components the hook is used...

Right now this is what we have const { dataView } = useDataViewSpec(scope); and I fee like const { dataViewSpec } = useDataViewSpec(scope); would be even clearer.

Thoughts?

@PhilippeOberti sounds reasonable, applied

Copy link
Contributor

@PhilippeOberti PhilippeOberti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left another couple of comments, but I'll let other people comment as well as maybe I'm overthinking this?

@lgestc lgestc requested a review from PhilippeOberti March 31, 2025 14:40
Copy link
Contributor

@PhilippeOberti PhilippeOberti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for making this rename!

@lgestc lgestc enabled auto-merge (squash) March 31, 2025 15:01
Copy link
Contributor

@christineweng christineweng left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

@elastic elastic deleted a comment from elasticmachine Apr 1, 2025
@lgestc lgestc merged commit 65bb560 into elastic:main Apr 1, 2025
9 checks passed
@lgestc lgestc deleted the rename_use_data_view_to_use_data_view_spec branch April 1, 2025 08:46
lgestc added a commit that referenced this pull request Apr 1, 2025
## Summary

Renaming `useFullDataView` to `useDataView`, for clarity. We also have
`useDataViewSpec` now, introduced in
#216461.
christineweng pushed a commit to christineweng/kibana that referenced this pull request Jun 6, 2025
…ic#216461)

## Summary

Just naming things, the goal is to highlight the fact the hook returns
the spec and not the DataView instance.
No testing is required as the change does not alter the logic.
christineweng pushed a commit to christineweng/kibana that referenced this pull request Jun 6, 2025
## Summary

Renaming `useFullDataView` to `useDataView`, for clarity. We also have
`useDataViewSpec` now, introduced in
elastic#216461.
christineweng added a commit that referenced this pull request Jun 10, 2025
… Data View Picker (#210585) (#223044)

# Backport

This will backport the following commits from `main` to `8.19`:
- [[Security Solution][Sourcerer] Replace Sourcerer with Discover Data
View Picker (#210585)](#210585)
- [[Security Solution] Rename use_data_view to use_data_view_spec
#216461](#216461)
- [[Security Solution] Rename use full data view hook
#216614](#216614)
- [[Security Solution] Replace sourcerer in global header
#216685](#216685)
- [[Security Solution] Remove .title use in use_selected_patterns
#216994](#216994)
- [[Security Solution] Render default security solution data view with
managed label #216961](#216961)
- [[Security Solution] Replace sourcerer in analyzer
#218183](#218183)
- [[Security Solution] Replace use_sourcerer_data_view
#216997](#216997)
- [[Security Solution] Replace sourcerer in EQL tab with dataview picker
#218897](#218897)
- [[Security Solution][Sourcerer] replace use get scoped data view
#220196](#220196)
- [[Security Solution] renaming dataView to dataViewSpec and adding
types for clarity
#220718](#220718)
- [[Security Solution][Sourcerer] Maintain url sync support
#221737](#221737)
- [[Security Solution][Data View Manager] Allow passing data view to
query bar #220585](#220585)
- [[Security Solution] Fix data view picker privilege
#222122](#222122)



<!--- Backport version: 10.0.0 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)

<!--BACKPORT [{"author":{"name":"Luke
Gmys","email":"11671118+lgestc@users.noreply.github.com"},"sourceCommit":{"committedDate":"2025-03-31T12:12:57Z","message":"[Security
Solution][Sourcerer] Replace Sourcerer with Discover Data View Picker
(#210585)\n\n# Unified Data View Picker: Phase 1 Implementation\nPart of
https://github.com/elastic/security-team/issues/11959\n\n## What This PR
Does\nThis PR represents the first step in our transition from the
current\nSourcerer component to the new unified Data View Picker.
Specifically,\nthis implementation:\n- Creates a new Data View Picker
component\n- Implements feature flag protection for all changes\n-
Handles asynchronous effects through Redux listener middleware\n-
Establishes a new Redux store architecture to support ad hoc data\nviews
infrastructure\n- Utilizes ad hoc data views to handle legacy patterns
from series 7\n(replacing the previous upgrade data view flow)\n\nSee
the readme for more info:
\n```x-pack/solutions/security/plugins/security_solution/public/data_view_manager/readme.md```\n\n##
What This PR Does NOT Cover\n- Does not affect screens other than
Timelines\n- Does not modify the existing Sourcerer component in any
way\n- Does not fully support all URL/local storage patterns\n\n##
Implementation Notes\nWe've made several accommodations to support both
Sourcerer and the new Data View Picker simultaneously during this
transition period, including:\n- Some interfaces might look odd,
especially the hooks that return the data view or patterns - this is
intentional to support existing use cases\n- There are feature
flag-based conditional statements throughout the code that will be
removed once the transition is complete\n\n## Testing Instructions\n1.
Add the following feature flag to your configuration:\n ```\n
xpack.securitySolution.enableExperimental:
['newDataViewPickerEnabled']\n ```\n2. Navigate to the Timelines
interface\n3. Test interactions with the new Data View
Picker\n\n---------\n\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"9679f2941550856d75e00c1faadd8c9669afe917","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:enhancement","backport:skip","Team:
SecuritySolution","Team:Threat
Hunting:Investigations","Feature:Sourcerer","9.1
candidate","v9.1.0"],"title":"[Security Solution][Sourcerer] Replace
Sourcerer with Discover Data View
Picker","number":210585,"url":"https://github.com/elastic/kibana/pull/210585","mergeCommit":{"message":"[Security
Solution][Sourcerer] Replace Sourcerer with Discover Data View Picker
(#210585)\n\n# Unified Data View Picker: Phase 1 Implementation\nPart of
https://github.com/elastic/security-team/issues/11959\n\n## What This PR
Does\nThis PR represents the first step in our transition from the
current\nSourcerer component to the new unified Data View Picker.
Specifically,\nthis implementation:\n- Creates a new Data View Picker
component\n- Implements feature flag protection for all changes\n-
Handles asynchronous effects through Redux listener middleware\n-
Establishes a new Redux store architecture to support ad hoc data\nviews
infrastructure\n- Utilizes ad hoc data views to handle legacy patterns
from series 7\n(replacing the previous upgrade data view flow)\n\nSee
the readme for more info:
\n```x-pack/solutions/security/plugins/security_solution/public/data_view_manager/readme.md```\n\n##
What This PR Does NOT Cover\n- Does not affect screens other than
Timelines\n- Does not modify the existing Sourcerer component in any
way\n- Does not fully support all URL/local storage patterns\n\n##
Implementation Notes\nWe've made several accommodations to support both
Sourcerer and the new Data View Picker simultaneously during this
transition period, including:\n- Some interfaces might look odd,
especially the hooks that return the data view or patterns - this is
intentional to support existing use cases\n- There are feature
flag-based conditional statements throughout the code that will be
removed once the transition is complete\n\n## Testing Instructions\n1.
Add the following feature flag to your configuration:\n ```\n
xpack.securitySolution.enableExperimental:
['newDataViewPickerEnabled']\n ```\n2. Navigate to the Timelines
interface\n3. Test interactions with the new Data View
Picker\n\n---------\n\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"9679f2941550856d75e00c1faadd8c9669afe917"}},"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/210585","number":210585,"mergeCommit":{"message":"[Security
Solution][Sourcerer] Replace Sourcerer with Discover Data View Picker
(#210585)\n\n# Unified Data View Picker: Phase 1 Implementation\nPart of
https://github.com/elastic/security-team/issues/11959\n\n## What This PR
Does\nThis PR represents the first step in our transition from the
current\nSourcerer component to the new unified Data View Picker.
Specifically,\nthis implementation:\n- Creates a new Data View Picker
component\n- Implements feature flag protection for all changes\n-
Handles asynchronous effects through Redux listener middleware\n-
Establishes a new Redux store architecture to support ad hoc data\nviews
infrastructure\n- Utilizes ad hoc data views to handle legacy patterns
from series 7\n(replacing the previous upgrade data view flow)\n\nSee
the readme for more info:
\n```x-pack/solutions/security/plugins/security_solution/public/data_view_manager/readme.md```\n\n##
What This PR Does NOT Cover\n- Does not affect screens other than
Timelines\n- Does not modify the existing Sourcerer component in any
way\n- Does not fully support all URL/local storage patterns\n\n##
Implementation Notes\nWe've made several accommodations to support both
Sourcerer and the new Data View Picker simultaneously during this
transition period, including:\n- Some interfaces might look odd,
especially the hooks that return the data view or patterns - this is
intentional to support existing use cases\n- There are feature
flag-based conditional statements throughout the code that will be
removed once the transition is complete\n\n## Testing Instructions\n1.
Add the following feature flag to your configuration:\n ```\n
xpack.securitySolution.enableExperimental:
['newDataViewPickerEnabled']\n ```\n2. Navigate to the Timelines
interface\n3. Test interactions with the new Data View
Picker\n\n---------\n\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"9679f2941550856d75e00c1faadd8c9669afe917"}}]}]
BACKPORT-->

---------

Co-authored-by: Luke Gmys <11671118+lgestc@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Philippe Oberti <philippe.oberti@elastic.co>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

9.1 candidate backport:skip This PR does not require backporting release_note:skip Skip the PR/issue when compiling release notes Team:Threat Hunting:Investigations Security Solution Threat Hunting Investigations Team v9.1.0

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants