Changes the dashboard endpoint routes from public to internal as they
are still unreleased.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/observability-dev/issues/4539
Fixes https://github.com/elastic/kibana/issues/221035
Enables custom roles for Observability projects in serverless.
The following is a summary of the changes:
## Feature renaming
1. Renamed `Uptime and Synthetics` to `Synthetics`
2. Renamed `APM and User Experience` to `Applications`
3. Renamed `Metrics` to `Infrastructure`
## Category reassignment
1. Changed `Dashboard` category from `Analytics` to `Observability`
2. Changed `Discover` category from `Analytics` to `Observability`
3. Changed `ML` category from `Analytics` to `Observability`
## Feature hiding
1. Hides the `Stack Alerts` feature.
2. Provides backwards compatibility for alerts created via Stack Alerts.
This enables our users to import rules created within Stack Alerts and
expect to see them in the Observability rules table.
## Navigation updates
1. Adds a `Custom Roles` link under the `Access` section in the
management navigation
2. Adds a `Manage Organization Members` link under the `Access` section
in the management navigation
3. Removes the `Users and Roles` link from the navigation footer (in
favor of the `Manage Organization Members link)
## Bug fixes
1. Fixes a bug where the `Alerts` link was not shown for Synthetics only
user (in stateful and serverless)
2. Fixes a bug where the `Alerts` link was not shown for Logs only user
(in stateful and serverless)
## Alert Override Removal
In the alerting framework, each rule is assigned a `consumer` value.
This `consumer` value changes depending on where the rule is created in
Kibana. However, in serverless we introduced an override that caused the
`consumer` value to be `Observability` in nearly every case. This logic
branched from stateful causing complexity and a large mental burden for
our engineers. Ultimately, this override became the source of bugs,
uncertainty, and unintended user experiences. Because of this, we've
removed this overrides.
If we kept this override, it would have the unfortunate side effect of
making all rules created in serverless visible from all custom roles (an
APM only user would have been can see Synthetics rules, and vice
versus). To make things more unpredictable, when users import their
rules from stateful the behavior would be different (access would be
properly mapped to the specific feature).
To address these specific user experience issues, and remove the source
of complexity, branching logic, and bugs, we removed this override logic
and restored the rule access behavior to match with stateful.
We did this while introducing backwards compatibility logic, ensuring
rules created in earlier versions of an oblt stateful cluster continue
to work and are accessible by a user with the right role access.
# Testing
1. Run local ES
```
yarn es serverless --projectType=oblt -E xpack.security.authc.native_roles.enabled=true
```
2. Run local Kibana
```
yarn start --serverless=oblt --xpack.security.roleManagementEnabled=true --xpack.cloud.users_and_roles_url="https://test_users_and_roles_url"
```
3. Login to Kibana with the admin role. Navigate to the Custom Roles
page via the management navigation.
4. Create a custom role
5. Log out of Kibana
6. Log back in with your custom role. You can do so by typing the custom
role name into the mock saml auth
<img width="460" alt="Screenshot 2025-05-22 at 9 23 13 PM"
src="https://github.com/user-attachments/assets/8e7f659b-5fe9-4e74-8c57-b420467d309e"
/>
---------
Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co>
Co-authored-by: Faisal Kanout <faisal.kanout@elastic.co>
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
## Summary
Resolves#221428.
We noticed recently when we added the Investigation Guide that, if the
user edits the values in the guide using the edit flyout, the data on
the main page will not refresh when they submit.
This patch would add an `onUpdate` handler prop to the Header Actions
component that would enable it to trigger the refresh on the parent
component when the user submits the form in the edit flyout.
Example:
## Summary
Main ticket ([Internal
link](https://github.com/elastic/security-team/issues/12790))
With these changes we add attack discovery alerts deduplication. Right
now identical attack are being stored within the alerts index and to
filter duplicates out we will use the next approach:
1. Each alert will have a ID generated as a SHA256 of attack attributes:
list of SIEM alerts IDs and space ID
2. After LLM generates attack discoveries we would check whether the
attack alert with the ID that describes the attack based on the rule
above exists in the alerts index
3. If such an alerts exists we would drop the generated discovery
4. Otherwise, we would proceed with storing the attack discovery as a
new alert
## NOTES
The feature is hidden behind the feature flag (in `kibana.dev.yml`):
```
feature_flags.overrides:
securitySolution.attackDiscoveryAlertsEnabled: true
```
## Summary
Resolves#221835.
Adds case links to the Alert Details status bar.
When there is exactly 1 case, the status bar displays that case's name
and links to the case detail page.
When there is more than 1 case, an additional link with the text `+N
cases` will render as well. This link simply sends the user to the Cases
overview page. We need improved filtering to allow the URL to pass a
series of case IDs to pre-filter the overview page to make the user's
landing experience better when using this feature.
If there is no linked case, the case links will not display anything.
## TODOS
Best not to review this until these are checked off.
- [ ] If the user utilizes the _Add to case_ feature of the detail page,
the cases shown in the status bar do not update. We should fix this
before merging.
- [ ] We should also ensure we have additional unit tests included for
the locator code 100% coverage, as it's a little tricky.
- [ ] We need unit tests for the links hook.
## Testing this PR
- Create three alerts.
- Do not attach the first one to any cases. Go to the detail page and
see that there is no case-related info displayed in the status bar.
- Attach the second alert to a case, and go to its detail page. See that
the case is shown in the status bar like `Case: {caseName}`.
- Attach the third alert to more than one case. Go to the detail page
and verify that the two links, `caseName` and `+ N more` are displayed
and that they function properly.
- Repeat this testing for a kibana with and without a basePath, and
across spaces, to ensure the locators are working correctly.
<img width="779" alt="image"
src="https://github.com/user-attachments/assets/f135bd1e-a0dc-45f2-a003-a375f7589cf0"
/>
## Summary
Closes https://github.com/elastic/kibana/issues/222555
Remove `confidence` and `is_correction` attributes from knowledge base
entry since they are no longer used.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [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: Søren Louv-Jansen <sorenlouv@gmail.com>
Since all the usage-api configs in CP has an `enabled` param, I'd like
to add that to connector usage reporting task as well. So we can
enable/disable the feature via config.
I got this PR deployed to serverless and was able to see a request to
usage-api:
<img width="1301" alt="Screenshot 2025-06-10 at 22 03 38"
src="https://github.com/user-attachments/assets/57c628fe-55a5-4d10-a2c0-82021be86fad"
/>
## Summary
This PR adds support for context awareness across tabs, allowing each
tab to have a separate data source profile and set of document profiles,
while all sharing the same root profile. Supporting this involved a few
main changes:
- Split out a separate `ScopedProfilesManager` class from the main
`ProfilesManager` to support managing data source and document profiles
separately from the root profile.
- Add a `createScopedProfilesManager` method to `ProfilesManager` to
support instantiating separate `ScopedProfilesManager` instances, which
are stored per tab in `RuntimeStateManager`.
- Add a `ScopedProfilesManagerProvider` component to provide access to
the current `ScopedProfilesManager` instance wherever it's needed
(Discover, Single doc, Surrounding docs, and the Discover session
embeddable).
Since this PR adds yet another React context provider to Discover (can't
be provided via `RuntimeStateProvider` since `ScopedProfilesManager`
must be accessible outside of the main Discover app), a new
`DiscoverTestProvider` helper component has been introduced, rather than
copy/pasting `ScopedProfilesManagerProvider` throughout the Jest tests.
All existing Discover tests that rely on providers have also been
updated to instead use `DiscoverTestProvider`. This greatly simplifies
test setup by ensuring the correct providers are automatically rendered
based on the passed props. It's also much more future proof since any
changes to providers later on no longer require updating dozens of test
files, and instead only the shared `DiscoverTestProvider`.
There are some changes here that will require updates to the context
awareness docs, which will be handled as part of #217128.
Resolves#216488.
### 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)
- [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)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes: #151493
**Description**
Ensure consistent screen reader announcements for errors when saving a
Dashboard with the "Create Tag" workflow.
**Changes Made**
Added the required` aria-invalid` attribute at the appropriate location
to support screen reader error announcements.
**Notes**
The original issue suggested setting `aria-live="assertive"`, but this
may not be necessary. Based on our current accessibility guidelines,
using `aria-invalid` is sufficient and aligns with best practices.
**Screen**
<img width="1434" alt="image"
src="https://github.com/user-attachments/assets/afe1416b-34d2-46b5-88c4-fcac6a1f4c86"
/>
## Summary
Resolves#212419.
In the Synthetics plugin, we are referencing the action connector form
provided for Email. The a11y audit noted that the `Cc` and `Bcc`
features on this form break the focus flow and make the page
inaccessible. This patch will apply `autoFocus` to the combo box
elements that get rendered when these buttons are clicked, thus allowing
screen reader and keyboard-only users to navigate the UI properly.
**NOTE:** you may see an example of the failure on the linked issue. I
have re-created the flow using VoiceOver and keyboard navigation and
included a GIF of it below.
## Example
This PR closes#221947.
https://github.com/user-attachments/assets/25beac10-5677-42ef-9544-b3ede0bf9fa1
The last part of the video is me trying to find the telemetry event
fired when clicking the button.
**Acceptance Criteria:**
- The list should appear on the Related Dashboards tab, under the Linked
Dashboards ✅
- Users should have the ability to add or "promote" a suggested
dashboard to the list of linked dashboards stored on this rule, in a
single click ✅
- We are collecting telemetry so that we know how many times users click
the button to promote a suggested dashboard to a linked dashboard ✅
---------
Co-authored-by: Dominique Belcher <dominique.clarke@elastic.co>
## Summary
Following the advice from Matuesz, Emotion Maintainer, this PR enables
Emotion’s speedy mode (`insertRule` instead of `<style>` tag injection)
in the development environment.
## Why?
We recently investigated an issue related to [Emotion’s style tag
bloat](https://github.com/elastic/kibana/issues/218340). It turned out
that the slowdown only affects development — in production, Emotion uses
`insertRule`, which is significantly more performant.
In dev, Emotion injects a new <style> tag for each rule to improve DX,
but this can lead to major slowdowns, especially when rendering many
components. Speedy mode avoids that by using `insertRule`, which has
been measured to be even >10x faster.
### Why now?
The original reason for disabling speedy mode in dev (inability to
inspect/edit styles) is no longer a limitation in modern browsers
(Chrome, Firefox).
The slowdown in dev doesn’t reflect real prod performance, making it
harder to reason about actual bottlenecks. It also makes some of the
devs worried that Kibana performance is worse than it actually is on
prod.
### What's the degugging difference?
https://github.com/user-attachments/assets/58d911a7-e621-4144-8f1f-8b43101c44e2
The difference is that you can’t see the styles in the DOM or the
stylesheet (see the video), neither the source maps for styles. You can
still edit them in the dev tools, but clicking the source link takes you
to an empty style tag. I don’t see that as a big problem - styles are
still easy to find in the code since the files containing them are part
of the auto-generated classnames.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Changelog: https://github.com/sorenlouv/backport/releases/tag/v10.0.1
Updating to 10.0.1 fixes an issue where the backport tool would throw an
exception if SAML is not authenticated for the github access token used
by backport:
```
⚠️ Ouch! An unhandled error occured 😿
TypeError: Cannot read properties of undefined (reading 'type')
at /Users/trentm/el/kibana/node_modules/backport/dist/lib/github/v4/getInvalidAccessTokenMessage.js:20:27
at Array.some (<anonymous>)
at getInvalidAccessTokenMessage (/Users/trentm/el/kibana/node_modules/backport/dist/lib/github/v4/getInvalidAccessTokenMessage.js:18:55)
at getOptionsFromGithub (/Users/trentm/el/kibana/node_modules/backport/dist/lib/github/v4/getOptionsFromGithub/getOptionsFromGithub.js:38:109)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async getOptions (/Users/trentm/el/kibana/node_modules/backport/dist/options/options.js:66:31)
at async backportRun (/Users/trentm/el/kibana/node_modules/backport/dist/backportRun.js:51:19)
at async Object.backportRun (/Users/trentm/el/kibana/node_modules/backport/dist/entrypoint.api.js:33:17)
Please open an issue in https://github.com/sorenlouv/backport/issues or contact me directly on https://twitter.com/sorenlouv
For additional details see the logs: /Users/trentm/.backport/backport.info.log
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/192910
url_field_formatter functional test was
[skipped](https://github.com/elastic/kibana/pull/193293) in Sept 2024.
Instead of removing `.skip`, the entire test should be removed for the
following reasons
1) It does not test dashboard code. The test verifies rendering of
legacy visualize table on a dashboard and discover table (in the
discover app). Both of these are not our area of responsibility.
2) the test case is better covered by unit tests.
## Summary
This PR adds the initial FTR test setup for the serverless Observability
Logs Essentials tier.
> [!IMPORTANT]
This PR is focused on providing the base structure and make sure the
tests can run in CI. The included tests are serving as usage examples
only and will have to be extended by Logs Essentials owners to achieve
proper test coverage.
### Changes
> [!NOTE]
The selection of tests for the logs essentials tier happens through
inclusion in specific test index files which are loaded by logs
essentials specific test config files. No tagging or other modification
of existing tests needed - the keep running for the complete tier. Test
files / directories can be included in complete tier test index files or
logs essentials tier test index files or both, giving us full control
over which tests are running where.
#### `x-pack/test_serverless`
- Add api_integration and functional config files and index files,
including common tests and load some example tests each - this way,
existing complete tier tests can be selected and included fro logs
essentials test runs.
- Add api_integration and functional `logs_essentials_only` directories
and include them in the logs essentials test index file - this way, new
test can be created that do not run on the complete tier and are
specific to the logs essentials tier.
- Add one example test each (assert the SLO settings API is not
available / assert the SLO menu entry is not displayed). These serve as
placeholders and are mainly there to demonstrate usage of this area -
going forward, they should be replaced, extended and/or modified as
needed.
#### `x-pack/test/api_integration/deployment_agnostic`
- Extend serverless base config parameters with an optional `tier` so
actual configs calling `createServerlessTestConfig` can provide a
`tier`.
- Add logs essentials specific config and index file and include core
tests as an example.
- There are no `logs_essentials_only` tests in this area, because logs
essentials is a serverless only option and as such tests specific to
that option should go into the `test_serverless` directory.
This PR closes#216235 by swapping the primary `Snooze the rule` button
with the `Add to case` acton.
https://github.com/user-attachments/assets/7b59fae0-9d16-4a31-95dc-a3890ab6632d
**Acceptance criteria:**
- This primary action for all alert details pages in observability
should be "Add to case" ✅
- The snooze rule action can be moved to the sub actions menu ✅
- The existing "Add to case" action present in the sub menu (see below)
should be removed (replaced by the primary button) ✅
- The button should allow the user to add this current alert to a new or
existing case ✅
Closing https://github.com/elastic/kibana/issues/221919
## Summary
In this PR, I'm adding the Attributes doc viwer tab for the
**Observability solution view.**
The tab should be visible for all discover documents that have any of
the following prefixes
```
const attributesPrefixes = ['attributes.', 'scope.attributes.', 'resource.attributes.'];
```
Also,
- Group the observability document profile providers into one file
> [!IMPORTANT]
> The content of the tab is not inlcuded in this PR. it will be part of
this [ticket](https://github.com/elastic/kibana/issues/221927)
## Additional changes
For the existing profiles, logs, traces I updated the condition to check
the solution
From `params.rootContext.profileId === OBSERVABILITY_ROOT_PROFILE_ID` to
`params.rootContext.solutionType === SolutionType.Observability`
IMO both are prone to errors.
- As I'm extending the root profile, the above statement is not true. it
returns the new extended profile ID
- Also, if we add more extensions to the root profile and we add another
solutionType by mistake the profiles won't work
I updated the type
https://github.com/elastic/kibana/pull/222391/files#diff-ff7a53f0c234902226be3e34978326985dfffadabb8ae722b6c3fc2115085d11R14
but it might not be enough.
## Test
#### How to generate OTel data
- Follow
https://github.com/smith/elastic-stack-docker-compose?tab=readme-ov-file#elastic-stack-docker-compose
#### How to test
- Make sure your solution view is Observability
- update your `kibana.yaml`
```
discover.experimental.enabledProfiles:
- observability-root-profile-with-attributes-tab
# if you want to test it with the additional profiles add the following to your `kibana.yaml`
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Address https://github.com/elastic/kibana/issues/216061
Adds an indirection layer in the definition of the `transformFn:`, which
forces devs to explicitly define the types of the documents being
transformed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR is mostly about moving tests from
x-pack/test/alerting_api_integration
Before:
```
x-pack/test/alerting_api_integration
| - basic/
| - common/
| - observability/
| - packages/
| - security_and_spaces/
| - spaces_only/
| - spaces_only_legacy/
```
After:
```
x-pack/platform/test/alerting_api_integration
| - basic/
| - common/
| - packages/
| - security_and_spaces/
| - spaces_only/
| - spaces_only_legacy/
x-pack/solutions/observability/test/alerting_api_integration
| - observability/
x-pack/solutions/security/test/alerting_api_integration
| - security_and_spaces/group1/
| - security_and_spaces/group2/
```
Details:
- few tests in original `backfill` dir use helper function relying on
import from `@kbn/security-solution-plugin`, both tests and helpers were
relocated to `x-pack/solutions/security/test` dir.
- `observability` dir and its tests were relocated directly to
`x-pack/solutions/observability/test` dir.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Customers who enabled risk scoring in a version below 8.18 and then
upgraded to 8.18 or 9.0, will find risk scoring stops working in 0-30
days, this is because the ingest pipeline to set event ingested is not
installed, but is specified on the risk scoring index, causing all
writes to fail.
This PR fixes this by installing the ingest pipeline in all spaces where
either:
- risk scoring is set up (the risk-engine-configuration saved object is
present)
- the asset criticality index exists
This PR also increases the internal versioning of the asset criticality
and risk scoring indices, to trigger the migration which will:
- add the pipeline to the asset criticality index
- add the pipeline to a risk scoring index which hasnt been rolled over
- remove the pipeline from the risk scoring latest index if it is set
(if risk scoring was set up in 9.0 or 8.18 for the first time) we remove
this because the latest index should not modify the risk scoring
documents.
The result is that asset criticality and risk scoring should work and
event.ingested should correctly be set.
## Other important technical changes
- whenevr we increase the risk scoring internal index version, this will
now trigger a rollover on the data stream
- asset criticality and risk scoring index migrations now support
settings changes
## test steps
- on 8.17 initialise risk engine and generate some risk scores
- upgrade to 8.18.0 or 9.0.0
- rollover the risk score latest datastream dev tool `POST
/risk-score.risk-score-default/_rollover`
- verify risk scoring has broken, easy way is by assigning asset
criticality in the entity flyout
- upgrade to 9.0.3 or 8.18.3
- verify risk scoring and asset criticality work
## Test steps for local env:
- start kibana
- checkout SDG branch
https://github.com/elastic/security-documents-generator/pull/153
- run `yarn start risk-score-ingest-bug` AS SUPERUSER
- observe asset criticality assignment results in an error / is not
performed
- restart kibana
- observe the ingest pipeline has been created and it works again
dev tools verification:
```
# the pipeline should have been created
GET /_ingest/pipeline/entity_analytics_create_eventIngest_from_timestamp-pipeline-default
# the mapping version should be 4 and the default pipeline should be set
GET /.asset-criticality.asset-criticality-default
# the mapping version should be 4 and the default pipeline should be set
GET /risk-score.risk-score-default
# the default pipeline should be set
GET /_index_template/.risk-score.risk-score-default-index-template
# the default pipeline should NOT be set
GET /risk-score.risk-score-latest-default
```
Other verifications:
- risk scoring should work
- asset criticality assignment should work
- ???
---------
Co-authored-by: machadoum <pablo.nevesmachado@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Updating playwright dependencies to the latest. Should be merged only
after https://github.com/elastic/synthetics/pull/999
---------
Co-authored-by: Shahzad <shahzad31comp@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
These optimizations aim to improve the performance of the bulk actions
endpoint.
The first optimization has to do with how we resolve rules before
executing the bulk actions. Before this PR we were doing this
sequentially, but a `bulkGet` method has been added to the rules action
client.
The second optimization greatly improves the update gaps routine that
occurs after a backfill is scheduled (see the before and after
screenshots below).
The following screenshots were taken under these conditions:
I triggered a manual run bulk action on 1 rule (5m) with 1000 gaps over
a period of 90 days.
Before:
After:
## How to test?
Use [this tool](https://github.com/elastic/security-documents-generator)
to create 1 rule (5m) with 1000 gaps.
```
yarn start rules --rules 1 -g 1000 -c -i"5m"
```
Then do a manual run on it for a period of 90 days.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Reopening of https://github.com/elastic/kibana/pull/223362
In https://github.com/elastic/kibana/pull/221474 we introduced the
mechanism to register queries per solution at the editor.
This PR displays these queries in the unified search menu too. In the
following screenshot the 2 first queries are the oblt solution
registered queries. I also have a max-height just to be sure that this
list doesnt get too long now that the solutions can register queries.
<img width="439" alt="image"
src="https://github.com/user-attachments/assets/8ca48b8a-1880-42f3-944f-dd1fb012661f"
/>
### Note
This change won't display anything in the popover as no solution has
registered any queries yet. This PR sets the mechanism though on when
they will do so.
### How to test
If you want to test it the fastest way is to go to the esql plugin
(server side) and add (change the examples as you wish):
```
this.extensionsRegistry.setRecommendedQueries(
[
{
name: 'Logs count by log level',
query: 'from logs* | STATS count(*) by log_level',
},
{
name: 'Apache logs counts',
query: 'from logs-apache_error | STATS count(*)',
},
{
name: 'Another index, not logs',
query: 'from movies | STATS count(*)',
},
],
'oblt'
);
```
Then go to Discover (solutions mode) and type `from logs*` and hit the
query. Open the popover and check the 2 first recommendations are been
suggested.
### Checklist
- [ ] [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
<!--ONMERGE {"backportTargets":["8.19"]} ONMERGE-->
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [react-window](http://react-window.now.sh/)
([source](https://redirect.github.com/bvaughn/react-window)) |
dependencies | patch | [`^1.8.10` ->
`^1.8.11`](https://renovatebot.com/diffs/npm/react-window/1.8.10/1.8.11)
|
---
### Release Notes
<details>
<summary>bvaughn/react-window (react-window)</summary>
###
[`v1.8.11`](https://redirect.github.com/bvaughn/react-window/blob/HEAD/CHANGELOG.md#1811)
[Compare
Source](https://redirect.github.com/bvaughn/react-window/compare/1.8.10...1.8.11)
- Dependencies updated to include React 19
</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:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOktpYmFuYSBNYW5hZ2VtZW50IiwiVGVhbTpNb25pdG9yaW5nIiwiYmFja3BvcnQ6YWxsLW9wZW4iLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
---------
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Matthew Kime <matt@mattki.me>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR addresses https://github.com/elastic/kibana/issues/171104. A
summary of changes is as follows:
1. Adds new `keyword` mappings to the alerting index(es):
* `kibana.alert.original_data_stream.dataset`
* `kibana.alert.original_data_stream.namespace`
* `kibana.alert.original_data_stream.type`
2. Adds new Detection Engine logic to copy these source data to the new
path while building the alert
* Formalizes/abstracts the above copying mechanism, as we were
previously doing this for `event.*` fields as well.
## Steps to review
1. Sanity-check my changes to the versioned alerting types (I just cargo
culted that)
1. Load some data with the relevant fields (here we use the archive
accompanying these integration tests):
TEST_ES_URL=http://elastic:changeme@localhost:9200
TEST_KIBANA_URL=http://elastic:changeme@localhost:5601 node
scripts/es_archiver.js load
x-pack/test/functional/es_archives/security_solution/ecs_fields_duplicated_for_alerts
1. Create a rule against that data:
* index: `ecs_fields_duplicated_for_alerts`
* 3 records ~ `2025-05-07T14:34:11.000Z`
1. Observe that the generated alerts contain the new fields referenced
above:
<kbd><img width="700" alt="Screenshot 2025-05-07 at 5 21 47 PM"
src="https://github.com/user-attachments/assets/fc765480-c57a-4149-937c-8d8acaa082b2"
/></kbd>
1. (Optional) Observe that the generated alerts contain the existing
`kibana.alert.original_event.*` fields as before:
<kbd><img width="700" alt="Screenshot 2025-05-07 at 5 21 56 PM"
src="https://github.com/user-attachments/assets/da3b8396-40b8-47d6-b9dc-81861f54a7ee"
/></kbd>
## Release note
Improves alert searching and filtering by including `data_stream` ECS
fields under `kibana.alert.original_data_stream.*`
### Checklist
- [x]
[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
- [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)
## Summary
Relates to https://github.com/elastic/kibana/issues/212125
When a Lens panel is saved to a dashboards, it is either saved by value
or by reference. If it's saved by reference, the attributes will not be
available. This was creating a reference error when attempting to
inspect the lens configuration to make suggestions.
This PR confirms that the attributes are available.
A follow up PR will fetch the values for the references to include them
in the evaluation.
Follow up PR to this
[comment](https://github.com/elastic/kibana/pull/221848#discussion_r2113901297)
## Summary
Right now we are pre-populating the combo box with all dashboards every
time the create rule or edit rule is opened
## ACCs
- fetch the dashboard list only if the combo box is focused
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Solves the focus issue with
https://github.com/elastic/kibana/issues/215841https://github.com/user-attachments/assets/97faffe4-1d5c-4aca-92a8-0b9e08220250
### Steps to reproduce
1.Navigate to existing map in the table.
2.Navigate to Tools on the map and press Enter.
3.Navigate to to Draw shape to filter data and press Enter.
4.Navigate to Draw shape and press Enter.
5. In the ideal word we'd be able to draw a shape with a keyboard here,
but this is unfortunately impossible. However, another problem is that
the focus is lost on the page. This PR at least adds a focus to the
`Cancel` button so the user can abandon the not-supported by keyboard
action.
Closes#223533
## Summary
To fix the issue I replaced the `metrics-*` with `*:metrics-*,metrics-*`
in the ES|QL queries
## Testing
- With local connection to a new edge edot cluster (created with the
oblt-cli tool)
- Go to APM > Services and click on the `ad` service
- Open the Metrics tab
- The charts should load
