## Summary
These changes decouple the core attack discovery generation
functionality from the `POST
/internal/elastic_assistant/attack_discovery` route.
This will allow us to use this functionality within the upcoming attack
discovery schedule execution handler ([internal
link](https://github.com/elastic/security-team/issues/12004)).
There are no changes in the business logic of the attack discovery
generation process and everything should continue working as before.
There were a couple places where our UI and API would break on orphaned
streams (classic data streams that exist in the streams API but the
underlying data stream got deleted by the user). As discussed in
https://github.com/elastic/streams-program/discussions/212 , we should
handle this case gracefully. This PR makes sure that the UI doesn't fail
anywhere
##
`x-pack/platform/packages/shared/kbn-streams-schema/src/models/ingest/lifecycle/index.ts`
An unwired ingest stream effective lifecycle can also be an error if the
data stream doesn't exist. This was part of the typescript type, but not
the schema, so using our generated typeguards would fail.
## `x-pack/platform/plugins/shared/streams/server/lib/streams/client.ts`
`client.ensureStream` would not actually do what it claimed - it would
not throw if the stream didn't exist at all. Adjusted the logic so it
does.
##
`x-pack/platform/plugins/shared/streams/server/routes/internal/streams/crud/route.ts`
_details endpoint would throw if the data stream doesn't exist, but it
can just do the search and report a doc count of 0
## All the other changes
This is more of a tangent, but I noticed that on switching to the
management tab it would reload the stream definition because it was a
different route, so the component holding the `useStreamsAppFetch` would
remount.
I fixed this by making the detail route a parent and the individual tabs
children. It's a little awkward because the management tab is the only
one having subtabs. I moved the handling of this into the
`StreamDetailViewContent` component because it wouldn't play well with
our typing of routes otherwise, but the behavior is the same as before,
with the difference that the stream definition is not reloaded if not
necessary.
Also added some api-level tests to make sure it stays that way.
Simplified massively from first state and just plugging in reselect in
places where that's suitable (here to calculate the currently relevant
sample documents).
Also does a drive-by layout fix.
~Introduces a new xstate helper for derived data.~
~In most cases, the actor and state machine model of xstate is great,
but for derived data using pure functions, the semantics of the
`useMemo` hook with defined dependencies is often easier to understand
and eliminates the risk of forgetting to update the derived data
correctly in some cases.~
~It's about using the right tool for the right job - you don't need to
choose between the dependency list of useMemo and the actor model of
xstate, you can use what fits the case, without compromising
performance.~
~This is the API:~
```ts
const myActorContext = withMemoizedSelectors(
createActorContext(myMachine),
{
derivedView: createSelector(
[
(ctx: MyContextType) => {
return ctx.dependency1;
},
(ctx: MyContextType) =>
ctx.dependency2,
],
(dependency1, dependency2) => {
return // expensive calculation only running when necessary
}
),
},
(context) => (context.subMachine ? [context.subMachine] : []) // optional subscribe to changes of submachines as well
);
// in react use useMemoizedSelector hook
// this will cause the component to rerender if the selector is returning a new value
myActorContext.useMemoizedSelector('derivedView')
```
~This is using reselect to declare the dependencies similar to a react
useMemo hook - the actual selector will only run if the dependencies
change, leading to similar semantics as useMemo, with the additional
benefit that if the value is used in multiple places, it's still just
calculated once. The component calling `withMemoizedSelectors` only
re-renders if the value returned by the selector changes. The selector
itself only re-runs if one of the declared dependencies changes.~
~Everything is type-safe by capturing the types of the reselect selector
object via inferred type param and using it in the `useMemoizedSelector`
type.~
## Summary
Fixes https://github.com/elastic/kibana/issues/215101
This PR adds an optional check for `span.id` (this value is always
populated) when redirecting to an error within a span link.
## Summary
Adds keyboard navigation for drag-and-drop interactions
Fixes https://github.com/elastic/kibana/issues/211925
Fixes https://github.com/elastic/kibana/issues/190448
### Supported features
1. Resize panels
https://github.com/user-attachments/assets/ba7add16-a0c6-4f15-9f3b-0f8ef7caf8ac
2. Drag panels within the same section (dragging between sections is
pending)
https://github.com/user-attachments/assets/a1fd80af-63ca-4fa2-bded-3db9968a8366
3. Move rows up/down
https://github.com/user-attachments/assets/8d7e8d7d-b1bf-4abe-9cc2-28eeea9b43f8
### Interaction Flow
1. Start interaction with `Space` or `Enter`
2. Move using arrow keys
3. Finish by confirming (`Enter`/`Space`) or canceling (`Escape`)
(blurring also confirms the changes)
### Scrolling Behavior:
* Default browser scrolling is disabled in interaction mode to avoid
unexpected behavior and edge cases that would overcomplicate this simple
implementation.
* Scrolling occurs when the user reaches the edge of the screen while
resizing or dragging, allowing them to continue the interaction
smoothly.
* When the operation is confirmed, we also scroll to the element to make
sure it's in view.
### Missing (planned for another PR):
* A11y announcements
* Dragging between sections
* This feature is not well unit-tested, but it's very difficult to do it
without mocking the crucial pieces of functionality. I'd vote to leave
it for now and add a few functional tests once we decide a strategy for
it, since drag and drop interactions are anyway quite difficult to
unit-test reliably anyway.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 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.
## Summary
- addresses https://github.com/elastic/security-team/issues/12000
- adds telemetry for rules in spaces:
- number of spaces, detection rules added
- number of rules in each space
---------
Co-authored-by: Dan Dillinger <ddillinger@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[@types/diff](https://redirect.github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/diff)
([source](https://redirect.github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/diff))
| devDependencies | patch | [`^7.0.1` ->
`^7.0.2`](https://renovatebot.com/diffs/npm/@types%2fdiff/7.0.1/7.0.2) |
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://redirect.github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkRhdGFEaXNjb3ZlcnkiLCJiYWNrcG9ydDphbGwtb3BlbiIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [lru-cache](https://redirect.github.com/isaacs/node-lru-cache) |
dependencies | minor | [`^11.0.2` ->
`^11.1.0`](https://renovatebot.com/diffs/npm/lru-cache/11.0.2/11.1.0) |
---
### Release Notes
<details>
<summary>isaacs/node-lru-cache (lru-cache)</summary>
###
[`v11.1.0`](https://redirect.github.com/isaacs/node-lru-cache/compare/v11.0.2...v11.1.0)
[Compare
Source](https://redirect.github.com/isaacs/node-lru-cache/compare/v11.0.2...v11.1.0)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://redirect.github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkNvcmUiLCJiYWNrcG9ydDphbGwtb3BlbiIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
Resolves: https://github.com/elastic/kibana/issues/192154
In the Fleet agent details view the last activity row shows the relative
time since the last report from an agent. This value is not as useful if
a user needs to debug why an agent is no longer reporting. Additionally,
the text content in the integration inputs are not selectable and
copyable.
* Changes the agent details last activity value to show the formatted
datetime.
* The text for integration inputs in agent details is now selectable and
copyable.
## Summary
This PR adjusts the approach introduced in #214861 to ensure state
updates work consistently across tabs, even after switching tabs during
async operations. The `currentTabId` prop has been removed from the
central state since it can't be relied on in actions, and instead tab
IDs are injected using a `CurrentTabProvider`. This allows selectors to
work the same as they did before, and tab specific actions have been
updated to use a standard `TabAction` interface that accepts a tab ID
and prevents leaking state changes.
This approach is safer but adds some complexity, so for actions
dispatched from React components, a `useCurrentTabAction` hook has been
added to handle injecting the current tab ID. We also still need to
access tab state within `DiscoverStateContainer` for now, so two utility
methods (`injectCurrentTab` and `getCurrentTab`) have been added to make
this easier. Since `DiscoverStateContainer` is scoped to a single tab,
this should be safe, and ideally temporary until we get rid of it
completely.
Resolves#215398.
### Checklist
- [ ] 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)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
**Resolves: https://github.com/elastic/security-docs/issues/3545**
## Summary
I am fixing documentation for the version and revision fields.
I used this page as the base documentation:
https://docs.elastic.dev/security-solution/dev-docs/detections/rule-versions
The changes:
- by marking the RuleVersion as read-only I am making sure we are
properly documenting that this field is not to be used in the request.
It is only returned in the response.
- by introducing RuleRevision type and marking it as read-only, I am
doing the same for this field, saying that this field is not supposed to
be used in the request.
- I am not changing any code in the app, as the ticket says we shouldn't
do any breaking changes and the update of the version should not cause
400 error. Basically current behavior is kept: users can still update
the version to whatever value they want, including going backwards, and
the changes to revision field is completely ignored.
- I am adding a condensed description of these fields.
I wanted to introduce an internal link between these two fields, but I
couldn't make it work in Bump.sh (even though this should work, normal
Markdown links) so I abandoned this idea.
You can also use this [link](https://bump.sh/jkelas2/doc/kibana_wip2)
where I deployed the generated bundled doc.
Screenshots:
<img width="664" alt="image"
src="https://github.com/user-attachments/assets/34d82eb2-f7f0-4369-ad8e-2fd3c1f35447"
/>
<img width="660" alt="image"
src="https://github.com/user-attachments/assets/dc7772af-0185-4850-816e-60be003775d6"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/214176 and
https://github.com/elastic/kibana/issues/214853
[upgrade from chrome 134 to 135 in functional test
runner](https://github.com/elastic/kibana/issues/213919) revealed a race
condition in `useBatchedPublishingSubjects` where batched observables
could emit new values before `useEffect` sets up the subscription. This
PR resolves this issue by setting up subscription in useRef, which has
no timing delays.
In chrome 134, `useBatchedPublishingSubjects` `useEffect` gets called
(setting up subscription) before lens embeddable emits any changes to
batched observables.
<img width="300" alt="chrome134"
src="https://github.com/user-attachments/assets/b0356f74-e0c7-4d93-a23a-ace519194d5d"
/>
In chrome 135, `useBatchedPublishingSubjects` `useEffect` gets called
after lens embeddable emits changes to batched observables. This causes
the lens embeddable to not render since the `LensEmbeddableComponent`
has a stale value for `expressionParams`.
<img width="300" alt="chrome135"
src="https://github.com/user-attachments/assets/320bfb7e-8b3f-4b48-a138-1c47c5ff9961"
/>
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/202092
Depends on:
- https://github.com/elastic/kibana/pull/213212
- https://github.com/elastic/kibana/pull/215963
- https://github.com/elastic/kibana/pull/216354
Add a "Group by" menu dropdown on the right side of the data grid to
render rows grouped recursively with a maximum of 3 group levels i.e.
entities grouped by type (1), category (2), risk(3). It supports
grouping by custom fields as in Findings.
Pagination state of each recursive group is kept locally, while the
top-level group's pagination is kept in the URL query-string. This is to
preserve consistency with the data-table's pagination state which is
also kept in the URL.
### Component hierarchy
<img width="1389" alt="Screenshot 2025-03-28 at 16 00 31"
src="https://github.com/user-attachments/assets/d4c30849-5d76-4589-867f-718847e11e8b"
/>
### Screenshots
<details><summary>TBD Menu Dropdown</summary>
</details>
<details><summary>Group by none</summary>
<img width="1374" alt="Screenshot 2025-03-26 at 17 00 58"
src="https://github.com/user-attachments/assets/5b319f7b-d63a-4bce-bf24-15549cda254d"
/>
</details>
<details><summary>TBD Group by entity type</summary>
</details>
<details><summary>TBD Group by source</summary>
</details>
<details><summary>TBD Group by entity type, then source</summary>
</details>
<details><summary>TBD Group by source, then entity type</summary>
</details>
<details><summary>TBD Group by cloud account</summary>
</details>
<details><summary>Group by custom field (entity.id)</summary>
<img width="1348" alt="Screenshot 2025-03-26 at 17 02 45"
src="https://github.com/user-attachments/assets/46dc1f25-2bd4-4571-888d-5becf011b7c6"
/>
</details>
> [!IMPORTANT]
> We can't group by asset criticality at the moment because the field is
not present in the current dataset.
<details><summary>TBD Group by asset criticality</summary>
</details>
### Definition of done
- [x] Add a toggle to switch between **DataGrid** and **Group by View**
visualizations.
- [x] Implement the **Group by View** using the `@kbn/grouping` package
for consistency and reusability.
- [x] Provide a dropdown menu to select grouping fields, including:
(updated as per [this
epic](https://github.com/elastic/security-team/issues/10344))
- ~~**Asset type (asset.type)**~~ -> **Asset criticality
(asset.criticality)**
- ~~**Asset category (asset.category)**~~ -> **Entity type
(entity.category)**
- ~~**Risk (host.risk.calculated_level)**~~ -> **Cloud account
(cloud.account.id)**
- ~~**Criticality (asset.criticality)**~~ -> **Source (entity.type)**
- **Custom field**: Allow users to input/select a custom field for
grouping.
- [x] Display the following information for each group row:
- The grouped term value.
- The count of assets in that group.
- A button to expand the group and view the assets in a filtered
**DataGrid**.
- [x] Ensure group expansion dynamically displays assets in a DataGrid
filtered by the selected grouping field.
- [x] **Pagination**: Display 10 groups per page by default, with
pagination controls to navigate between pages.
- [x] **Rows per page dropdown**: Allow users to adjust the number of
groups displayed per page (options: 10, 25, 50, 100).
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] 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)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [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
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Risks
No risk since code is still hidden behind the *Enable Asset Inventory*
advanced setting and the beta *Cloud Asset* integration must be
installed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/194984
This PR uses the `EuiScreenReaderOnly` component to spell out trace per
minute instead of its abbreviation for screen readers
---------
Co-authored-by: jennypavlova <jennypavlova94@gmail.com>
Removes the "disabled" flag for Security's Entity Store feature from the
Security Solution's serverless configuration (i.e., effectively enabling
the feature in Serverless).
This feature has already been tested in ECH.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
In https://github.com/elastic/kibana/pull/170234, we added validation on
the security solution settings in serverless that is enabled through the
`xpack.securitySolution.enableUiSettingsValidations` config setting. In
this PR, we move this setting to `config/serverless.security.yml` so
that it follows the sustainable architecture principles.
Fixes#210619
## Summary
Provides a tags array on the request and response bodies of dashboards.
This allows consumers of the Dashboards HTTP API and internal RPC API to
add an array of tag names to the attributes in the body of create and
update endpoints. The dashboard server will be responsible for
converting the tag names into references in the saved object.
If, during creation or update, a tag name does not have a matching tag
saved object, a new tag saved object will be created. If the user lacks
permissions to manage tags, then an error will be logged in the server
and the tag will not be added to the dashboard.
The server also injects the tag references as an array of tag names in
the attributes of the response body of get and search endpoints of the
HTTP and RPC APIs.
For backwards compatibility in create and update endpoints, tags can
alternatively be specified in the `references` array in the options
instead of (or in addition to) the `attributes.tags` in the request
body. Similarly, for backwards compatibility, tag references are
returned in the `references` of the response body of get and search
endpoints.
Client-side tag handling is out of scope for this PR. Dashboards listing
page and dashboard settings continue to use the tag references and do
not use the `tags` attribute in the response.
For example:
Here's how we currently create a dashboard with tag references.
```
## Creating a dashboard with tag references
POST kbn:/api/dashboards/dashboard
{
"attributes": {
"title": "my tagged dashboard"
},
"references": [
{
"type": "tag",
"id": "37aab5de-a34d-47cb-9aa5-9375d5db595f",
"name": "tag-ref-37aab5de-a34d-47cb-9aa5-9375d5db595f"
},
{
"type": "tag",
"id": "5ed29bba-c14d-4302-9a8c-9602e40dbc2a",
"name": "tag-ref-5ed29bba-c14d-4302-9a8c-9602e40dbc2a"
},
{
"type": "tag",
"id": "fc7890e8-c00f-44a1-88a2-250e4d27e61d",
"name": "tag-ref-fc7890e8-c00f-44a1-88a2-250e4d27e61d"
}
]
}
```
With this PR, creating a dashboard with tags is much simpler.
```
## Creating a dashboard with tag names
POST kbn:/api/dashboards/dashboard
{
"attributes": {
"title": "my tagged dashboard",
"tags": [
"boo",
"foo",
"bingo",
"bongo"
]
}
}
```
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] If there are more than one tag saved objects with the same name,
only one of the tag references will be added to the saved object when
creating a dashboard. Creating tags with duplicate names are not
permitted via the UI. But there is no such restrictions when creating
tags from imported saved objects. Having multiple tags with the same
name is an edge case that Kibana guards against with reasonable
restrictions, so I think we should not be too concerned about it.
- [ ] ...
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
During upgrade of ES client in
https://github.com/elastic/kibana/pull/208776, preview logged requests
started to show `index` property in request body.
This PR fixes issue
Closes#214562
## Summary
This PR fixes the issue with the service icons overridden by the merge
of the service stats
## Testing
As this is a bit tricky to test - it needs a bit of refreshing /
changing the time range, etc. to reproduce
The way to verify the fix is to check the service overview - every
service that has an icon there should have an icon in the service
inventory:
https://github.com/user-attachments/assets/e401554b-6a39-440b-a52b-a126e42eacd5
# Unified Data View Picker: Phase 1 Implementation
Part of https://github.com/elastic/security-team/issues/11959
## What This PR Does
This PR represents the first step in our transition from the current
Sourcerer component to the new unified Data View Picker. Specifically,
this implementation:
- Creates a new Data View Picker component
- Implements feature flag protection for all changes
- Handles asynchronous effects through Redux listener middleware
- Establishes a new Redux store architecture to support ad hoc data
views infrastructure
- Utilizes ad hoc data views to handle legacy patterns from series 7
(replacing the previous upgrade data view flow)
See the readme for more info:
```x-pack/solutions/security/plugins/security_solution/public/data_view_manager/readme.md```
## What This PR Does NOT Cover
- Does not affect screens other than Timelines
- Does not modify the existing Sourcerer component in any way
- Does not fully support all URL/local storage patterns
## Implementation Notes
We've made several accommodations to support both Sourcerer and the new Data View Picker simultaneously during this transition period, including:
- Some interfaces might look odd, especially the hooks that return the data view or patterns - this is intentional to support existing use cases
- There are feature flag-based conditional statements throughout the code that will be removed once the transition is complete
## Testing Instructions
1. Add the following feature flag to your configuration:
```
xpack.securitySolution.enableExperimental: ['newDataViewPickerEnabled']
```
2. Navigate to the Timelines interface
3. Test interactions with the new Data View Picker
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
