This PR adds a rate limiter to control connector usage rate limiting.
It supports only `email` connector for now, but the other connectors can
be added by adding their connectorTypeId to the `validConnectorTypeIds`
list.
## To validate:
Add the below config to your `kibana.yml`
```
xpack.actions.rateLimiter.email
lookbackWindow: '310s'
limit: 4
```
And create a rule that triggers an email action every 1 minute.
On the 5th execution you should see an error message like: `Action
execution rate limit exceeded for connector: .email`
30 seconds after that the action should be successfully retried.
You can test with other connectors as well (e.g. .server-log). In order
to do that, the connectorTypeId should be added to the
`validConnectorTypeIds` list in the config file.
`const validConnectorTypeIds = new Set(['email']);` -> `const
validConnectorTypeIds = new Set(['email','server-log']);`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
These changes fix the issue with the markdown fields that we return
within the action's context for Attack Discovery Schedules.
Right now if the second part (the `value`) of the `{{ field value }}`
elements within the details markdown fields has whitespaces the RegEx
won't capture those and thus we will not transform them into a desired
format - `value`.
With the help of gemini I generated the expression that handles
whitespaces within the value part:
```
new RegExp('{{\\s*(\\S+)\\s+(.*?)\\s*}}', 'gm');
```
### Gemini reasoning
To fix your RegEx and capture substrings like `{{ file.hash.sha256 fake
file sha256 }}`, you need to modify the second capturing group to allow
for spaces.
Here's the corrected RegEx: `{{\s*(\S+)\s+(.*?)\s*}}`
Here's a breakdown of the changes:
* `(\S+)`: This remains the same, capturing the first part (e.g.,
`host.name`, `file.name`, `file.hash.sha256`) which does not contain
whitespace.
* `(.*?)`: This is the key change.
* `.`: Matches any character (except newline).
* `*`: Matches the preceding character zero or more times.
* `?`: Makes the `*` quantifier non-greedy, meaning it will match the
shortest possible string. This is important to prevent it from matching
across multiple `{{ ... }}` blocks if they were on the same line.
This updated RegEx will now correctly capture both
`835a4be1-8f35-431f-93a0-c89935726b2e` and `fake file sha256` as the
second captured group.
### RegExp testing
https://regexr.com/
<img width="2043" alt="Screenshot 2025-06-27 at 10 51 21"
src="https://github.com/user-attachments/assets/e0f13c1b-a1d7-477e-9fdd-1624919395f1"
/>
## Summary
Related issue: https://github.com/elastic/kibana/issues/221827
The changes in this PR for now will only apply in serverless.
This PR adds the following changes in a serverless environment:
- removes the allocations/threads input fields from the inference
endpoints UI creation and replaces it with an input for max allocations
- adds informative text for the user when adaptive allocations will be
enabled
- always sets adaptive allocations to be enabled and min_allocations to
0
Entry points tested:
- Inference endpoints list page > `Add endpoint` button
- Playground > `Connect to an LLM` button
- Connectors list page > `Create connector button`
- AI Assistant > `Set up GenAI Connector` button
- Index management > create index with mapping > add semantic text field
## TASKS
~~- [ ] implement helper class to calculate appropriate value for
`num_threads` based on max allocations specified by the user. This will
be done keeping in mind that it will be optimized for search with high
resource use.~~
- ML nodes will set a default number of threads in serverless trained
model APIs - this will require a backend change (I will link PR here
when available)
- Until that change is made, `num_allocations` will be defaulted to 1 as
the endpoint currently requires that parameter
- [x] minimum allocations will always be 0
- [x] Add serverless check in AI Connector to ensure behavior is the
same
## TO NOTE
The field overrides added are a temporary solution until the endpoint
returning the service's configurable fields can be updated.
As the code is shared with the AI Connector - this behavior will also
apply for Elasticsearch service when on serverless.
### 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)
- [ ] 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
- [ ] 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>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR adds the ability for users to create and manage their own ESQL
based tools through API endpoints `/api/chat/tools/esql`. The tools are
persisted into a hidden index that serves as the source of truth for the
ESQL Tool Provider that is registered on start to manage the tools and
expose them to the Onechat registry.
**ESQL Tools**
- The tools follow a common schema when being created
```
id: schema.string(),
name: schema.maybe(schema.string))
description: schema.string(),
query: schema.string(),
params: schema.recordOf(
schema.string(),
schema.object({
type: schema.string(),
description: schema.string(),
})
),
meta: schema.object({
tags: schema.arrayOf(schema.string(), { defaultValue: [] }),
}),
```
- Queries follow this pattern `"FROM my_cases | WHERE case_id ==
?case_id | LIMIT 1"` where parameters that are needed to execute the
query are shown with a '?'.
- this feature is under a feature flag so you will need to update you
`kibana.yml `file with
```
uiSettings.overrides:
onechat:esqlToolApi:enabled: true
```
Not in the PR:
- `_execute` endpoint to test tools
https://github.com/user-attachments/assets/7e25b7e2-5190-4dfc-8dbc-3afd20982706
### 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)
- [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
- [ ] 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
- [ ] 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Sean Story <sean.j.story@gmail.com>
Fixes#225559
## Summary
Remove `schema.maybe` from `perPage` query attribute on Dashboard
listing endpoint.
When a property has `schema.maybe` and a `defaultValue`, the assigned
`defaultValue` is not used and the property falls back to undefined.
This was not previously detected, because the saved objects client
applies a per page limit of 20 if the setting is undefined.
## Summary
Serverless observability project would throw when creating a rule with a
system case action.
`Action 'system-connector-.cases' failed: an error occurred while
running the action: Failed to bulk create cases: Error: Unauthorized to
create case with owners: "cases"`
To fix it, we set the owner to be the serverless project type and if
serverless but unknown, we default the owner to "cases"
### How to test
1. Start ES with cloud projectId flag like this: `yarn es serverless
--projectType=oblt -E xpack.cloud.serverless.project_id: test-123`
2. Go to management rules page by searching for `rules` in the top
searchbar
3. Create a stack rule (index threshold) and add the cases action
4. When an alert is triggered confirm you can view the case in the cases
page
---------
Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>
## Summary
This is the 3rd time i am seeing this particular test due to no reason
failing on the overnight [MKI
Jobs](190f2d7aea.html?response-content-type=text%2Fhtml&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=ASIAQPCP3C7LZABMSFPC%2F20250624%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20250624T073221Z&X-Amz-Expires=600&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEDAaCXVzLWVhc3QtMSJHMEUCIQD3ZIdNEBZ%2Faco2J7lNN6JntielBfuzftliTQO%2B5TL6WQIgEww3Ps0ogDuwu2A0nkbDH8R%2BJmrBXBZIMT3tSkjhpvwq8QMIKBAAGgwwMzIzNzk3MDUzMDMiDF4g3TZsvMi%2BTND5dSrOA5%2F9oH%2BOGLj2zjXHJTHPq1nX0ZBY9gPV6S8fGbyrFtMGWmvJ63y4qVt7c6Y0aLDLqHf%2BMvetLeJFv3oiV%2BLkaK60NV0GC2P3nWhPAxR9hxVfEcl2k1blrSwNCQhqdd%2BX8jWVxkHo0M1jdJdfvPf3vaQG889KGVnNk4Sbhmpmj5LvWS4CyAyVZAXb1itO1KZGlLaZ4%2FK50LoA5CUI%2BfDfT4aVCMlQ%2BjtTQsGXPSDbF78KzqhJUdQgoeTdej%2FwcV0t%2FRrP9j%2BLYCbJRZbUWoeYjKeBQvgCk5bpDuWi6CWX2iMH7occK%2BVTeuIU5EMGsSAWkjpG9E78xE0q7xm0rvKxfQ6%2BeGmPLIxnG2jCezsPD6I9PKWQeGB70ncAPzzd7zAxBgujvr4cEliGzTiOSslP8wrXh5Hrg19H087r6xawHAP7XiV7jbaCwcpi09dEwRl1Q3O9CdUW4EN7uWDt9gVM97HFT1O%2BILjvIlUhVSZ4qtCcEyTCIAquHZn7COlajnOz%2B8UJdXzOwDg9h7CzD83pW3DIigGJrb8yHQ5IlwAahq%2FzJ6JCvZ5Q2LOLhjMVJ%2BiNr8Sw7xTIxFIqgOqv7lH0EFkAJ7fYZA5k%2F6SOkzWHWDDLoOnCBjqlAaobshAs0a1L9PjBtih5SVnuWknfnWBFK76rXa9uupOa28n8nzHz83pmSEeVzMp529Wge1451qmBsBlSvS5f315rpO1PTLp73ulHAETrX3MQlCyplnIHd642GFQcqyM616ThO9yCUYataOlU4jLHlT6shcOgyRXENmIWLe1IjrwMgICBNmoo9QxpmApfbL2CiC0wdUCKFbhChv%2BZ76eqWTCZEqahDg%3D%3D&X-Amz-SignedHeaders=host&X-Amz-Signature=8ea3ab47bde2b997384f5c6dde9592c3c0d9a2aa6697324bff44cfeffd41d07c)
It is almost impossible to reproduce it locally via MKI. I only got it
once and then it never happened.
My suspicion is the previously open flyout did not close. Hence as a
trial and error, i changed the index of the row to instead of always
opening the flyout for the 1st row, we force opening flyout for the 2nd
row.
Hopefully this should get away with the flakiness.
## Summary
It fixes https://github.com/elastic/security-team/issues/12544
This PR updates the URL query handling logic to allow Rison encoding and
decoding for multiple keys. This fixes an issue where reloading the page
or filtering/searching were making the flyout disappear since it was
missing it's reference on the URL params.
* **Added support for flyout and multiple Rison parameters**: New
functions (`encodeFlyout`, `decodeFlyout`, `encodeRisonParam`,
`decodeRisonParam`, `encodeMultipleRisonParams`,
`decodeMultipleRisonParams`) were introduced to handle encoding and
decoding of flyout parameters and multiple Rison parameters.
### Refactoring of `useUrlQuery` hook:
* **Support for multiple URL parameters**: The `useUrlQuery` hook was
refactored to decode and encode multiple Rison parameters, including
flyout-specific parameters, while maintaining separation between query
and flyout namespaces. Helper functions (`buildFlyoutSearchString`,
`combineSearchParts`) were added to streamline the construction of
search strings.
### Recording
https://github.com/user-attachments/assets/14205787-48dd-4306-bc0f-ac25958b694a
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 📄 Summary
- Adds a callout to the Scheduled reports flyout when none of the
available report types is supported for scheduling to avoid showing the
flyout with an empty type selector
- Adds `csv_v2` to the list of supported report types
<details>
<summary>
## 🧪 Verification steps
</summary>
### No supported report type for scheduling
- If you don't have data in Kibana, navigate to Home > Try sample data
and activate a sample data set
- Create a role (and relative test user) with access to some ES indices,
a license != `basic` and privilege for Visualize Library without
subfeature privilege for scheduling PDF and PNG reports:
<img width="723" alt="image"
src="https://github.com/user-attachments/assets/7e413a51-8d14-4b3b-af9d-24f82e6f9ea6"
/>
- Log in with the unprivileged user and navigate to `Analytics >
Visualize Library`, then create a visualization of type Lens
- Drag any field in the lens UX so that the ⬇️ (Export) menu in the
toolbar becomes clickable and click it
- Click on `Schedule export`
- Check that the flyout shows a warning callout for unsupported report
types
#### csv_v2 support
- Log in as an admin or user with access to Discover
- Navigate to Discover, toggle ES|QL mode
- Open the ⬇️ (Export) menu in the toolbar
- Click on `Schedule export`
- Check that the `CSV` option is available and scheduling works
correctly
</details>
<details>
<summary>
## 🐞 Known issues
</summary>
The CallOut for missing report types is a temporary solution until we
can hide the schedule button altogether (this requires changes in the
SharedUX share menu API)
</details>
<details>
<summary>
## 📷 Screenshots
</summary>
Warning CallOut
</details>
## 🔗 References
Refs #225606
## Summary
Implements #218172
Adds a "triggered" column for related alerts that shows either a
relative time value or an absolute timestamp of when the alert was
triggered/created if the duration is greater than 2 hours. This PR also
sets up the time duration display logic to be separated out into a
reusable component. This component was inserted into the common folder
of the observability plugin and is exported for use in other packages.
Note: There is a [draft
PR](https://github.com/elastic/kibana/pull/223972) where the elapsed
time tooltip component was created as a kibana package. This PR
encourages wider use across the app, but it fragments the design of
observability formatters by moving the datetime formatter to the
package.
<img width="679" alt="Screenshot 2025-06-13 at 4 01 27 PM"
src="https://github.com/user-attachments/assets/9150ffc5-f6f4-4760-b5ea-7cc91d60ea3f"
/>
## Summary
Summarize your PR. If it involves visual changes, include a screenshot
or gif.
Fixes various bugs introduced by this PR
https://github.com/elastic/kibana/pull/223936
Changes:
- Fix bug where esql_content_references (citations that open the ESQL
editor) were not working due to the discover plugin not getting imported
to the elastic_assistant plugin. This caused the assistant to crash.
- Fix bug where some buttons in the AI4Soc flavour were not linking to
the correct pages.
https://github.com/elastic/kibana/pull/223936#discussion_r2164506213
### How to test:
#### Verify ESQL citations work:
- Start Kibana
- Create a semantic index and index a document through the dev console:
```
PUT my-index-000001
{
"mappings": {
"properties": {
"description": {
"type": "semantic_text"
}
}
}
}
# Add a document to my-index
POST /my-index-000001/_doc
{
"id": "Security threats",
"title": "Stuxnet",
"description": "What Made It Special:
Stuxnet was the first known cyber weapon designed to cause physical destruction. It targeted the Iranian nuclear program by infecting uranium enrichment facilities and sabotaging centrifuges."
}
```
- Set up a knowledge base and a knowledge base index in
http://localhost:5601/app/management/kibana/securityAiAssistantManagement?tab=knowledge_base
<img width="678" alt="image"
src="https://github.com/user-attachments/assets/a267146e-7973-4723-8c1d-365b8729a28e"
/>
- Open the security AI assistant and ask "What is the Stuxnet computer
virus?"
- Check the response to see if it contains a citation, click on the
citation, and verify the ESQL editor opens.
* If you don't get a citation, ask "What is the Stuxnet computer virus?
Provide me the citation"
#### Verify Ai4Soc buttons in the Security AI assistant link to the
correct pages:
- Start AI4Soc flavor - Create the following file
`config/serverless.security.dev.yml` with this content:
```yml
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
- Start serverless ES
```bash
node scripts/es serverless --projectType security --clean --kill
```
- Start serverless Kibana for security
```bash
node --no-experimental-require-module scripts/kibana --dev --serverless=security --no-base-path
```
- Open the security AI assistant
- Check that clicking on these buttons takes you to the respective pages
(KB settings
`/app/security/configurations/ai_settings?tab=knowledge_base` and AI
settings `/app/security/configurations/ai_settings` ):
<img width="690" alt="image"
src="https://github.com/user-attachments/assets/4e2728e9-8a13-4670-aef4-05b1bdb3fd57"
/>
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [X] 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)
- [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] 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.
- [X] [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)
### 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
> [!IMPORTANT]
> **Should be no user-facing changes!!!** The new layout work is behind
a feature flag!
> [!IMPORTANT]
> This bootstraps new grid layout for chrome using a feature flag. It
only works with classic nav and hack a lot of bugs and EUI-related
workarounds, but the overall code structure and approach can be reviewed
and merged to main.
## Summary
Part of [workspace
chrome](https://github.com/elastic/kibana-team/issues/1581 ) work. In
this PR we lay down the ground work for new grid layout that will power
Kibana's chrome. This is done by introducing **a feature flag** with
which Kibana can switch between "legacy-fixed" layout and new "grid"
layout.
Proper detailed figma link:
https://www.figma.com/design/10ca4AhnWDkyJklUDXnHg5/Sidebar?node-id=5192-259808&p=f&m=dev
kibana.yml:
```
feature_flags.overrides:
core.chrome.layoutType: 'grid'
```
For this, in-between `rendering_service` and `chrome_service` a new
`layout_service` was introduced the goal of which is to aggregate stuff
from chrome service and compose it together using the needed layout.
There are two implementations for `layout_service`:
- `LegacyFixedLayout` - old one, just code refactor, should still work
as in main
- `GridLayout`- new one, mostly works, but only for classic nav, for
now, and with bunch of hacks and bugs that we will resolve over time
The switch is in `rendering_service` based on a feature flag:
```tsx
const layout: LayoutService =
layoutType === 'grid'
? new GridLayout(renderCoreDeps)
: new LegacyFixedLayout(renderCoreDeps);
const Layout = layout.getComponent();
ReactDOM.render(
<KibanaRootContextProvider {...startServices} globalStyles={true}>
<Layout />
</KibanaRootContextProvider>,
targetDomElement
);`
```
To see the grid and new layout in action there is a helpful `debug` flag
that displays not yet used elements of new layout:
kibana.yml:
```
feature_flags.overrides:
core.chrome.layoutType: 'grid'
core.chrome.layoutDebug: true
```
https://github.com/user-attachments/assets/9e4ad1d9-ed23-41ab-b029-254f7511136d
### Other clean ups
- Migrate `.chrHeaderBadge__wrapper`, `. chrHeaderHelpMenu__version`,
`breadcrumbsWithExtensionContainer` to emotion on simplify global css of
chrome
- remove `getIsNavDrawerLocked` and related css since not used
- Small unzyme
### TODO
- [x] fix solution nav in management
- [x] make sure solution nav works with header
- [x] fix dashboard full screen mode
- [x] check discover eui grid full screen
- [x] check chromeless mode
- [x] Follow up on EUI related hacks
https://github.com/elastic/eui/issues/8820
- [ ] Misaligned console in search solution
- [ ] Miaaligned secondary nav in security solutions
- [ ] double scroll in discover push flyout
## How to review
1. Most importantly, we need to ensure that nothing is broken in the old
layout during the refactor. - Functional tests + visual/manual testing
2. Then for the new layout:
kibana.yml:
```
feature_flags.overrides:
core.chrome.layoutType: 'grid'
core.chrome.layoutDebug: true
```
- Check that it mostly works (some specific edge cases and bugs are
fine)
- Code-review: focus on the layout implementation split approach
## Summary
This PR contains the schema changes needed to support using `dtstart` in
task manager rrule schedules. This is meant for intermediate release and
then the changes will be used in this PR:
https://github.com/elastic/kibana/pull/224948
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR removes `kbn/test-suites-serverless` as kbn reference for
osquery/cypress test-helper module in order to fix circular dependency I
faced in https://github.com/elastic/kibana/pull/225377
Since the main consumer of that `shared/lib/security` code is
`osquery/cypress` test module, I believe it is a resonable change in
order to unblock us relocating tests from `x-pack/test` dir.
Resolves https://github.com/elastic/kibana/issues/224987
## Summary
This test was failing the ES snapshot promotion pipeline. See in the
logs:
```
[00:04:15] │ proc [kbn-ui] [2025-06-26T17:44:06.841+00:00][WARN ][plugins.eventLog] invalid event logged: [kibana.user_api_key.managed_by]: definition for this key is missing; {"@timestamp":"2025-06-26T17:44:06.840Z","event":{"provider":"actions","action":"execute","kind":"action","start":"2025-06-26T17:44:06.762Z","end":"2025-06-26T17:44:06.840Z","duration":"78000000","outcome":"success"},"kibana":{"saved_objects":[{"rel":"primary","type":"action","id":"c4a64b3b-e5f5-4ffc-a58c-98584b6b5e59","type_id":"test.index-record","namespace":"space1"}],"space_ids":["space1"],"action":{"name":"My Connector","id":"c4a64b3b-e5f5-4ffc-a58c-98584b6b5e59","type_id":"test.index-record","execution":{"uuid":"ecbbf89f-729a-416c-a711-05b0a1e27de6","source":"http_request","usage":{"request_body_bytes":0}}},"user_api_key":{"managed_by":"elasticsearch","name":"test user managed key","id":"r1RWrZcB4HDiQQlB8SOM"},"server_uuid":"5b2de169-2785-441b-ae8c-186a1936b17d","version":"9.1.0"},"user":{"name":"elastic"},"message":"action executed: test.index-record:c4a64b3b-e5f5-4ffc-a58c-98584b6b5e59: My Connector","ecs":{"version":"1.8.0"}}) {"service":{"node":{"roles":["ui"]}}}
```
So it looks like the `api_key` information now returns a `managed_by`
field which we were copying over to the event log but was not accepted
by the event log schema. Updated the code to only copy over the `name`
and `id` field to address this. Can open a followup issue to see if we
want to copy over the `managed_by` field.
Closes https://github.com/elastic/kibana/issues/208328
This change adds Playwright test for Ensemble e2e testing CI.
[🔒 Corresponding PR in Ensemble
repo](https://github.com/elastic/ensemble/pull/580)
[🔒 Successful CI
run](1561308352)
# How to test
1. Run Kibana locally
2. Adjust
`x-pack/solutions/observability/plugins/observability_onboarding/e2e/playwright/.env`
file if needed (see README in the same folder for more details)
3. Run the test:
```bash
npx playwright test -c ./x-pack/solutions/observability/plugins/observability_onboarding/e2e/playwright/playwright.config.ts --reporter list --headed x-pack/solutions/observability/plugins/observability_onboarding/e2e/playwright/stateful/firehose.spec.ts
```
4. The test will open the Firehose onboarding page and stop after
copying the CLI command snippet. When running on the CI, Ensemble would
take over by running the snippet on the CI instance. The Playwright test
at this point is just waiting for data to start coming in, to imitate
that without actually creating infrastructure on a real AWS account, you
can ingest a dummy document manually, for example:
```
# Adjust the @timestamp before executing
POST logs-aws.apigateway_logs-default/_doc
{
"@timestamp": "2025-06-13T13:32:01.000Z",
"some": 111,
"aws.kinesis.name": "Elastic-Cloudwatch"
}
```
5. After doing that, you should see Kibana UI update with detected data
and the Playwright should continue and finish successfully.
## 26/06 Edits
Following discussion with the team, made the following changes:
* Modified curl and request and response examples with more appropriate
examples
## 20/06 Edits
Following discussion with the team, made the following changes:
* Removed `query` parameter from the API, and therefore removed it from
docs
* Made API return OpenAI format by default
* Removed `unredactions` property from public API schema and removed it
from docs
## Summary
Closes https://github.com/elastic/obs-ai-assistant-team/issues/193
Add docs for chat/complete public API.
## Steps to view documentation
1. checkout branch
2. Install bump-cli if you don't already have it:
https://docs.bump.sh/help/continuous-integration/cli/
3. Go to kibana/oas_docs folder
4. Run `bump preview output/kibana.yaml` or `bump preview
output/kibana.serverless.yaml`
5. Go to the url given by the command (it takes a while to load). On the
side bar, click on Observability AI Assistant menu item and there you
can see the docs :)
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [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>
## Summary
Resolves https://github.com/elastic/observability-dev/issues/4556.
This PR will amend the existing EBT `onPageReady` tracking for TTFCP
with some descriptions to help consumers of the telemetry data
understand the context around what we are tracking for this timing data.
Also exports the `Meta` type for re-use in a Synthetics-specific
implementation that needs to accept this parameter.
## Summary
PDF, PNG and ES|QL CSV reports all use a relative date range based on
`now` so when we generate recurring exports, we override `now` with a
`forceNow` parameter. Non ES|QL CSV reports use a `SearchSource` with a
fixed time range, even when a relative time range is set in Discover.
This PR updates the CSV search source report generation to override the
fixed time range for recurring scheduled exports.
## To Verify
- create a dataview (trying creating one using a field other than
`@timestamp` as the time field)
- populate the dataview with some data
- schedule a CSV export and verify that the eventual CSV report has data
in the correct time range
- may be faster to schedule via the API to get a report generated
faster.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Summarize your PR. If it involves visual changes include a screenshot or
gif.
These changes addresses the review comment from my previous PR
36ed6b38c1 (r2150081638)
Initially I broke up rendered component into multiple memoized
sub-sections. Reverting that back and adding tests coverage for the new
functionality - Case actions UI for the Attack Discovery rule type:
* Hidden `group by` component
* Hidden `time window` component
* Hidden `reopen case` component
* Disabled `template selector` component
* Tooltip explaining why we disabled the `template selector` component
## Summary
This PR reduces logging in the security solution plugin’s telemetry code
for production environments by reviewing existing logs and adjusting
their log levels.
- Deprecated a logging helper method and moved to standard
`logger.[debug|info|warn|error]` calls.
- Reviewed all the logging sentences to adjust the log level, remove the
non-useful ones, and improve messages.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Alejandro Fernández Haro <afharo@gmail.com>
## Summary
Fixes: https://github.com/elastic/kibana/issues/190761
I've added a `handleKeyDown` to capture the `ESC` key press behavior.
1. First `ESC` finds any .euiFlyout and close it with`closeFlyout()`
from `useExpandableFlyoutApi()`, then stops.
2. Next `ESC` (when no flyout) clicks `openToggleRef.current`, toggling
the timeline modal closed.
https://github.com/user-attachments/assets/0e42f9e9-2694-429d-8a5a-df86aa671809
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] [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
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Follow-up of https://github.com/elastic/kibana/pull/223367
Fix https://github.com/elastic/search-team/issues/10259
This PR introduce the concept of agent **mode**, and expose the "deep
research" agent as a mode instead of a tool.
## Examples
### Calling the Q/A (default) mode
```curl
POST kbn:/internal/onechat/chat
{
"nextMessage": "Find all info related to our work from home policy"
}
```
### Calling the researcher mode
```curl
POST kbn:/internal/onechat/chat
{
"mode": "researcher",
"nextMessage": "Find all info related to our work from home policy"
}
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
There's an issue where the `esArchiverLoad` migrates SO if any index
starting with `.kibana` is affected.
```
CypressError: `cy.task('esArchiverLoad')` failed with the following error:
> security_exception
Root causes:
security_exception: action [indices:admin/settings/update] is unauthorized for user [testing-internal] with effective roles [superuser] on restricted indices [.kibana_security_solution_1,.kibana_alerting_cases_1,.kibana_task_manager_1,.kibana_usage_counters_1,.kibana_1,.kibana_ingest_1,.kibana_analytics_1], this action is granted by the index privileges [manage,all]
```
This PR disables the test for MKI so it doesn't interfere with the
release, we'll work on a fix in a separate PR
Example MKI execution
https://buildkite.com/elastic/kibana-serverless-security-solution-quality-gate-investigations/builds/2889
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Implements a huggingface dataset loader for RAG evals - see
[x-pack/platform/packages/shared/kbn-ai-tools-cli/src/hf_dataset_loader/README.md](https://github.com/dgieselaar/kibana/blob/hf-dataset-loader/x-pack/platform/packages/shared/kbn-ai-tools-cli/src/hf_dataset_loader/README.md).
Additionally, a `@kbn/cache-cli` tool was added that allows tooling
authors to cache to disk (possibly remote storage later).
Used o3 for finding datasets on HuggingFace and doing an initial pass on
a line-by-line dataset processor ([see
conversation](https://chatgpt.com/share/6853e49a-e870-8000-9c65-f7a5a3a72af0))
Libraries added:
- `cache-manager`, `cache-manager-fs-hash`, `keyv`,
`@types/cache-manager-fs-hash`: caching libraries and plugins. could not
find any existing caching libraries in the repo.
- `@huggingface/hub`: api client for HF.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Simplifies the function to extract the categorize function field. The
unit tests we had pass for the new implementation so I am sure we don't
introduce new bugs
## Summary
This PR fixes [[ML] Change point detection: p-value tooltip is not
announced because lack of
focus](https://github.com/elastic/kibana/issues/216545) issue.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
While testing the ES|QL charts I realized that in case of an error in
the query, the hook goes into a loop and causes performance issues.
As the error is being reported we do not need to re-run the query to get
the results
For example if you create a control wrongly.
e.g.
1. Create a chart and add a control which will create an error:
<img width="508" alt="image"
src="https://github.com/user-attachments/assets/f2013d2c-e161-47bf-a3cb-d5033be9de59"
/>
2. Add to the control no-date fields. e.g. clientip
3. Check the editor is not going into a rendering loop
<img width="482" alt="image"
src="https://github.com/user-attachments/assets/cc541b68-b317-41ae-b4a6-87569466edd6"
/>
### Release notes
Fixes a performance issue in the Lens ES|QL charts in case of errors in
the query.
### 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
## Summary
The Obs-ux-infra_services team identified a useful addition to the PR
checklist we'd like to add to help remind contributors to apply
backports to the appropriate branches per the guideline document.
## Summary
Main ticket ([Internal
link](https://github.com/elastic/security-team/issues/10142))
With these changes we make sure that we return attack discovery fields
reformatted to a nice markdown text. We already format discovery details
when we create a new Case and add markdown comment to it.
### To Test
1. Create attack discovery schedule
2. Add an action to the schedule (email, slack etc.)
3. Select `For each alert > Per rule run` action frequency
4. Update subject, body or other fields of the connector to include
discovery details through the context variables
5. Wait until the action is triggered and check the received message
### Example of the email connector fields
**Subject**:
```
{{context.attack.title}}
```
**Message**:
```
{{{context.attack.detailsMarkdown}}}
{{{context.attack.detailsUrl}}}
```
<img width="665" alt="Screenshot 2025-06-25 at 18 05 30"
src="https://github.com/user-attachments/assets/71b2e02b-0437-4486-a584-108bec4d477f"
/>
which will result in an email similar to this one
<img width="1125" alt="Screenshot 2025-06-25 at 17 54 32"
src="https://github.com/user-attachments/assets/fefe60f0-e560-4288-9ec8-d1d444feb950"
/>
## NOTES
The feature is hidden behind the feature flag (in `kibana.dev.yml`):
```
feature_flags.overrides:
securitySolution.attackDiscoveryAlertsEnabled: true
securitySolution.assistantAttackDiscoverySchedulingEnabled: true
```
## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR is mostly about moving tests from x-pack/test/
Before:
```
x-pack/test/
| - reporting_api_integration/
| - reporting_functional/
```
After:
```
x-pack/platform/test/
| - reporting_api_integration/
| - reporting_functional/
```
Few page objects, required by functional tests, were relocated as well
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/218433
This change adds more descriptive error messages inside telemetry events
in the auto detect onboarding flow. The extended error message be shown
to the user as well.
* New telemetry event for the case when user is not running the script
as `root`
* If Agent fails to download, bot the original error from `curl` and the
download URL will be logged
* If Agent fails to extract, error message from `tar` command will be
logged
* If Agent fails to install, error message from `elastic-agent install`
command will be logged
* Error response from the integrations install endpoint will be logged
Example telemetry event:
Example terminal output:
## How to test
In order to simulate errors for all scenarios, you going to need to
modify the `auto_detect.sh` script to make it intentionally fail, like
adding extra character to the EA download URL. You can modify it
directly in the source if you're running Kibana locally, or you can
modify it after it was downloaded and before running it.
To test just one use-case without the script manipulations, you can
modify the EA download URL inside the code snippet provided by Kibana.
**Whatever way you choose, still go though the flow and make sure the
successful path works as expected.**
You can check the telemetry events emitted from the flow on [the staging
telemetry
cluster](https://telemetry-v2-staging.elastic.dev/s/observability-ux/app/discover#/?_g=(filters:!(),refreshInterval:(pause:!t,value:60000),time:(from:now-24h%2Fh,to:now))&_a=(columns:!(),dataSource:(dataViewId:b4befdd3-9a15-40c2-be4d-3ac1084d6182,type:dataView),filters:!(),interval:auto,query:(language:kuery,query:'event_type%20:%20%22observability_onboarding%22'),sort:!(!('@timestamp',desc)))),
but keep in mind that events delivered there with a delay of a couple of
hours 😢
---------
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
## Summary
Bug description (also the bug video below):
The bug occurred in the Customize Panel Editor, where the
PanelTitle—even when matching the defaultTitle from the central Saved
Object—was not always properly synchronized with that object. This led
to situations where the title was incorrectly stored as a custom
override, breaking the link to the saved object. There were two specific
cases where this happened:
Adding a panel from the library, then opening Customize Panel and
clicking Apply without making changes
After adding a panel from the library, the user opens the Customize
Panel Editor via the settings icon. Without making any changes to the
title, they exit the editor by clicking the Apply button instead of the
close icon. This causes the defaultTitle to be unnecessarily written
into the title field of the API object, which then treats it as a custom
title—breaking future synchronization with the saved object.
Resetting the title to default after a change
The user changes the panel title in the Customize Panel Editor and
clicks Apply. Later, they reopen the editor and click Reset to default.
This correctly restores the title from the central saved object, but it
is again written into the title field of the API object. Although the
value matches the current defaultTitle, it is now treated as custom. If
the central title changes later, the panel title will no longer
update—breaking synchronization again.
Fix:
The logic was updated to correctly detect when the panel title matches
the defaultTitle. In such cases, it clears the title field in the API
(by setting it to undefined) to indicate that the panel should inherit
the title from the saved object. This ensures proper synchronization:
any future updates to the saved object's title will be reflected
automatically in the panel.
Closes#188858
Below the bug video:
https://github.com/user-attachments/assets/f784679c-8eaa-47b4-942d-e3802faee076
## Summary
The bug: A field with the expected name `user.name.keyword` but with the
wrong mapping was returned.
How to fix it? `fieldCaps` was returning unmapped mixed with mapped
fields. This change forces the API to return the `fields` property with
a list of all indices matching `user.name.keyword`.
More information on [this
slack](https://elastic.slack.com/archives/C0D8ST60Y/p1750661564933609) 🧵
### How to test it?
* Create an index with the correct mapping
```
PUT /test-index1
{
"mappings": {
"properties": {
"user.name.keyword": {
"type": "text"
}
}
}
}
```
* Create an index with the wrong mapping
```
PUT /test-index2
{
"mappings": {
"properties": {
"user.name.keyword": {
"type": "text"
}
}
}
}
```
* Go to the manage data sources page
* Only `test-index1` should be returned
## Summary
Fix the FORK removal logic to insert the branch in the correct position
when only one FORK branch is valid.
### How to reproduce it
* Start empty kibana
* Generate data with resolve_generator `node
x-pack/solutions/security/plugins/security_solution/scripts/endpoint/resolver_generator.js`
* Go to "Privileged user monitoring" page and add some privileged users
* On the Dashboard page, scroll down to "Privileged user activity" and
click the "Authentications" tab
* It should display "No results found" instead of an error
### Before fix
### After fix
### 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
## Summary
Coming from the conversation from here:
https://github.com/elastic/kibana/pull/225339#discussion_r2167248942 and
a proposal from @akowalska622, we noticed that the useMemoCss doesn't
catch the keys of the css object. This fixes it.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Skips the Dataset Quality API integration test suite which
depends on reading Failure Store index privileges. Because when this
test suite runs in Kibana 8.19 against ES 9.0 in a forward compatibility
test runs, it raises the error:
```bash
[00:04:43] │ proc [kibana] [2025-06-25T05:40:33.223+00:00][WARN ][http.server.kbn-internal-api-restricted] Access to uri [/internal/dataset_quality/data_streams/logs-synth.fs-default/details] with method [get] is deprecated {"service":{"node":{"roles":["background_tasks","ui"]}}}
[00:04:43] │ proc [kibana] [2025-06-25T05:40:33.252+00:00][ERROR][plugins.datasetQuality] illegal_argument_exception
[00:04:43] │ proc [kibana] Root causes:
[00:04:43] │ proc [kibana] illegal_argument_exception: unknown index privilege [read_failure_store]. a privilege must be either one of the predefined fixed indices privileges [all,auto_configure,create,create_doc,create_index,cross_cluster_replication,cross_cluster_replication_internal,delete,delete_index,index,maintenance,manage,manage_data_stream_lifecycle,manage_follow_index,manage_ilm,manage_leader_index,monitor,none,read,read_cross_cluster,view_index_metadata,write] or a pattern over one of the available index actions {"service":{"node":{"roles":["background_tasks","ui"]}}}
[00:04:43] │ proc [kibana] [2025-06-25T05:40:33.291+00:00][WARN ][http.server.kbn-internal-api-restricted] Access to uri [/internal/dataset_quality/data_streams/logs-synth.no-default/details] with method [get] is deprecated {"service":{"node":{"roles":["background_tasks","ui"]}}}
[00:04:43] │ proc [kibana] [2025-06-25T05:40:33.305+00:00][ERROR][plugins.datasetQuality] illegal_argument_exception
```
This happens because the test accesses endpoint
`data_stream/{index}/details` which inquire user's index privileges
including `read_failure_store`, which is not available in **ES 9.0** as
`ES 9.0` does not support Failure Store.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
Closes https://github.com/elastic/observability-dev/issues/4511
Apply the following restrictions based on the serverless project tier:
- Grok patterns suggestions (only available on complete tier)
- Restrict suggestions API
- Restrict UI control to generate suggestions
- Date formats suggestions (only available on complete tier)
- Restrict suggestions API
- Restrict UI control to generate suggestions
- Restrict autocomplete
- Significant events (only available on complete tier)
- Restrict read API
- Last restrictions to be applied when [[Streams] Significant events
view](https://github.com/elastic/kibana/pull/220197#top) is merged.
**N.B.** All the above restrictions are only applied to Serverless
Observability projects on the Logs Essentials tier.
## 🧪 How To Test
* Modify `config/serverless.oblt.dev.yml` to include:
```yaml
pricing.tiers.products:
- name: observability
tier: logs_essentials
```
* Run Kibana locally
* In a stream detail view, go to management and try creating a grok
processor or a date one.
* It should NOT display the patterns generation button, nor it should
autocomplete the date processor formats and show its generate button.
Additionally, switch back to `tier: complete` in
`config/serverless.oblt.dev.yml` and make sure that ML/AI assisted flows
look as usual.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [diff](https://redirect.github.com/kpdecker/jsdiff) | dependencies |
patch | [`^8.0.1` ->
`^8.0.2`](https://renovatebot.com/diffs/npm/diff/8.0.1/8.0.2) |
---
### Release Notes
<details>
<summary>kpdecker/jsdiff (diff)</summary>
###
[`v8.0.2`](https://redirect.github.com/kpdecker/jsdiff/blob/HEAD/release-notes.md#802)
[Compare
Source](https://redirect.github.com/kpdecker/jsdiff/compare/v8.0.1...v8.0.2)
- [#​616](https://redirect.github.com/kpdecker/jsdiff/pull/616)
**Restored compatibility of `diffSentences` with old Safari versions.**
This was broken in 8.0.0 by the introduction of a regex with a
[lookbehind
assertion](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Lookbehind_assertion);
these weren't supported in Safari prior to version 16.4.
- [#​612](https://redirect.github.com/kpdecker/jsdiff/pull/612)
**Improved tree shakeability** by marking the built CJS and ESM packages
with `sideEffects: false`.
</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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkRhdGFEaXNjb3ZlcnkiLCJiYWNrcG9ydDphbGwtb3BlbiIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>
## Summary
This PR splits out a separate class from `DiscoverEBTManager` called
`ScopedDiscoverEBTManager`, similar to #216488, in order to better
support EBT tracking across tabs.
The profiles tracking in EBT events is a bit convoluted, and ideally
we'd be able to fully isolate the scoped managers, but our use of the
global EBT context observable makes that infeasible since it's a
singleton. If we simply updated the profiles in the EBT context when
switching tabs, it could result in the wrong profiles being tracked for
events fired asynchronously, e.g.:
- Starting from tab A, create a new tab B.
- Switch to tab B (which updates the EBT context with tab B's profiles)
and trigger a long running search.
- While the search is still running, switch back to tab A (updating the
EBT context back to tab A's profiles).
- Tab B's search completes while tab A is active, and the EBT context
for tab B's `discoverFetchAll` event incorrectly contains tab A's
profiles, since they were set when switching back to tab A.
This is solved by keeping track of the active scoped manager in the root
EBT manager, and temporarily updating the EBT context profiles when
firing events from inactive tabs, which seems to be reliable to prevent
leaking across tabs from my testing.
Since I'm using the same "scoped" service approach used for context
awareness across tabs, I've removed the dedicated
`ScopedProfilesManagerProvider` and replaced it with a general purpose
`ScopedServicesProvider` that can be used for all of these types of
services.
Unfortunately while Git recognized that certain files were just moved
and modified (e.g. `discover_ebt_manager.test.ts`), GitHub is displaying
them as entirely new files. To make it easier to review the actual file
changes, open the "Changes from X commits" dropdown and select from the
first commit to "Update unit tests", which will correctly display the
changes before the files were moved (they weren't modified after this
commit).
Resolves#223943.
### 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.
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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)
Closes https://github.com/elastic/kibana/issues/225344https://github.com/elastic/kibana/pull/223149 moved dynamic action
injection/extraction from dashboard to embeddables.
https://github.com/elastic/kibana/pull/223149 muffed the implementation
for the lens embeddable and failed to spread dynamicActionsState and
dynamicActionsReferences into serialized state for by-value panels.
This PR resolve the issue by spreading dynamicActionsState and
dynamicActionsReferences with lens state for by-value panels.
After applying fix, dashboard saved object should contain drilldown
reference and enhancements state should no longer contain hard coded
`dashboardId`.
```
{
"attributes": {
"panelsJSON": "[{\"type\":\"lens\",\"embeddableConfig\":{\"enhancements\":{\"dynamicActions\":{\"events\":[{\"eventId\":\"63700c7c-13e2-4aa2-8a58-7d2c19c42b34\",\"triggers\":[\"FILTER_TRIGGER\"],\"action\":{\"factoryId\":\"DASHBOARD_TO_DASHBOARD_DRILLDOWN\",\"name\":\"Go to Dashboard\",\"config\":{\"openInNewTab\":false,\"useCurrentDateRange\":true,\"useCurrentFilters\":true}}}]}},\"syncColors\":false,\"syncCursor\":true,\"syncTooltips\":false,\"filters\":[],\"query\":{\"query\":\"\",\"language\":\"kuery\"},\"attributes\":{\"title\":\"\",\"visualizationType\":\"lnsXY\",\"type\":\"lens\",\"references\":[{\"type\":\"index-pattern\",\"id\":\"90943e30-9a47-11e8-b64d-95841ca0b247\",\"name\":\"indexpattern-datasource-layer-5374d213-dba0-47d7-b4f2-9226d08a35cc\"}],\"state\":{\"visualization\":{\"legend\":{\"isVisible\":true,\"position\":\"right\"},\"valueLabels\":\"hide\",\"fittingFunction\":\"Linear\",\"axisTitlesVisibilitySettings\":{\"x\":true,\"yLeft\":true,\"yRight\":true},\"tickLabelsVisibilitySettings\":{\"x\":true,\"yLeft\":true,\"yRight\":true},\"labelsOrientation\":{\"x\":0,\"yLeft\":0,\"yRight\":0},\"gridlinesVisibilitySettings\":{\"x\":true,\"yLeft\":true,\"yRight\":true},\"preferredSeriesType\":\"bar_stacked\",\"layers\":[{\"layerId\":\"5374d213-dba0-47d7-b4f2-9226d08a35cc\",\"accessors\":[\"d1180bfd-63e2-437e-a027-faa0face26ff\"],\"position\":\"top\",\"seriesType\":\"bar_stacked\",\"showGridlines\":false,\"layerType\":\"data\",\"colorMapping\":{\"assignments\":[],\"specialAssignments\":[{\"rules\":[{\"type\":\"other\"}],\"color\":{\"type\":\"loop\"},\"touched\":false}],\"paletteId\":\"default\",\"colorMode\":{\"type\":\"categorical\"}},\"xAccessor\":\"dc975f9c-772f-4fc1-bc1e-70339f2c5906\"}]},\"query\":{\"query\":\"\",\"language\":\"kuery\"},\"filters\":[],\"datasourceStates\":{\"formBased\":{\"layers\":{\"5374d213-dba0-47d7-b4f2-9226d08a35cc\":{\"columns\":{\"dc975f9c-772f-4fc1-bc1e-70339f2c5906\":{\"label\":\"Top 5 values of machine.os.keyword\",\"dataType\":\"string\",\"operationType\":\"terms\",\"scale\":\"ordinal\",\"sourceField\":\"machine.os.keyword\",\"isBucketed\":true,\"params\":{\"size\":5,\"orderBy\":{\"type\":\"column\",\"columnId\":\"d1180bfd-63e2-437e-a027-faa0face26ff\"},\"orderDirection\":\"desc\",\"otherBucket\":true,\"missingBucket\":false,\"parentFormat\":{\"id\":\"terms\"},\"include\":[],\"exclude\":[],\"includeIsRegex\":false,\"excludeIsRegex\":false}},\"d1180bfd-63e2-437e-a027-faa0face26ff\":{\"label\":\"Count of records\",\"dataType\":\"number\",\"operationType\":\"count\",\"isBucketed\":false,\"scale\":\"ratio\",\"sourceField\":\"___records___\",\"params\":{\"emptyAsNull\":true}}},\"columnOrder\":[\"dc975f9c-772f-4fc1-bc1e-70339f2c5906\",\"d1180bfd-63e2-437e-a027-faa0face26ff\"],\"incompleteColumns\":{},\"sampling\":1}}},\"indexpattern\":{\"layers\":{}},\"textBased\":{\"layers\":{}}},\"internalReferences\":[],\"adHocDataViews\":{}}}},\"panelIndex\":\"74c07c77-979f-4fd9-8b07-889f4a93f9e0\",\"gridData\":{\"x\":0,\"y\":0,\"w\":24,\"h\":15,\"i\":\"74c07c77-979f-4fd9-8b07-889f4a93f9e0\"}}]",
},
"references": [
{
"type": "index-pattern",
"id": "90943e30-9a47-11e8-b64d-95841ca0b247",
"name": "74c07c77-979f-4fd9-8b07-889f4a93f9e0:indexpattern-datasource-layer-5374d213-dba0-47d7-b4f2-9226d08a35cc"
},
{
"name": "74c07c77-979f-4fd9-8b07-889f4a93f9e0:drilldown:DASHBOARD_TO_DASHBOARD_DRILLDOWN:63700c7c-13e2-4aa2-8a58-7d2c19c42b34:dashboardId",
"type": "dashboard",
"id": "edf84fe0-e1a0-11e7-b6d5-4dc382ef7f5b"
}
],
}
```
## Summary
This adds basic Lens CRUD api routes using the Content Management
system.
| Operation | URI |
|--------|--------|
| Create | `POST api/lens/visualizations` |
| Get | `GET api/lens/visualizations/{id}` |
| Search | `GET api/lens/visualizations?query=test` |
| Update | `PUT api/lens/visualizations/{id}` |
| Delete | `DELETE api/lens/visualizations/{id}` |
### Changes to Lens Content Management
The custom `update` method uses `soClient.create` under the hood for
reasons (i.e. #160116). However, doing this acts as an update or create
method with the provided `id`. I changed this behavior so now any update
where the id is not found will return a `404` error.
Closes#221941Closes#221942 - OpenAPI docs auto generate from route schema
### Testing
You can testing this locally in kibana dev console like so...
```
GET kbn:/api/lens/visualizations/<id>?apiVersion=1
```
> The `apiVersion` query param is needed to test `internal` api routes.
## Checklist
- [x] 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)
- [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.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Marco Vettorello <marco.vettorello@elastic.co>
## Summary
Endpoint Exception ALL privilege got lost, because the original
migration (PR: https://github.com/elastic/kibana/pull/219566) did this:
- for `siem:ALL` or `siemV2:ALL`:
- it adds the new `global_artifact_management_all`, because `siemVX` all
meant that user can write Endpoint Exceptions
- and: it changed `siemVX:ALL` to `siemVX:MINIMAL_ALL`, in order to
enabled the sub-features toggle, so it is visible to the user that they
are granted a new sub-privilege
and the issue: Endpoint Exceptions are not included in
`siemVX:MINIMAL_ALL`, and thanks to this the user lost their access to
Endpoint Exceptions.
this PR solves this issue.
### visualization
with this change, the `siem/siemV2:ALL` -> `siemV3` migration graph now
looks like this:
```mermaid
flowchart LR
classDef serverless stroke:blue,stroke-dasharray: 5 5
subgraph siemV2[siem/siemV2]
all1[all]
end
subgraph siemV3
subgraph minall2[minimal_all]
g1[global_artifact_management_all]
eea["`endpoint_exceptions_all
(only serverless)`"]:::serverless
end
end
all1 -->|keep access to the included Endpoint Exceptions ALL| g1
all1 -->|enable sub-feature toggle| minall2
all1 -->|keep access to EE ALL, as it WAS included in ALL. only serverless| eea
linkStyle 2 stroke:#00f,color:blue
```
see the previous ones here:
https://github.com/elastic/kibana/pull/219566
### 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
## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR is mostly about moving tests from
x-pack/test/cases_api_integration and updating related imports
Before:
```
x-pack/test/
| - cases_api_integration/
```
After:
```
x-pack/platform/test/
| - cases_api_integration/
x-pack/solutions/security/test/
| - cases_api_integration/
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- Part of #213293
- Adds infrastructure for a new pipeline: `kibana / renovate helper`
- The pipeline and scripts are currently a no-op and will be finalized
and tested in a follow up PR against the provisioned pipeline.
## Plan
The goal is to automatically run a script when Renovate opens a PR to
dedupe and perform any other actions, then trigger the Kibana PR
pipeline. This can also be performed by commenting `buildkite run
renovate helper` in the instances where the PR has been rebased by
Renovate.
Additionally, this pipeline will trigger the Kibana PR pipeline
automatically for Renovate PRs when the commit author is not Renovate
bot. Currently a developer has to comment every time they want CI to run
on Renovate PRs. This will improve DX when merging upstream, debugging
the dep upgrade and auto-commits by `kibanamachine`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Adapted cypress tests to:
- Run cypress tests within the Threat Hunting Investigations team bundle
in the CI.
- Fixed failing onboarding test.
- Added test cases for migration rename functionality to the onboarding
test.
## Screenshots
Fixes#218255 and #213784
## Summary
This PR fixes flaky test in Console responsible for opening
documentation with keyboard shortcut by checking if the opened tab
contains `www.elastic.co/docs`.
## Summary
In [this PR](https://github.com/elastic/kibana/pull/222827) we added
support of Cases action for Attack Discovery Schedules.
Now we would like to increase a "max opened cases" limit which defaults
to `5` right now and can be set maximum to `10`. In case with attack
discoveries it is highly expected to have more generated alerts and thus
we would like to bump the max number of opened cases to `20`.
## NOTES
The attack discovery scheduling and alerts history features are hidden
behind these feature flags (in `kibana.dev.yml`):
```
feature_flags.overrides:
securitySolution.attackDiscoveryAlertsEnabled: true
securitySolution.assistantAttackDiscoverySchedulingEnabled: true
```
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base-fips | digest | `d55453a` ->
`7f2cebd` |
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJiYWNrcG9ydDpza2lwIiwiY2k6YnVpbGQtZG9ja2VyLWZpcHMiLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Jon <jon@elastic.co>
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base | digest | `fdfd7f3` ->
`a02075b` |
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJiYWNrcG9ydDpza2lwIiwicmVsZWFzZV9ub3RlOnNraXAiXX0=-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Jon <jon@elastic.co>
Adds a `fromExternalVariant` helper function that unpacks external
variants (which are commonly used in Elasticsearch APIs) into a fully `{
type, value }` object.
## Notes
I used o3 to write the tests, including unit tests and type tests.
## Summary
- Fix the create of Event Filters, Blocklists, Endpoint Exceptions and
Host Isolation Exceptions so that an error is returned when space
awareness feature is enabled and the user does not have the Global
Artifact Management privilege.
> [!NOTE]
> Trusted Applications were already correctly validating this during
create of an artifact
### Checklist
- [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
This change remove `playwright-chromium` package from Kibana
dependencies.
* The package isn't used anywhere in the codebase
* The package conflicts with `@playwright/test` by installing the same
`playwright` executable which then misses a bunch of features, including
the `test` command
## Summary
With the new Claude 3.7 Elastic Managed LLM we're seeing an unhandled
error in Kibana playground. We can reproduce it by:
1. Indexing few but very large documents in Elasticsearch (10 docs, each
7mb)
2. Setting the docs to send setting as 10
3. Setting context to always query the index (I think there is some
function calling, not sure what happens under the hood but this worked
as I wanted to consistently).
Thread:
https://elastic.slack.com/archives/C08DT72KR6J/p1750686748616369?thread_ts=1750685837.561949&cid=C08DT72KR6J
We're not 100% sure this fixes the issue but we do know the model should be added.
### Checklist
Check the PR satisfies following conditions.
- [ ] Cannot reproduce the issue after the model entry is used on QA
environment
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)
### Identify risks
No known risks
Fixes https://github.com/elastic/kibana/issues/224191
## Summary
Bugfix - Replace call to registry when deleting kibana assets for
packages of type "custom" and "bundled". Also replaced the call to
`fetchInfo.registry` on another code path to avoid errors in the same
situation -
- These calls are replaced with `getPackageInfo`, that has some internal
functionalities to decide when the packageInfo should be fetched from
the cache, ES or the registry.
- Added additional logging to the delete assets functions
### Testing
- Install a custom integration that has some assets (a dashboard for
instance)
- Uninstall it and check that the asset is correctly removed and there
are no errors:
<img width="1453" alt="Screenshot 2025-06-25 at 11 02 39"
src="https://github.com/user-attachments/assets/32fb07f3-2628-4e30-be92-16610043b3ae"
/>
### 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
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This adds and enables the case id incrementer service ([design
doc](https://docs.google.com/document/d/1DZKTPl7UryYjpjVMNhIYbE82OADVOg93-d02f0ZQtUI/edit?tab=t.0#heading=h.6qjc4qynaeuo)).
In order not to stress bulk creation of cases, we're processing
incremental ids asynchronously, meaning they will not immediately appear
in the UI.
The feature is currently disabled by default to allow for testing in
additional environments after merging but can be enabled by setting
`xpack.cases.incrementalIdService.enabled=true` in `kibana(.dev).yml`.
Once the flag is enabled, actually rendering the IDs in the UI is
disabled by default (for now) and has to be enabled in the advanced
settings (`cases:incrementalIdDisplay:enabled`).
Cases can be found by their incremental ID by searching for
`#{incremental_case_id}` in the cases table.
### Screenshots
**Incremental ID in the case detail page**
<img width="1506" alt="Screenshot 2025-06-05 at 15 46 42"
src="https://github.com/user-attachments/assets/f51ae0cd-a2e8-48f7-a6db-05f9f1285e95"
/>
**Incremental ID in the cases table**
<img width="1240" alt="Screenshot 2025-06-05 at 20 32 32"
src="https://github.com/user-attachments/assets/619b3f12-1986-4bc7-b9e8-f7556d0c546c"
/>
**Searching for case by its incremental ID**
<img width="1239" alt="Screenshot 2025-06-05 at 20 33 36"
src="https://github.com/user-attachments/assets/771df512-7436-4aa0-88f9-ac3e1e161455"
/>
### Testing notes
<details>
<summary>Validation script</summary>
Use this script to investigate if there are duplicates or gaps:
```js
import * as fs from 'fs';
// Query to get all cases from all namespaces sorted by incremental_id
// GET .kibana_alerting_cases/_search?_source_excludes=*
// {
// "query": {
// "exists": {
// "field": "cases.incremental_id"
// }
// },
// "fields": [
// "cases.incremental_id",
// "cases.title",
// "namespaces"
// ],
// "from": 0,
// "size": 10000,
// "sort": [
// {
// "cases.incremental_id": {
// "order": "asc"
// }
// }
// ]
// }
// Put those results into `test.json` in the same directory
// You might need to add `"search_after": [40007]` in case you want to look at more than 10k cases.
// In that case, replace `[40007]` with whatever value the last item has in `"sort": [2102]`
// Concatenate hits if needed (10k per file)
const cases = [
JSON.parse(fs.readFileSync('./test.json')),
// JSON.parse(fs.readFileSync('./test1.json')),
// JSON.parse(fs.readFileSync('./test2.json')),
// JSON.parse(fs.readFileSync('./test3.json')),
// JSON.parse(fs.readFileSync('./test4.json')),
].reduce((allHits, currResult) => {
return allHits.concat(currResult.hits.hits);
}, []);
console.log(`Total amount of cases: ${cases.length}`);
// Groups cases but
const casesByNamespace = cases.reduce((acc, theCase) => {
const id = theCase._id;
const space = theCase.fields.namespaces[0];
const incrementalId = theCase.fields['cases.incremental_id'][0];
const title = theCase.fields['cases.title'][0];
const toStore = { id, incrementalId, title };
if (!acc[space]) {
acc[space] = new Map();
}
// check for duplicates
const spaceMap = acc[space];
if (!spaceMap.has(incrementalId)) {
acc[space].set(incrementalId, toStore);
} else {
const storedCase = spaceMap.get(incrementalId);
console.error(`
${storedCase.title} and ${toStore.title} have the same incremental id (${incrementalId})
`);
}
return acc;
}, {});
// find gaps in spaces
Object.keys(casesByNamespace).forEach((space) => {
const spaceHits = casesByNamespace[space];
const gaps = [];
spaceHits.forEach(({ incrementalId }, _, map) => {
const idBefore = incrementalId - 1;
if (incrementalId > 1 && !map.has(idBefore)) {
gaps.push(idBefore);
}
});
console.log(`space:${space} has ${spaceHits.size} cases and ${gaps.length} skipped ids`);
gaps.forEach((gap) => console.log(`id #${gap} is not assigned`));
});
```
</details>
- Enable the logger in your `kibana.dev.yml` (optional but helpful)
```
logging.loggers:
- name: plugins.cases.incremental_id_task
level: debug
```
- Change some of the timings in
`x-pack/platform/plugins/shared/cases/server/tasks/incremental_id/incremental_id_task_manager.ts`
- Set `timeout: '1m'`
- Set `CASES_INCREMENTAL_ID_SYNC_INTERVAL_DEFAULT_MINUTES = 1`
- Remove ```runAt: new Date(
new Date().getTime() +
CASES_INCREMENTAL_ID_SYNC_INTERVAL_DEFAULT_MINUTES * 60 * 1000
),```
- you can also set the timings to something lower in the seconds e.g.
`10s`
- Generate a bunch of cases with the generator script
`x-pack/platform/plugins/shared/cases/scripts/generate_cases.js`:
- `node scripts/generate_cases.js -c 1000 -o securitySolution
- Enable `cases:incrementalIdDisplay:enabled` in advanced settings
- Wait a couple minutes until the incrementer task ran
- Test that the ids show up and that the search works
### Research notes
- We ran a large-scale test with ~350k cases in a cloud env and can
report the following findings:
- The 10min timeout for the incremental id task makes sense. The task
was usually finished after around 8-9min (processing 1000 cases at a
time) which gives it some buffer even.
- While processing the first 50k cases, the service skipped 8 ids and no
duplicates have been assigned. This means it skipped `0.016%` ids which
is great.
- It's unclear when these skips happened though and we investigated the
first 50k cases for duplicate ids, just in case, and found no
duplicates.
- At no point did any of the error logs trigger, meaning the task is
running smoothly.
### Checklist
- [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
---------
Co-authored-by: Michael Olorunnisola <michael.olorunnisola@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/223990
## Summary
This PR fixes the forward-compatibility test for index mode, which
failed because the index mode was added to Get Data Streams API in 8.19
and 9.1 (see https://github.com/elastic/elasticsearch/pull/122486), so
if Kibana 8.19 is run with Es 9.0, the index mode is always displayed as
"Standard" because Es doesn't return an index mode field.
In this PR, we separate all index mode-related tests into a separate
file, and only run it for Es versions 8.19 or 9.1+.
This was also fixed for functional tests in
https://github.com/elastic/kibana/pull/223129
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Adds a recommended query for the `CATEGORIZE` function in ES|QL.
Adds keyword highlighting for the patterns and the ability to open a new
Discover tab to filter for docs which match the selected pattern.
https://github.com/user-attachments/assets/9ed8c5b0-7e92-4cc8-88dd-cb7749b5ffd3
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
## Summary
Multi space monitors !!
Fixes https://github.com/elastic/kibana/issues/164294
User will be able to choose in which space monitors will be available !!
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/f01ac226-ed54-4e96-b6f4-27f0134a9be5"
/>
### Technical
This is being done by registering another saved object type and for
existing monitors it will continue to work as right now but for newly
created monitors user will have ability to specify spaces or choose
multiple spaces or all.
### Testing
1. Create few monitors before this PR in multiple spaces
2. Create multiple monitors in multiple spaces after this PR
3. Make sure filtering, editing and deleting, creating works as expected
on both set of monitors
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Summarize your PR. If it involves visual changes include a screenshot or
gif.
Make it easier to debug topological plugin order errors by including the
exact cycle/s causing the issue in the error message:
Previous error message:
```
Error: Topological ordering of plugins did not complete, these plugins have cyclic or missing dependencies:
["discover","esql","canvas","crossClusterReplication","discoverEnhanced","indexLifecycleManagement","logstash","monitoring","observabilityAiAssistantManagement","remoteClusters","reporting","rollup","contentConnectors","dataQuality","datasetQuality","fleet","indexManagement","ml","osquery","streamsApp","apm","exploratoryView","infra","inventory","observability","observabilityAIAssistantApp","observabilityLogsExplorer","observabilityOnboarding","streamsAppWrapper","slo","synthetics","uptime","ux","enterpriseSearch","searchAssistant","searchIndices","searchInferenceEndpoints","searchPlayground","cloudSecurityPosture","elasticAssistant","securitySolution","securitySolutionEss"]
```
New error message tells you exactly where the cycle is:
```
Error: Topological ordering of plugins did not complete due to circular dependencies:
Detected circular dependencies:
discover -> elasticAssistant -> ml -> discover
Plugins with cyclic or missing dependencies: ["discover","esql","canvas","crossClusterReplication","discoverEnhanced","indexLifecycleManagement","logstash","monitoring","observabilityAiAssistantManagement","remoteClusters","reporting","rollup","contentConnectors","dataQuality","datasetQuality","fleet","indexManagement","ml","osquery","streamsApp","apm","exploratoryView","infra","inventory","observability","observabilityAIAssistantApp","observabilityLogsExplorer","observabilityOnboarding","streamsAppWrapper","slo","synthetics","uptime","ux","enterpriseSearch","searchAssistant","searchIndices","searchInferenceEndpoints","searchPlayground","cloudSecurityPosture","elasticAssistant","securitySolution","securitySolutionEss"]
```
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [X] 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)
- [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] 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.
- [X] [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)
### 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Jean-Louis Leysens <jeanlouis.leysens@elastic.co>
## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR is mostly about moving osquery cypress dir with
security-solution imports
```
x-pack/test/osquery_cypress
```
After:
```
x-pack/solutions/security/test/osquery_cypress
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Silences SASS module usage warnings around the deprecated `@import`
statements.
While the sass/scss owner teams are migrating these usages, the dev
server is clogged up with deprecation warnings. It's probably best to
disable it, because it's annoying to everyone and not necessarily to the
owners.
## [Attack discovery] Optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries
This PR introduces a new UI to optionally update the `kibana.alert.workflow_status` of alerts associated with Attack discoveries, as illustrated by the animated gif below:
Users may (optionally) update all alerts for a single attack discovery, or just update the discovery itself:
When multiple attack discoveries are selected, users may also (optionally) update the status of all their related alerts via the bulk action menu:
### Alert document enhancements
Attack discoveries generated via the Attack discovery page, and scheduled Attack discoveries (generated via the alerting framework), are persisted as alert documents.
To support the new UI, this PR populates Attack discovery alert documents with two additional (existing, but unused by Attack discovery) alert document fields:
1) `kibana.alert.start` - timestamp when Attack discoveries are created
2) `kibana.alert.workflow_status_updated_at` - timestamp when the `kibana.alert.workflow_status` was last updated
This PR introduces three new alert document fields to capture metadata about when alerts are updated. Attack discovery is the first implementation to use these new fields, however any consumer of the alerting framework may utilize them in the future:
1) `kibana.alert.updated_at` - timestamp when the alert was last updated
2) `kibana.alert.updated_by.user.id` - user id of the user that last updated the alert
3) `kibana.alert.updated_by.user.name` - user name of the user that last updated the alert
The three new alert fields above are updated when Attack discovery users update:
- The `kibana.alert.workflow_status` status of Attack discoveries
- The visibility (sharing) status of Attack discoveries (`kibana.alert.attack_discovery.users`)
The three new fields above were added to the [alert_field_map](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-alerts-as-data-utils/src/field_maps/alert_field_map.ts) and [alert_schema](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-alerts-as-data-utils/src/schemas/generated/alert_schema.ts).
Using the `default` space as an example, the fields above may be observed in the `.adhoc.alerts-security.attack.discovery.alerts-default` data stream for Attack discoveries generated on the Attack discovery page, and scheduled discoveries for the same space are found in the `.alerts-security.attack.discovery.alerts-default` data stream.
### @timestamp updated when sharing status changes
To ensure newly-shared Attack discoveries are bumped to the top of search results, the `@timestamp` field is updated when the visibility (sharing) status of Attack discoveries (`kibana.alert.attack_discovery.users`) is updated.
(The original time an Attack discovery was generated is represented by the `kibana.alert.start` field, which is not mutated.)
### Visibility menu changes
This PR disables the visibility menu items for shared Attack discoveries, as illustrated by the screenshot below:
The disabled menu has a tooltip that reads:
```
The visibility of shared discoveries cannot be changed
```
Note: The internal Attack discovery bulk API still (intentionally) allows changes to the visibility of shared attack discoveries.
### `kibana.alert.workflow_status` added to default `Alerts` tab columns
The `kibana.alert.workflow_status` field was added to default `Alerts` tab columns, as illustrated by the screenshot below:
### Summary of field updates
The following table describes when fields are updated (via this PR):
| Field | Updated when | Description |
|-------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|
| `kibana.alert.start` | - Attack discoveries are created | timestamp when Attack discoveries are created |
| `kibana.alert.workflow_status_updated_at` | - Workflow status (`kibana.alert.workflow_status`) is updated | timestamp when `kibana.alert.workflow_status` was last updated |
| `kibana.alert.updated_at` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | timestamp when the alert was last updated |
| `kibana.alert.updated_by.user.id` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | user id of the user that last updated the alert |
| `kibana.alert.updated_by.user.name` | - Workflow status (`kibana.alert.workflow_status`) is updated<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | user name of the user that last updated the alert |
| `@timestamp` | - Attack discoveries are created<br>- Sharing status (`kibana.alert.attack_discovery.users`) is updated | ECS [`@timestamp`](https://www.elastic.co/docs/reference/ecs/ecs-base#field-timestamp) field |
### Feature flags
The _required_ feature flag below is necessary to desk test with Ad hoc attack discoveries. The _recommended_ feature flag below enables testing with scheduled Attack discoveries.
### required: `securitySolution.attackDiscoveryAlertsEnabled`
Enable the required `securitySolution.attackDiscoveryAlertsEnabled` feature flag in `config/kibana.dev.yml`:
```yaml
feature_flags.overrides:
securitySolution.attackDiscoveryAlertsEnabled: true
```
### recommended: `securitySolution.assistantAttackDiscoverySchedulingEnabled: true`
Also enable the recommended `assistantAttackDiscoverySchedulingEnabled` feature flag in `config/kibana.dev.yml`:
```yaml
feature_flags.overrides:
securitySolution.attackDiscoveryAlertsEnabled: true
securitySolution.assistantAttackDiscoverySchedulingEnabled: true
```
## Summary
This PR pulls the latest changes from the Elasticsearch's ES|QL
documentation updates the ESQL docs. It also adds new ES|QL docs for:
- KQL
- TO_DATE_NANOS
Test results:
```
Model gpt-4o scored 27.700000000000003 out of 30
-------------------------------------------
-------------------------------------------
Model gpt-4o scores per category
- category: ES|QL commands and functions usage - scored 12 out of 13
- category: ES|QL query generation - scored 12.200000000000003 out of 13
- category: SPL to ESQL - scored 3.5 out of 4
-------------------------------------------
Model gpt-4o scored 25.300000000000004 out of 30
-------------------------------------------
-------------------------------------------
Model gpt-4o scores per category
- category: ES|QL commands and functions usage - scored 10.3 out of 13
- category: ES|QL query generation - scored 11.500000000000002 out of 13
- category: SPL to ESQL - scored 3.5 out of 4
-------------------------------------------
-------------------------------------------
Model gpt-4o scored 26.300000000000004 out of 30
-------------------------------------------
-------------------------------------------
Model gpt-4o scores per category
- category: ES|QL commands and functions usage - scored 10.8 out of 13
- category: ES|QL query generation - scored 11.700000000000003 out of 13
- category: SPL to ESQL - scored 3.8 out of 4
Model gpt-4o scored 27.500000000000004 out of 30
-------------------------------------------
-------------------------------------------
Model gpt-4o scores per category
- category: ES|QL commands and functions usage - scored 12 out of 13
- category: ES|QL query generation - scored 11.700000000000003 out of 13
- category: SPL to ESQL - scored 3.8 out of 4
```
### 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)
- [ ] 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
- [ ] 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
# Overview
Adds the initial privileged users table within the Privileged user
monitoring page.
Currently, this table shows:
- The user's risk score
- The user's asset criticality
- The data source that determined the privileged user
- The number of alerts associated with that privileged user in the
specified time range, along with its distribution
<img width="1310" alt="Screenshot 2025-06-24 at 3 41 17 PM"
src="https://github.com/user-attachments/assets/4093892d-896c-4ba9-a585-ad955f5661b7"
/>
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
disables features under Application for serverless-essentials.
### 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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR moves the `chart_settings_popover` and `field_selections` to
`~security_solution/public/detections/components/alerts_kpis` since they
are used exclusively by the KPI charts. These were left out in the
original folder reorg effort in
https://github.com/elastic/kibana/pull/189234
### Checklist
- [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
The `isSampleDataSetInstalled` function had an inefficient code pattern.
It uses `testSubjects.find()`, which has a 10 second default timeout.
When the sample data card doesn't exist, this call waits for 10 seconds
before failing, which slows down the `retry.waitFor` loop (20 second
timeout) in `addSampleDataSet` and tended to cause the entire test to
time out.
Closes https://github.com/elastic/kibana/issues/220053
## Summary
The PR adds code for displaying the visualisations for key insights
panel of Privileged user monitoring dashboard.
It comprises of 6 tiles.
1. Active Privileged Users
2. Alerts Triggered
3. Anomalies Detected
4. Granted Rights
5. Account Switches
6. Authentications
All the tiles have been created using the Lens visualisation for ease of
use and also to streamline visualisations across the security solution.
Screenshots :
Privileged User Monitoring Dashboard
Lens visualisation for a tile :
### Adding Data for desk testing :
1. On the `main` branch of "The Data Yeeter"
(https://github.com/elastic/security-documents-generator/), run `yarn
start privileged_access_detection`. This primarily adds data for
anomalies.
2. Then on the same `main` branch, run `yarn start
privileged_user_monitoring`. This will add data for the privileged user
index
3. On the dev console execute the following :
```
POST kbn:/api/entity_analytics/monitoring/engine/init
POST kbn:/api/entity_analytics/monitoring/users
{
"user": {"name": "john.smith"}
}
POST kbn:/api/entity_analytics/monitoring/users
{
"user": {"name": "stacy_armstrong"}
}
POST kbn:/api/entity_analytics/monitoring/users
{
"user": {"name": "john_smith"}
}
POST kbn:/api/entity_analytics/monitoring/users
{
"user": {"name": "randy.carlisle"}
}
POST kbn:/api/entity_analytics/monitoring/users
{
"user": {"name": "root"}
}
```
### Testing Steps :
1. Enable privilegedUserMonitoring feature flag.
2. Navigate to entity_analytics/privileged_user_monitoring page
3. Click on "Go to Dashboards" on the top left corner.
4. You will be able to see the tiles with name and number.
5. Click on the three dots when cursor is hovered over the tile and
click on Inspect to check the query executed, click on More -> Open in
Lens to check if the tile opens up fine in the lens visualiastion link.
6. Check the data view in the lens visualisation. For anomalies, the
data view should be `.ml-anomalies-*`. For other it would either be
`.alerts-*` or `logs-*`.
### Not part of this PR :
1. The trendline on the tile did not work as i am yet to figure out a
way, if it exists, to show a trendline with ES|QL query as it works fine
with KQL queries but similar lens attribites do not function.
2. Load testing where the local environment does not have much data to
show.
### 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
- [ ] 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: jaredburgettelastic <jared.burgett@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/212091
## Summary
Updates alerting snapshot telemetry to capture data about number of
backfill executions and gap durations from the event log index.
## To Verify
1. Reduce the cadence of the usage collector task
```
--- a/x-pack/platform/plugins/shared/alerting/server/usage/task.ts
+++ b/x-pack/platform/plugins/shared/alerting/server/usage/task.ts
@@ -31,7 +31,7 @@ import { MAINTENANCE_WINDOW_SAVED_OBJECT_TYPE } from '../../common';
export const TELEMETRY_TASK_TYPE = 'alerting_telemetry';
export const TASK_ID = `Alerting-${TELEMETRY_TASK_TYPE}`;
-export const SCHEDULE: IntervalSchedule = { interval: '1d' };
+export const SCHEDULE: IntervalSchedule = { interval: '5m' };
```
2. Enable the gap detection feature flag
```
--- a/x-pack/solutions/security/plugins/security_solution/common/experimental_features.ts
+++ b/x-pack/solutions/security/plugins/security_solution/common/experimental_features.ts
@@ -191,7 +191,7 @@ export const allowedExperimentalValues = Object.freeze({
/**
* Enables the storing of gaps in the event log
*/
- storeGapsInEventLogEnabled: false,
+ storeGapsInEventLogEnabled: true,
```
3. Start Kibana and create a detection rule and let it run once.
4. Stop Kibana for a period of time (at least 3 times the rule
interval).
5. Restart Kibana and navigate to
`https://localhost:5601/app/security/rules/id/<ruleId>`. Under the
`Execution Results` tab, you should see a section for `Gaps` and `Manual
runs`. When the rule runs again, you should see an entry under `Gaps`
with an action to `Fill gaps`. Click the action to fill the gaps.
<img width="2250" alt="Screenshot 2025-05-29 at 5 41 24 PM"
src="https://github.com/user-attachments/assets/a08455d0-8c54-4170-831b-3dedf6932fe7"
/>
6. Verify that the next time the usage collection task runs, you should
see data for backfill executions and gaps. You can see this in the Dev
Console using
```
POST kbn:/internal/telemetry/clusters/_stats?apiVersion=2
{ "unencrypted": true, "refreshCache": true }
```
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Fixes https://github.com/elastic/security-team/issues/8934
Summarize your PR. If it involves visual changes include a screenshot or
gif.
This PR enables the Security AI assistant to be used globally - i.e. if
you are outside of the security solution (e.g. Discover), the Security
Assistant can still be opened.
Changes:
- A public module has been added to the elastic-assistant plugin
(previously it was a server-side-only plugin).
- The vast majority of the assistant (flyout and nav bar) has been moved
into the new elastic-assistantpublic plugin.
- Comment actions & message augmentations remain within the
security-solution.
- A new public plugin was created called elastic-assistant-shared state.
This plugin is used to share state between the elastic-assistant public
plugin and other plugins (e.g. security-solution).
- For example, the security solution registers comment actions in the
elastic-assistant-shared-state plugin. The elastic-assistant public
plugin then reads the comment actions from
elastic-assistant-shared-state and renders them in the assistant flyout.
### Considerations:
- Currently, the Security AI assistant is being displayed everywhere
except the observability solution (see implementation
[here](https://github.com/elastic/kibana/pull/223936/files#diff-5dd1ea91c2d5d242203cc58ee59ec283116e5e739ed82bae4e2cd78af322150c)).
This is only for testing while the PR is in review. We plan to add a
setting to the stack management that allows the user to configure where
they would like the assistant to be shown. This will be changed before
the PR is merged.
## How to test
Feel free to use the cloud and serverless deployments created by the CI
pipeline for testing. Credentials can be found on Buildkite.
### Verify that the Security AI assistant works as expected within the
security solution
Expected there to be no changes in how the security AI assistant works
within the Security Solution. Please do some exploratory testing to make
sure nothing has changed.
Start the branch locally and go to http://localhost:5601/app/security/
Things to test:
- Does the assistant open?
- Can I send an alert to the assistant from the alerts page?
- Does the assistant display code blocks correctly?
- Does the assistant display ESQL correctly (can I view the ESQL in the
timeline)?
- Do assistant messages have the correct comment actions? Do the comment
actions work?
- Are conversations displayed correctly?
- Do citations work?
- Does the assistant work in serverless? Does the assistant work as
expected in AI4SOC?
- Do quick prompts work?
- Can you select a system prompt for a new convo?
- Can you send alerts to the Security AI assistant?
- AI assistant in a space that has Security disabled.
- Does attack discovery work?
AI assistant open in Discover app:
<img width="1841" alt="image"
src="https://github.com/user-attachments/assets/0a13a100-d192-4fa4-b395-0951452e14c2"
/>
AI assistant in Security solution:
<img width="1841" alt="image"
src="https://github.com/user-attachments/assets/7ed38f37-79de-41a7-a80f-8b96147bfdf6"
/>
### Verify the Security AI assistant works in Discover (or anywhere
outside of the Security solution)?
Head over to http://localhost:5601/app/discover. Note that some
functionality is removed when using the AI assistant outside of
security:
- Only the "copy" comment action appears on messages.
- Code block augmentations (i.e. the button that opens ESQL inside of
the timeline) don't appear.
Things to test:
- Does the security AI assistant button appear in the nav bar?
- Can you open the security AI assistant?
- Are you able to send messages?
- Are conversations appearing as expected?
- Can you close the assistant?
- Do citations work?
- Can you switch to a different solution while the assistant is open?
Security AI assistant open in AI4SOC Discover:
<img width="1841" alt="image"
src="https://github.com/user-attachments/assets/36537b9b-e945-459e-ac13-43e9444e92b7"
/>
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [X] 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)
- [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] 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.
- [X] [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)
### 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
With these changes we add Case Action support to Attack Discovery
Schedule rule types.
Attack discovery alerts act differently from SIEM alerts and include the
reference to list of SIEM alerts that led to the attack - described
within the attack discovery alert document. Thus, we would like to
attach referenced SIEM alerts instead of the attack alert document
itself to the created Case. Also, as part of the Case creation we would
like to be able to add a comment generated by LLM that describes steps
and nuance of the discovery.
## NOTES
The attack discovery scheduling feature is hidden behind the feature
flag (in `kibana.dev.yml`):
```
feature_flags.overrides:
securitySolution.attackDiscoveryAlertsEnabled: true
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>
Fixed some issues found with the privileged access detection heatmap.
- Fixed an issue when multiple joined results per user come back from
privileged access detection anomalies "top users" query.
- Fixed an emotion CSS issue where I imported the wrong module
## Summary
- Implements traversal of `source` node children (string literals), like
`a` and `b` in `FROM a:b`. Before `a` and `b` would not be traversed.
- Implements traversal of `order` nodes, like `field DESC` in `FROM a |
SORT field DESC`. Before the `field DESC` would be skipped.
- Adds tests, which verify that all nodes in the query are traversed by
the `Walker`, see `walker_all_nodes.test.ts`.
### Checklist
- [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
## Summary
This PR introduces a new Search Home page.
Currently, the homepage experience differs across Classic nav, Solution
nav, and Serverless. Our goal is to unify these into a consistent,
foundational experience that we can iterate on to create a more
personalized and customizable homepage for Elasticsearch users.
The new page includes:
- An option to connect to Elasticsearch
- File upload and sample dataset ingestion
- Entry points to explore Elastic’s AI Search capabilities
- Quick access to Observability and Security solutions
- Links to Search Labs, Python notebooks, and Elasticsearch
documentation
https://github.com/user-attachments/assets/7b1b5330-59b4-43b7-aa5b-000fcd2654e2
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] 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.
- [x] [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)
### 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
Co-authored-by: Rodney Norris <rodney@tattdcodemonkey.com>
## Summary
This closes#224982
Asset Inventory relies on the `entity.id` field as a unique identifier
for visualizations, grouping, filtering, and flyout functionality.
Currently, documents missing this field are included in the results,
leading to noise, broken interactions, and misleading asset entries.
This PR implements filtering within the Asset Inventory fetchers and UI
components to ensure that only valid documents with `entity.id` are
processed and displayed.
### Screenshot
**Before**
Unexpected behaviour in the Inventory page due to empty `user.name`
<img width="2162" alt="Image"
src="https://github.com/user-attachments/assets/18131bfc-c05e-4165-ab86-fea03b0a1c49"
/>
**After:**
<img width="1985" alt="image"
src="https://github.com/user-attachments/assets/0a3ca7de-b237-4d97-b62c-6fbd665e8cc5"
/>
Closes https://github.com/elastic/kibana/issues/224084
This improves the knowledge base retrieval by rewriting the user prompt
before querying Elasticsearch. The LLM is asked to rewrite the prompt
taking into account screen description and conversation history. We then
use the LLM-generated prompt as the search query.
Other changes:
- Remove `screenContext` from being used verbatim as ES query. This was
causing noise and leading to bad results
- Take conversation history into account: with query rewriting, the LLM
has access to the entire conversation history. This context will be
embedded into the generated prompt along side screen context
---------
Co-authored-by: Viduni Wickramarachchi <viduni.ushanka@gmail.com>
## Summary
Updates `security-ai-prompts` README to include instructions on how to
update kibana/integrations
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Fixes https://github.com/elastic/kibana/issues/222575
## Summary
Ensure package policy names are unique when moving across spaces. The
check applies to any integration (not only Defend) but it's only applied
when moving a policy from a space to another, not when creating a new
policy)
### Testing
- Ensure to have space awareness enabled
- In `default` space, create an agent policy and add a package policy to
it with name `defend1`
- In a second space `space1`, create an agent policy and add a package
policy to it with same name `defend1`
- Try to update the settings of this agent policy changing the space to
'default' - you should get an error `an integration policy with name
"defend" already exists. Please rename it or choose a different name."
### Checklist
Check the PR satisfies following conditions.
- [ ] [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
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
# Overview
This pull request enables the Security Entity Analytics Privileged user
monitoring feature. This feature has many accompanying PRs, that have
until now been kept behind an experimental feature flag. The feature is
currently slated to ship as a Technical Preview.
Instead of removing the feature flag, we will be allowing for a
"disabled" version of the experimental flag, which allows this feature
to remain disabled in Serverless, until fully tested during the 9.1
release cycle. Disabling in Serverless is accomplished via setting the
configuration to disabled in the `config/serverless.security.yml` file.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR adds a management page to the current privmon dashboard to
facilitate adding data sources *after* the initial onboarding flow
---------
Co-authored-by: jaredburgettelastic <jared.burgett@elastic.co>
Co-authored-by: Pablo Machado <pablo.nevesmachado@elastic.co>
## Summary
- Implements the flyout to schedule reports
- Adds a Schedules table to the Stack Management > Reporting page to
view schedules
- Updates the Reports table to show information about scheduled reports
<details>
<summary>
## Verification steps
</summary>
### 🐞 Happy Path
- Add the following configuration to your Kibana config file
```
notifications.connectors.default.email: gmail
xpack.actions.preconfigured:
gmail:
name: 'email: my gmail'
actionTypeId: '.email'
````
- Log in as an admin user or user with Reporting privileges and a
license != `basic`
- If you don't have data in Kibana, navigate to Home > Try sample data
and activate a sample data set
- Create a Dashboard or Discover session
- Open the ⬇️ (Export) menu in the toolbar
- Click `Schedule export`
- Schedule reports with different combinations of file name, export
type, recurrence schedule and email notification settings
- Navigate to Stack Management > Reporting
- Check that the scheduled reports match the displayed items in the
Reports and Schedules tabs (⚠️ some jobs might not have started because
of the recurrence rule so you might not find the reports immediately)
### ⚡️ Edge Cases
Missing default notifications email connector
- Start Kibana without the default email connector from point n.1 of the
happy path
- When trying to schedule a report, the flyout should show a callout
informing the user about the missing email connector
Unmet prerequisites
- Start ES with any of the following flags: `-E
xpack.security.enabled=false` or `-E
xpack.security.authc.api_key.enabled=false`
- The `Schedule export` button should not appear in the Export menu
Unsupported license
- Log in as a user with a basic license or without capabilities to
generate reports
- The `Schedule export` button should not appear in the Export menu
Users without `Manage Scheduled Reports` privilege
- Create a role with sufficient privileges to access and export any
object type (Dashboards, Discover, ...), do not grant the `Manage
Scheduled Reports` privilege (under `Stack Management`)
- Create a user with this role, _without an email address_
- Open the Schedule export flyout
- Check that the `Send by email` field is disabled, showing a hint about
the user profile missing an email address
- Add an email address to the user (for the changes to take effect you
might have to renew the session, logging back in)
- Check that the `Send by email` toggle is now enabled
- Check that when toggling email notifications on, the `To` field is
disabled and precompiled with the user's email address
Flyout form validation
- `File name` should be required
- `To` should not allow to insert invalid email addresses
- `To` should not allow to insert unallowed email addresses (not in
allowlist)
- Recurrence subform should show presets based on the current datetime
### ❌ Failure Cases
</details>
<details>
<summary>
## Known issues
</summary>
- PDF print option is not displayed in readOnly mode
- Console error due to `compressed` attribute wrongly forwarded by
form-hook-lib to DOM element (this is likely a form lib issue):
<img width="916" alt="image"
src="https://github.com/user-attachments/assets/09d20ba9-8781-46d6-bcfa-862d8a4cbf90"
/>
- Email validation errors accumulate instead of replacing the previous
one (again looks like a fom lib issue):
https://github.com/user-attachments/assets/f2dc7a46-a3a9-465d-b8a1-3187b200f9b9
</details>
<details>
<summary>
## Screenshots
</summary>
Health API error:
<img height="500" alt="Screenshot 2025-05-31 at 10 48 40"
src="https://github.com/user-attachments/assets/dd069597-971c-489f-9c07-eb5edfd7bede"
/>
Health API loading state:
<img height="500" alt="Screenshot 2025-05-31 at 10 49 04"
src="https://github.com/user-attachments/assets/27d95bf3-bf7d-42c7-9a40-2826f38aa837"
/>
Health API success with some missing prerequisites:
<img width="449" alt="Screenshot 2025-06-17 at 16 59 57"
src="https://github.com/user-attachments/assets/c44afa97-70ff-4618-8b73-41b816514459"
/>
Form validation:
<img height="500" alt="image"
src="https://github.com/user-attachments/assets/a8d4cae1-2819-4f71-a911-9300a6cf81f8"
/>
Success toast:
<img width="480" alt="image"
src="https://github.com/user-attachments/assets/a87c3af5-dbb0-40e8-915a-fc9d7e1d97f2"
/>
Failure toast:
<img width="518" alt="image"
src="https://github.com/user-attachments/assets/908f9dea-b5cb-4da9-b4a5-76e313837f18"
/>
Print format toggle:
<img width="502" alt="image"
src="https://github.com/user-attachments/assets/602f3ab9-07ef-4689-a305-dc1b2b5495cd"
/>
Missing notifications email connector callout:
<img width="499" alt="image"
src="https://github.com/user-attachments/assets/fe4997a5-75e6-4450-85e5-7d853049e085"
/>
User without `Manage Scheduled Reports` privilege and without email
address in profile
<img width="492" alt="Screenshot 2025-06-23 at 14 51 07"
src="https://github.com/user-attachments/assets/e0867b7b-3358-4cf0-8adf-c141a1ded76f"
/>
User without `Manage Scheduled Reports` privilege with email address in
profile
<img width="498" alt="image"
src="https://github.com/user-attachments/assets/c45a0c31-cac7-4acb-b068-b3cfc02aac68"
/>
</details>
## Release Notes
Added the ability to schedule reports with a recurring schedule and view
previously scheduled reports
## References
Closes#216321Closes#216322
### Checklist
- [x] 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
- [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>
Co-authored-by: Eyo O. Eyo <7893459+eokoneyo@users.noreply.github.com>
Co-authored-by: Janki Salvi <117571355+js-jankisalvi@users.noreply.github.com>
Co-authored-by: Janki Salvi <jankigaurav.salvi@elastic.co>
## Summary
Updates the logic around the test cases generator to allow for adding
cases to additional environments
example to test:
```
yarn generate:cases -c 1000 -o securitySolution
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
# Summary
This PR introduces support for populating the Privileged Users index
from custom data sources (Elasticsearch indices) by querying Privileged
User Monitoring Saved Objects from a Kibana task.
[Related Issue](https://github.com/elastic/security-team/issues/12289)
[Figma
Breakdown](https://www.figma.com/board/yBr1pBDGu4JqNxb5ZrULtk/MonEntitySourceSyncTask?node-id=0-1&p=f&t=q52ABMD5MLX0uGj1-0)
Working from the _"Synchronize Privileged User index based on configured
Entity Sources"_ section, to the right.
### ✅ Implemented
• Registered the temporary type and mappings
• Created a Descriptor Client that saves it via soClient.create()
• Called Descriptor Client create method from PrivMon initialisation.
* Testing above default Saved Object creation within PrivMon
Initialisation
* Update the entity_analytics:monitoring:privileges:engine task to:
* Read all Saved objects of index type
* query user.name values from given indexPattern
* Apply any filters or matchers defined in the Saved Object
* Insert matched user.names into
.entity_analytics.monitoring.users-<space> with source type index.
* Cleanup logic:
* Target pattern does not exist, log warning and continue task
* Failures will be caught and do not interrupt task loop
* Remove previously stored user.names with source type index, that are
no longer present.
* Component Testing
### 🚧 Wish List
* Pull out sync functions from privilege monitoring data client into
their own sync service class / similar
* * Currently in the data client, they should not be on this layer.
* Update GET and DELETE methods with dynamic id's for monitoring data
client as per [this
ticket](https://github.com/elastic/security-team/issues/12851)
# How to Test
- Pull branch into local machine
- Security experimental flag enable: 'privilegeMonitoringEnabled'
- Start up ElasticSearch and Kibana
**1. Optional - create the default index, this should just skip if you
don't make it.**
```
POST entity_analytics.privileged_monitoring/_doc
{
"user": {
"name": "default name"
}
}
```
**2. Create test index/ indicies**
```
POST tatooine-/_bulk
{ "index": {} }
{ "user": { "name": "Luke Skywalker" } }
{ "index": {} }
{ "user": { "name": "Leia Organa" } }
{ "index": {} }
{ "user": { "name": "Han Solo" } }
{ "index": {} }
{ "user": { "name": "Chewbacca" } }
{ "index": {} }
{ "user": { "name": "Obi-Wan Kenobi" } }
{ "index": {} }
{ "user": { "name": "Yoda" } }
{ "index": {} }
{ "user": { "name": "R2-D2" } }
{ "index": {} }
{ "user": { "name": "C-3PO" } }
{ "index": {} }
{ "user": { "name": "Darth Vader" } }
```
**3. Register Monitoring Entity Source Saved Objects**
```
POST kbn:/api/entity_analytics/monitoring/entity_source
{
"type": "index",
"name": "StarWars",
"managed": true,
"indexPattern": "tatooine-",
"enabled": true,
"matchers": [
{
"fields": ["user.role"],
"values": ["admin"]
}
],
"filter": {}
}
```
**- OPTIONAL: You can check what is in the monitoring entity_source
SO:**
```
GET kbn:/api/entity_analytics/monitoring/entity_source/list
```
**4. Initialise monitoring engine:**
```
POST kbn:/api/entity_analytics/monitoring/engine/init {}
```
**5. Verify Users in Monitoring Index**
- Check the list of synced user, should include:
- - The created users
- - The default user (if you created it)
```
GET kbn:/api/entity_analytics/monitoring/users/list
```
**e.g. output:**
```
[
{
"id": "FkMJoZcB7muj1aiwb_eQ",
"user": {
"name": "C-3PO",
"is_privileged": true
},
"labels": {
"sources": [
"index"
],
"source_indices": [
"tatooine-"
],
}
},
{
"id": "F0MJoZcB7muj1aiwb_eQ",
"user": {
"name": "Chewbacca",
"is_privileged": true
},
"labels": {
"sources": [
"index"
],
"source_indices": [
"tatooine-"
],
}
},
// ... more here
```
## Testing: Removing Stale Users
The engine should soft delete users from the internal index if they no
longer appear in the synced sources - e.g. label as
monitoring.privileged_users: "not_monitored"
**Example:**
- Delete users in index:
```
POST tatooine-/_delete_by_query
{
"query": {
"terms": {
"user.name.keyword": ["Chewbacca", "Han Solo"]
}
}
}
```
- re-run engine init
```
POST kbn:/api/entity_analytics/monitoring/engine/init
{}
```
-Fetch the updated user list:
```
GET kbn:/api/entity_analytics/monitoring/users/list
```
You should now only see both Chewbacca and Han Solo are no longer
privileged:
```
// ..
{
"id": "GUMJoZcB7muj1aiwb_eQ",
"user": {
"name": "Han Solo"
"is_privileged": false
},
"labels": {
"sources": [],
"source_indices": [],
}
}
]
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR adds guidelines for designing Kibana HTTP APIs that are
terraform-provider developer friendly.
fix https://github.com/elastic/kibana/issues/224643
## Summary
Kibana doesn't have specific guidelines for designing HTTP APIs. With
increasing constraints, it's time to document what was previously tribal
knowledge.
Elasticsearch is far further along this road, and other teams have
compiled their own.
This document serves as guidelines to designing _public_ HTTP APIs that
are suitable for managing with Terraform.
## How to test this (recommended for easier reading)
- pull this PR
- setup
[`docs.elastic.dev`](https://docs.elastic.dev/docs/local-dev-docs-setup)
locally
- run `yarn dev` from `docs.elastic.dev`
- review the docs live!
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
---------
Co-authored-by: florent-leborgne <florent.leborgne@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/224294
### External team reviewers
@elastic/kibana-presentation team is working on "Dashboards as code"
project where we provide a human readable CRUD API for dashboards. Part
of this work is aligning dashboard client code with the shape of
dashboard server api. As such, we are changing the shape of `panels`
from a Map to an Array - to directly consume what is being returned from
the dashboard server api.
### PR Overview
The goal of this PR is to update dashboard client-side state `panels`
type to match the type from dashboard server api. The dashboard server
api returns panels as an Array, while the dashboard client-side logic is
expecting panels to be a Map keyed by panel id.
This type change required the following changes:
* Refactored dashboard client code to receive panels as an array and
return panels as an array. Biggest work is in layout_manager
`deserializeState` and `serializeState` methods.
* Remove `convertPanelsArrayToPanelSectionMaps` from
`loadDashboardState`. `convertPanelsArrayToPanelSectionMaps` performed 2
tasks
1) Convert panels array to map. This is no longer needed as now
dashboard client code accepts panels in its native shape from the
dashboard server api.
2) Move `id` and `title` fields into embeddable state. This is no longer
needed as now dashboard server api does this transform before sending
the dashboard to the client.
* Remove `convertPanelSectionMapsToPanelsArray` from
`getSerializedState`. `convertPanelSectionMapsToPanelsArray` performed 2
tasks.
1) Convert panels map into panels array. This is no longer needed as now
panels is provided to `getSerializedState` in the shape required for the
dashboard server api.
2) Lift `id` and `title` fields from into top level panel state. This is
no longer needed as all embeddable state should remain under
`panelConfig`.
* Remove a bunch of code in `dashboard/common` as now the client and
server are do not need to depend on shared logic as the client is much
simpler and no longer needs to transform the server response. Much of
this shared logic was copied into server saved object migrations in
https://github.com/elastic/kibana/pull/223980 but can now be removed
from common since its no longer used in the client.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Issue: https://github.com/elastic/kibana/issues/216631
This PR adds a new priority called `normalLongRunning` that is slightly
lower than the normal task priority. This priority is applied to the
`attack-discovery` rule type. Unit and E2E tests are also added to
verify that the new priority is working as intended.
### Checklist
- [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
Closes https://github.com/elastic/kibana/issues/217508,
https://github.com/elastic/kibana/issues/217510,
https://github.com/elastic/kibana/issues/217521
This pull request introduces significant updates to the ML anomaly
detection utilities and components. The changes focus on improving
theme-aware severity color handling, refining severity thresholds, and
deprecating legacy severity-related utilities.
## New Anomalies filtering UX and Influencers badges:
<img width="1361" alt="image"
src="https://github.com/user-attachments/assets/0f7e0aa3-310f-4f59-95aa-f74c576d0f91"
/>
## New Single Metric Viewer base colors
<img width="929" alt="image"
src="https://github.com/user-attachments/assets/9b3e33cf-23b4-4163-b274-f911ef9321e4"
/>
### Theme-aware severity color handling:
* Added `useSeverityColor` hook and `getThemeResolvedSeverityColor`
utility to provide theme-aware severity colors, replacing legacy fixed
colors. These utilities ensure better integration with the EUI theme.
`x-pack/platform/packages/shared/ml/anomaly_utils/use_severity_color.ts`
* Deprecated legacy severity color constants (`ML_SEVERITY_COLORS`) and
methods (`getSeverityColor`) in favor of theme-aware alternatives.
`x-pack/platform/packages/shared/ml/anomaly_utils/severity_colors.ts`
`x-pack/platform/packages/shared/ml/anomaly_utils/get_severity_color.ts`
### Severity thresholds and ramp:
* Removed the legacy `ML_SEVERITY_COLOR_RAMP` constant and introduced
`getMlSeverityColorRampValue` utility to dynamically generate
theme-aware severity ramps.
`x-pack/platform/packages/shared/ml/anomaly_utils/severity_ramp.ts`
### Type and interface updates:
* Introduced a new `SeverityThreshold` type to represent severity
ranges, replacing the previous numeric severity representation in
`ExplorerAppState`.
`x-pack/platform/plugins/shared/ml/common/types/anomalies.ts`
`x-pack/platform/plugins/shared/ml/common/types/locator.ts`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves
https://github.com/elastic/streams-program/issues/206?issue=elastic%7Cstreams-program%7C317
This PR introduces a new Advanced Settings for enabling streams
significant events. It is disabled by default.
This PR also registers the rule regardless of the settings.
Using an Advanced Settings makes it easier for internal customers to
toggle the feature on serverless.
<img width="1495" alt="Screenshot 2025-06-17 at 11 15 11 AM"
src="https://github.com/user-attachments/assets/27023c52-20a9-476f-9dfd-d3b8b3f03e94"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dario Gieselaar <dario.gieselaar@elastic.co>
This pull request updates the `.github/CODEOWNERS` file to revise
ownership assignments for several configuration files related to
serverless setups. The changes primarily involve adding or modifying
team ownership for specific files.
Ownership updates:
* Added ownership for `@elastic/kibana-security` to
`config/serverless.*.yml`, ensuring broader coverage for serverless
configuration files.
* Updated ownership for `config/serverless.oblt.complete.yml` and
`config/serverless.oblt.logs_essentials.yml` to include
`@elastic/kibana-security` alongside existing teams.
## Summary
Added a check that will prevent dispatches when either id or fallbacks
patterns are not provided.
The only thing I am not sure about is some kind of warning, we need to
log it somehow probably.
Closes https://github.com/elastic/kibana/issues/223156
## Testing
Flip the flag: `xpack.securitySolution.enableExperimental:
['newDataViewPickerEnabled']`
then try to investigate alert in timeline.
### Checklist
- [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
## Summary
It fixes#217792 by having a consistent experience with the rule flyout.
### Resizable flyout:
- ✅ From the Apps on Create and Edit
- ✅ From the Rules page on Edit
### Full-page
- ✅ From the Rules page on Create
- ✅ From the Rule details page on Edit
# Backport
This will backport the following commits from `8.19` to `main`:
- [[Upgrade Assistant] Create actions column in Es deprecations
(#222346)](https://github.com/elastic/kibana/pull/222346)
- [[Upgrade Assistant] Change resolution column icons to filled
(#222764)](https://github.com/elastic/kibana/pull/222621)
- [[Upgrade Assistant] Add suggestions to resolution column
(#223113)](https://github.com/elastic/kibana/pull/222621)
- [[Upgrade Assistant] Update index unfreeze and read-only progress
strings (#223509)](https://github.com/elastic/kibana/pull/222621)
- [[Upgrade Assistant] Show single action button in ES
deprecations/Actions column
(#223576)](https://github.com/elastic/kibana/pull/223576)
- [[Upgrade Assistant] Create modal for setting to read-only and
unfreeze (#224525)](https://github.com/elastic/kibana/pull/224525)
- [[Upgrade assistant] Unify read-only copies
(#224532)](https://github.com/elastic/kibana/pull/224532)
- [[Upgrade Assistant] Small cosmetic fixes
(#224535)](https://github.com/elastic/kibana/pull/224535)
- [[Upgrade Assistant] Add manually resolve for follower readonly
(#224600)](https://github.com/elastic/kibana/pull/224600)
<!--- Backport version: 9.6.6 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)
<!--BACKPORT [{"author":{"name":"Sonia Sanz
Vivas","email":"sonia.sanzvivas@elastic.co"},"sourceCommit":{"committedDate":"2025-06-09T11:00:42Z","message":"[Upgrade
Assistant] Create actions column in Es deprecations (#222346)\n\nFixes
https://github.com/elastic/kibana/issues/222035\nPart of
https://github.com/elastic/kibana/issues/221977\n\n## Summary\nThis PR
is the first one for the enhancement in the ES deprecations\ntable in
Upgrade Assistant. This PR creates a new column called\n`Actions` and
moves the existing available actions in the `resolution`\ncolumn to it.
The icon and the flyout is the same. The status of the\nresolution still
gets updated in the `resolution` column.\n\nThe goal of this PR was that
no functionality or tests gets affected by\nthis changes (except the
unit test verifying that the entire row is\nclickable).\n\nNote: The
width of the columns is a little weird right now. It will\nadjust when
all columns have the expected content.\n\n### How to test\n\n* Follow
the instructions in\nhttps://github.com/elastic/kibana-team/issues/1521.
Use the data folder\nnamed `data_qaf_frozen` because it has the largest
variety of\ndeprecations.\nYou can also add some other deprecations by
replacing\n`x-pack/platform/plugins/private/upgrade_assistant/server/lib/es_deprecations_status/migrations.ts\n`
L272 with:\n````\nlet esDeprecations = (await
esClient.migration.deprecations()) as EsDeprecations;\nesDeprecations =
{\n ...esDeprecations,\n cluster_settings: [\n {\n level: 'warning',\n
message:\n 'Template patterns are no longer using `template` field, but
`index_patterns` instead',\n url:
'https://www.elastic.co/guide/en/elasticsearch/reference/6.0/breaking_60_indices_changes.html#_index_templates_use_literal_index_patterns_literal_instead_of_literal_template_literal',\n
details:\n 'templates using `template` field:
security_audit_log,watches,.monitoring-alerts,triggered_watches,.ml-anomalies-,.ml-notifications,.ml-meta,.monitoring-kibana,.monitoring-es,.monitoring-logstash,.watch-history-6,.ml-state,security-index-template',\n
resolve_during_rolling_upgrade: false,\n },\n {\n level: 'warning',\n
message: 'one or more templates use deprecated mapping settings',\n url:
'https://www.elastic.co/guide/en/elasticsearch/reference/6.0/breaking_60_indices_changes.html',\n
details:\n '{.monitoring-logstash=[Coercion of boolean fields],
.monitoring-es=[Coercion of boolean fields], .ml-anomalies-=[Coercion of
boolean fields], .watch-history-6=[Coercion of boolean fields],
.monitoring-kibana=[Coercion of boolean fields],
security-index-template=[Coercion of boolean fields]}',\n
resolve_during_rolling_upgrade: false,\n },\n ],\n ilm_policies: {\n
myfreezepolicy: [\n {\n level: 'warning',\n message:\n \"ILM policy
[myfreezepolicy] contains the action 'freeze' that is deprecated and
will be removed in a future version.\",\n url:
'https://www.elastic.co/guide/en/elasticsearch/reference/master/frozen-indices.html',\n
details:\n 'This action is already a noop so it can be safely removed,
because frozen indices no longer offer any advantages. Consider cold or
frozen tiers in place of frozen indices.',\n
resolve_during_rolling_upgrade: false,\n },\n ],\n },\n templates: {\n
mytemplate: [\n {\n level: 'critical',\n message:\n 'Configuring source
mode in mappings is deprecated and will be removed in future versions.
Use [index.mapping.source.mode] index setting instead.',\n url:
'https://github.com/elastic/elasticsearch/pull/117172',\n
resolve_during_rolling_upgrade: false,\n },\n ],\n },\n};\n````\n* Go to
\"Stack Management > Upgrade Assistant\". Navigate to\n\"Elasticsearch
deprecation issues\"\n * Verify that the new actions column is there\n*
Verify that the column now contains the actions icon and opens
the\nflyout.\n * Verify that the resolution column still updates the
status\n* Verify that the deprecations that requires Manual action, now
display\na Gear icon in the actions column.\n* Verify that the entire
row is not longer clickable and the flyout only\ngets opened when
clicking in the icon.\n\n###
Demo\n<details>\n<summary>Video</summary>\n\n\n\n\nhttps://github.com/user-attachments/assets/22f16b7d-de08-42dd-8ffe-91acec4dab92\n\n\n\n</details>\n\n---------\n\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"ba012f668c3385594dee9279467c8f51b28c789f","branchLabelMapping":{"^v8.16.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Kibana
Management","release_note:skip","Feature:Upgrade
Assistant","backport:version","v8.19.0","UA_needs_forwardport_9.1"],"title":"[Upgrade
Assistant] Create actions column in Es
deprecations","number":222346,"url":"https://github.com/elastic/kibana/pull/222346","mergeCommit":{"message":"[Upgrade
Assistant] Create actions column in Es deprecations (#222346)\n\nFixes
https://github.com/elastic/kibana/issues/222035\nPart of
https://github.com/elastic/kibana/issues/221977\n\n## Summary\nThis PR
is the first one for the enhancement in the ES deprecations\ntable in
Upgrade Assistant. This PR creates a new column called\n`Actions` and
moves the existing available actions in the `resolution`\ncolumn to it.
The icon and the flyout is the same. The status of the\nresolution still
gets updated in the `resolution` column.\n\nThe goal of this PR was that
no functionality or tests gets affected by\nthis changes (except the
unit test verifying that the entire row is\nclickable).\n\nNote: The
width of the columns is a little weird right now. It will\nadjust when
all columns have the expected content.\n\n### How to test\n\n* Follow
the instructions in\nhttps://github.com/elastic/kibana-team/issues/1521.
Use the data folder\nnamed `data_qaf_frozen` because it has the largest
variety of\ndeprecations.\nYou can also add some other deprecations by
replacing\n`x-pack/platform/plugins/private/upgrade_assistant/server/lib/es_deprecations_status/migrations.ts\n`
L272 with:\n````\nlet esDeprecations = (await
esClient.migration.deprecations()) as EsDeprecations;\nesDeprecations =
{\n ...esDeprecations,\n cluster_settings: [\n {\n level: 'warning',\n
message:\n 'Template patterns are no longer using `template` field, but
`index_patterns` instead',\n url:
'https://www.elastic.co/guide/en/elasticsearch/reference/6.0/breaking_60_indices_changes.html#_index_templates_use_literal_index_patterns_literal_instead_of_literal_template_literal',\n
details:\n 'templates using `template` field:
security_audit_log,watches,.monitoring-alerts,triggered_watches,.ml-anomalies-,.ml-notifications,.ml-meta,.monitoring-kibana,.monitoring-es,.monitoring-logstash,.watch-history-6,.ml-state,security-index-template',\n
resolve_during_rolling_upgrade: false,\n },\n {\n level: 'warning',\n
message: 'one or more templates use deprecated mapping settings',\n url:
'https://www.elastic.co/guide/en/elasticsearch/reference/6.0/breaking_60_indices_changes.html',\n
details:\n '{.monitoring-logstash=[Coercion of boolean fields],
.monitoring-es=[Coercion of boolean fields], .ml-anomalies-=[Coercion of
boolean fields], .watch-history-6=[Coercion of boolean fields],
.monitoring-kibana=[Coercion of boolean fields],
security-index-template=[Coercion of boolean fields]}',\n
resolve_during_rolling_upgrade: false,\n },\n ],\n ilm_policies: {\n
myfreezepolicy: [\n {\n level: 'warning',\n message:\n \"ILM policy
[myfreezepolicy] contains the action 'freeze' that is deprecated and
will be removed in a future version.\",\n url:
'https://www.elastic.co/guide/en/elasticsearch/reference/master/frozen-indices.html',\n
details:\n 'This action is already a noop so it can be safely removed,
because frozen indices no longer offer any advantages. Consider cold or
frozen tiers in place of frozen indices.',\n
resolve_during_rolling_upgrade: false,\n },\n ],\n },\n templates: {\n
mytemplate: [\n {\n level: 'critical',\n message:\n 'Configuring source
mode in mappings is deprecated and will be removed in future versions.
Use [index.mapping.source.mode] index setting instead.',\n url:
'https://github.com/elastic/elasticsearch/pull/117172',\n
resolve_during_rolling_upgrade: false,\n },\n ],\n },\n};\n````\n* Go to
\"Stack Management > Upgrade Assistant\". Navigate to\n\"Elasticsearch
deprecation issues\"\n * Verify that the new actions column is there\n*
Verify that the column now contains the actions icon and opens
the\nflyout.\n * Verify that the resolution column still updates the
status\n* Verify that the deprecations that requires Manual action, now
display\na Gear icon in the actions column.\n* Verify that the entire
row is not longer clickable and the flyout only\ngets opened when
clicking in the icon.\n\n###
Demo\n<details>\n<summary>Video</summary>\n\n\n\n\nhttps://github.com/user-attachments/assets/22f16b7d-de08-42dd-8ffe-91acec4dab92\n\n\n\n</details>\n\n---------\n\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"ba012f668c3385594dee9279467c8f51b28c789f"}},"sourceBranch":"8.19","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/222346","number":222346,"mergeCommit":{"message":"[Upgrade
Assistant] Create actions column in Es deprecations (#222346)\n\nFixes
https://github.com/elastic/kibana/issues/222035\nPart of
https://github.com/elastic/kibana/issues/221977\n\n## Summary\nThis PR
is the first one for the enhancement in the ES deprecations\ntable in
Upgrade Assistant. This PR creates a new column called\n`Actions` and
moves the existing available actions in the `resolution`\ncolumn to it.
The icon and the flyout is the same. The status of the\nresolution still
gets updated in the `resolution` column.\n\nThe goal of this PR was that
no functionality or tests gets affected by\nthis changes (except the
unit test verifying that the entire row is\nclickable).\n\nNote: The
width of the columns is a little weird right now. It will\nadjust when
all columns have the expected content.\n\n### How to test\n\n* Follow
the instructions in\nhttps://github.com/elastic/kibana-team/issues/1521.
Use the data folder\nnamed `data_qaf_frozen` because it has the largest
variety of\ndeprecations.\nYou can also add some other deprecations by
replacing\n`x-pack/platform/plugins/private/upgrade_assistant/server/lib/es_deprecations_status/migrations.ts\n`
L272 with:\n````\nlet esDeprecations = (await
esClient.migration.deprecations()) as EsDeprecations;\nesDeprecations =
{\n ...esDeprecations,\n cluster_settings: [\n {\n level: 'warning',\n
message:\n 'Template patterns are no longer using `template` field, but
`index_patterns` instead',\n url:
'https://www.elastic.co/guide/en/elasticsearch/reference/6.0/breaking_60_indices_changes.html#_index_templates_use_literal_index_patterns_literal_instead_of_literal_template_literal',\n
details:\n 'templates using `template` field:
security_audit_log,watches,.monitoring-alerts,triggered_watches,.ml-anomalies-,.ml-notifications,.ml-meta,.monitoring-kibana,.monitoring-es,.monitoring-logstash,.watch-history-6,.ml-state,security-index-template',\n
resolve_during_rolling_upgrade: false,\n },\n {\n level: 'warning',\n
message: 'one or more templates use deprecated mapping settings',\n url:
'https://www.elastic.co/guide/en/elasticsearch/reference/6.0/breaking_60_indices_changes.html',\n
details:\n '{.monitoring-logstash=[Coercion of boolean fields],
.monitoring-es=[Coercion of boolean fields], .ml-anomalies-=[Coercion of
boolean fields], .watch-history-6=[Coercion of boolean fields],
.monitoring-kibana=[Coercion of boolean fields],
security-index-template=[Coercion of boolean fields]}',\n
resolve_during_rolling_upgrade: false,\n },\n ],\n ilm_policies: {\n
myfreezepolicy: [\n {\n level: 'warning',\n message:\n \"ILM policy
[myfreezepolicy] contains the action 'freeze' that is deprecated and
will be removed in a future version.\",\n url:
'https://www.elastic.co/guide/en/elasticsearch/reference/master/frozen-indices.html',\n
details:\n 'This action is already a noop so it can be safely removed,
because frozen indices no longer offer any advantages. Consider cold or
frozen tiers in place of frozen indices.',\n
resolve_during_rolling_upgrade: false,\n },\n ],\n },\n templates: {\n
mytemplate: [\n {\n level: 'critical',\n message:\n 'Configuring source
mode in mappings is deprecated and will be removed in future versions.
Use [index.mapping.source.mode] index setting instead.',\n url:
'https://github.com/elastic/elasticsearch/pull/117172',\n
resolve_during_rolling_upgrade: false,\n },\n ],\n },\n};\n````\n* Go to
\"Stack Management > Upgrade Assistant\". Navigate to\n\"Elasticsearch
deprecation issues\"\n * Verify that the new actions column is there\n*
Verify that the column now contains the actions icon and opens
the\nflyout.\n * Verify that the resolution column still updates the
status\n* Verify that the deprecations that requires Manual action, now
display\na Gear icon in the actions column.\n* Verify that the entire
row is not longer clickable and the flyout only\ngets opened when
clicking in the icon.\n\n###
Demo\n<details>\n<summary>Video</summary>\n\n\n\n\nhttps://github.com/user-attachments/assets/22f16b7d-de08-42dd-8ffe-91acec4dab92\n\n\n\n</details>\n\n---------\n\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"ba012f668c3385594dee9279467c8f51b28c789f"}}]},{"author":{"name":"Sonia
Sanz
Vivas","email":"sonia.sanzvivas@elastic.co"},"sourceCommit":{"committedDate":"2025-06-06T12:28:23Z","message":"[Upgrade
Assistant] Change resolution column icons to filled (#222764)\n\nPart of
https://github.com/elastic/kibana/issues/222036\n\n## Summary\n\nSmall
PR to change the icons in the ES deprecations table resolution\ncolumn
to the filled version as required in the mocks. I've also updated\nthe
icons in the Kibana Deprecations table for consistency.\n\nBefore:\n<img
width=\"583\" alt=\"Screenshot 2025-06-05 at 10 26
35\"\nsrc=\"https://github.com/user-attachments/assets/f22449dd-6859-4459-ba1d-bdfdaf535fde\"\n/>\n<img
width=\"522\" alt=\"Screenshot 2025-06-05 at 10 25
22\"\nsrc=\"https://github.com/user-attachments/assets/acb96c78-14b7-49b1-903d-c7f36237b15b\"\n/>\n\nAfter:\n<img
width=\"528\" alt=\"Screenshot 2025-06-05 at 10 23
09\"\nsrc=\"https://github.com/user-attachments/assets/6a7e888f-6fb7-44a7-a970-6b48d04f6f96\"\n/>\n\n<img
width=\"556\" alt=\"Screenshot 2025-06-05 at 10 24
31\"\nsrc=\"https://github.com/user-attachments/assets/fdb15ad7-825e-42d4-810f-869bf86dd36f\"\n/>\n\n\n##
How to test\n\n* Follow the instructions
in\nhttps://github.com/elastic/kibana-team/issues/1521. Use the any
data\nfolder.","sha":"1b5be7cc2e96f5ca4c03f215891969e45f062b30"},"sourcePullRequest":{"labels":[],"title":"Update
dependency chromedriver to ^137.0.4
(8.19)","number":222621,"url":"https://github.com/elastic/kibana/pull/222621"},"sourceBranch":"8.19","suggestedTargetBranches":[],"targetPullRequestStates":[]},{"author":{"name":"Sonia
Sanz
Vivas","email":"sonia.sanzvivas@elastic.co"},"sourceCommit":{"committedDate":"2025-06-11T13:38:03Z","message":"[Upgrade
Assistant] Add suggestions to resolution column (#223113)\n\nCloses
https://github.com/elastic/kibana/issues/222036\nPart of
https://github.com/elastic/kibana/issues/221977\n\n## Summary\n\nThis PR
modifies the resolution column to offer the user a\nrecommendation of
the action to take depending on the deprecation. The\nrow can also be
empty if we don't have any deprecation to show.\n\n###
Mocks\n\n\n\n###
How to test\n* Follow the instructions
in\nhttps://github.com/elastic/kibana-team/issues/1521. Use the data
folder\nnamed `data_most_types.zip` because it has almost all types
of\ndeprecations.\nYou can also add the remaining types by
replacing\n`x-pack/platform/plugins/private/upgrade_assistant/server/lib/es_deprecations_status/migrations.ts\n`
L272 with:\n````\nlet esDeprecations = (await
esClient.migration.deprecations()) as EsDeprecations;\nesDeprecations =
{\n ...esDeprecations,\n cluster_settings: [\n {\n level: 'warning',\n
message:\n 'Template patterns are no longer using `template` field, but
`index_patterns` instead',\n url:
'https://www.elastic.co/guide/en/elasticsearch/reference/6.0/breaking_60_indices_changes.html#_index_templates_use_literal_index_patterns_literal_instead_of_literal_template_literal',\n
details:\n 'templates using `template` field:
security_audit_log,watches,.monitoring-alerts,triggered_watches,.ml-anomalies-,.ml-notifications,.ml-meta,.monitoring-kibana,.monitoring-es,.monitoring-logstash,.watch-history-6,.ml-state,security-index-template',\n
resolve_during_rolling_upgrade: false,\n },\n {\n level: 'warning',\n
message: 'one or more templates use deprecated mapping settings',\n url:
'https://www.elastic.co/guide/en/elasticsearch/reference/6.0/breaking_60_indices_changes.html',\n
details:\n '{.monitoring-logstash=[Coercion of boolean fields],
.monitoring-es=[Coercion of boolean fields], .ml-anomalies-=[Coercion of
boolean fields], .watch-history-6=[Coercion of boolean fields],
.monitoring-kibana=[Coercion of boolean fields],
security-index-template=[Coercion of boolean fields]}',\n
resolve_during_rolling_upgrade: false,\n },\n ],\n ilm_policies: {\n
myfreezepolicy: [\n {\n level: 'warning',\n message:\n \"ILM policy
[myfreezepolicy] contains the action 'freeze' that is deprecated and
will be removed in a future version.\",\n url:
'https://www.elastic.co/guide/en/elasticsearch/reference/master/frozen-indices.html',\n
details:\n 'This action is already a noop so it can be safely removed,
because frozen indices no longer offer any advantages. Consider cold or
frozen tiers in place of frozen indices.',\n
resolve_during_rolling_upgrade: false,\n },\n ],\n },\n templates: {\n
mytemplate: [\n {\n level: 'critical',\n message:\n 'Configuring source
mode in mappings is deprecated and will be removed in future versions.
Use [index.mapping.source.mode] index setting instead.',\n url:
'https://github.com/elastic/elasticsearch/pull/117172',\n
resolve_during_rolling_upgrade: false,\n },\n ],\n },\n};\n````\n* Go to
\"Stack Management > Upgrade Assistant\". Navigate to\n\"Elasticsearch
deprecation issues\"\n \n\n### Screenshots\n<details>\n<img
width=\"1509\" alt=\"Screenshot 2025-06-09 at 15 31
02\"\nsrc=\"https://github.com/user-attachments/assets/5e2ff112-41d4-4c15-8d99-30da4129a1f4\"\n/>\n\n<img
width=\"1250\" alt=\"Screenshot 2025-06-09 at 15 27
16\"\nsrc=\"https://github.com/user-attachments/assets/b622eb6d-6af3-4c73-8d55-2c283352a477\"\n/>\n<img
width=\"1235\" alt=\"Screenshot 2025-06-09 at 15 26
54\"\nsrc=\"https://github.com/user-attachments/assets/ca56e143-6da4-4a9c-94c1-7f977e0645e4\"\n/>\n<img
width=\"1229\" alt=\"Screenshot 2025-06-09 at 15 16
51\"\nsrc=\"https://github.com/user-attachments/assets/9cf9a806-9b77-4a7f-aafd-2f7f7fa85714\"\n/>\n<img
width=\"1230\" alt=\"Screenshot 2025-06-09 at 15 15
53\"\nsrc=\"https://github.com/user-attachments/assets/dbdb2f7f-0b59-41ca-bfea-a27f72de7b35\"\n/>\n<img
width=\"1162\" alt=\"Screenshot 2025-06-09 at 15 13
08\"\nsrc=\"https://github.com/user-attachments/assets/58b0fb27-32d1-41d5-b18d-edd64c4cc941\"\n/>\n<img
width=\"1245\" alt=\"Screenshot 2025-06-09 at 15 12
40\"\nsrc=\"https://github.com/user-attachments/assets/f4872d46-c9c1-471e-9c26-29f5d56e55f6\"\n/>\n<img
width=\"1225\" alt=\"Screenshot 2025-06-09 at 15 12
28\"\nsrc=\"https://github.com/user-attachments/assets/64af7ee7-a75d-4b81-b7b8-399da78aff21\"\n/>\n<img
width=\"1246\" alt=\"Screenshot 2025-06-09 at 15 12
21\"\nsrc=\"https://github.com/user-attachments/assets/d581b5bd-ae37-4513-a2f1-035db36a2e9d\"\n/>\n<img
width=\"1235\" alt=\"Screenshot 2025-06-09 at 15 12
13\"\nsrc=\"https://github.com/user-attachments/assets/43b1a3b6-b30a-461d-b111-958911f175b4\"\n/>\n\n\n\n</details>\n\n---------\n\nCo-authored-by:
Vlada Chirmicci
<vlada.chirmicci@elastic.co>","sha":"c72c785e87f10e3a745b0de0bcbcc120beafd54d"},"sourcePullRequest":{"labels":[],"title":"Update
dependency chromedriver to ^137.0.4
(8.19)","number":222621,"url":"https://github.com/elastic/kibana/pull/222621"},"sourceBranch":"8.19","suggestedTargetBranches":[],"targetPullRequestStates":[]},{"author":{"name":"Sonia
Sanz
Vivas","email":"sonia.sanzvivas@elastic.co"},"sourceCommit":{"committedDate":"2025-06-16T14:02:00Z","message":"[Upgrade
Assistant] Update index unfreeze and read-only progress strings
(#223509)\n\nFixes https://github.com/elastic/kibana/issues/222036\n\n##
Summary\nThis PR changes the text we display when and index is set to
read-only\nor unfreeze. Until now, we only show a generic `Update
complete`.\n\n### How to test\n* Follow the instructions
in\nhttps://github.com/elastic/kibana-team/issues/1521. Use any data
folders\n* Verify that the status is correct when unfreezing or setting
as read\nonly an index. You can add a waiting time
in\n`x-pack/platform/plugins/private/upgrade_assistant/public/application/components/es_deprecations/deprecation_types/indices/use_update_index.tsx`\nto
review the `inProgress` state. Otherwise will be too fast and you\nwon't
be able to check that step.\n\n###
Demo\n\n\nhttps://github.com/user-attachments/assets/fa581b59-2fc5-41ab-adfb-c2d39682019e","sha":"7d02c645ecc3b5331a49240a12a612730b7c6665"},"sourcePullRequest":{"labels":[],"title":"Update
dependency chromedriver to ^137.0.4
(8.19)","number":222621,"url":"https://github.com/elastic/kibana/pull/222621"},"sourceBranch":"8.19","suggestedTargetBranches":[],"targetPullRequestStates":[]},{"author":{"name":"Sonia
Sanz
Vivas","email":"sonia.sanzvivas@elastic.co"},"sourceCommit":{"committedDate":"2025-06-19T08:08:49Z","message":"[Upgrade
Assistant] Show single action button in ES deprecations/Actions column
(#223576)\n\nCloses
https://github.com/elastic/kibana/issues/222317\nPart of
https://github.com/elastic/kibana/issues/221977\n\n## Summary\n\nThis PR
modifies the action column so it display the possible actions\nfor
indices and data streams. The read-only and unfreeze options are\nopened
in the flyout. Creating the modal would be done in a follow
up\ntask.\n\n###
Mocks\n\n\n\n###
How to test\n* Follow the instructions
in\nhttps://github.com/elastic/kibana-team/issues/1521. Use the data
folder\nnamed `data_most_types.zip` because it has almost all types
of\ndeprecations.\n* Go to ES deprecations table and click on the icons,
perform different\nactions and verify the flyout shows the status after
the action started.\n\n###
Demo\n\n\nhttps://github.com/user-attachments/assets/07764d05-31b5-4a05-85a1-85e18d3ec18e","sha":"5ffc7522f769b6a384f97281ff3a3d8e69b92040","branchLabelMapping":{"^v8.16.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Kibana
Management","release_note:skip","Feature:Upgrade
Assistant","backport:version","v8.19.0","UA_needs_forwardport_9.1"],"title":"[Upgrade
Assistant] Show single action button in ES deprecations/Actions
column","number":223576,"url":"https://github.com/elastic/kibana/pull/223576","mergeCommit":{"message":"[Upgrade
Assistant] Show single action button in ES deprecations/Actions column
(#223576)\n\nCloses
https://github.com/elastic/kibana/issues/222317\nPart of
https://github.com/elastic/kibana/issues/221977\n\n## Summary\n\nThis PR
modifies the action column so it display the possible actions\nfor
indices and data streams. The read-only and unfreeze options are\nopened
in the flyout. Creating the modal would be done in a follow
up\ntask.\n\n###
Mocks\n\n\n\n###
How to test\n* Follow the instructions
in\nhttps://github.com/elastic/kibana-team/issues/1521. Use the data
folder\nnamed `data_most_types.zip` because it has almost all types
of\ndeprecations.\n* Go to ES deprecations table and click on the icons,
perform different\nactions and verify the flyout shows the status after
the action started.\n\n###
Demo\n\n\nhttps://github.com/user-attachments/assets/07764d05-31b5-4a05-85a1-85e18d3ec18e","sha":"5ffc7522f769b6a384f97281ff3a3d8e69b92040"}},"sourceBranch":"8.19","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/223576","number":223576,"mergeCommit":{"message":"[Upgrade
Assistant] Show single action button in ES deprecations/Actions column
(#223576)\n\nCloses
https://github.com/elastic/kibana/issues/222317\nPart of
https://github.com/elastic/kibana/issues/221977\n\n## Summary\n\nThis PR
modifies the action column so it display the possible actions\nfor
indices and data streams. The read-only and unfreeze options are\nopened
in the flyout. Creating the modal would be done in a follow
up\ntask.\n\n###
Mocks\n\n\n\n###
How to test\n* Follow the instructions
in\nhttps://github.com/elastic/kibana-team/issues/1521. Use the data
folder\nnamed `data_most_types.zip` because it has almost all types
of\ndeprecations.\n* Go to ES deprecations table and click on the icons,
perform different\nactions and verify the flyout shows the status after
the action started.\n\n###
Demo\n\n\nhttps://github.com/user-attachments/assets/07764d05-31b5-4a05-85a1-85e18d3ec18e","sha":"5ffc7522f769b6a384f97281ff3a3d8e69b92040"}}]},{"author":{"name":"Sonia
Sanz
Vivas","email":"sonia.sanzvivas@elastic.co"},"sourceCommit":{"committedDate":"2025-06-19T14:41:35Z","message":"[Upgrade
Assistant] Create modal for setting to read-only and unfreeze
(#224525)\n\nFixes https://github.com/elastic/kibana/issues/222037\nPar
to of https://github.com/elastic/kibana/issues/221977\n\n## Summary\n*
This PR creates the modal for the read-only actions in the
ES\ndeprecations table.\n* It add a confirm step for `Unfreeze`. \n* It
changes the `WarningCheckbox` for the data streams for both the\nmodal
and the flyout so it looks like the Index ones.\n* Introduces the
explicit name of the data stream in the steps for both\nreindex and
read-only.\n\n### Mocks\n<img width=\"395\" alt=\"Screenshot 2025-06-19
at 10 52
43\"\nsrc=\"https://github.com/user-attachments/assets/fe72c007-4299-4a05-9ec8-f2f375b4f55f\"\n/>\n\n\n**Note**:
As agreed with @jovana-andjelkovic, the warning checkbox would\nkeep the
border and the same format that it has in the flyout.\n\n\n### How to
test\n* Follow the instructions
in\nhttps://github.com/elastic/kibana-team/issues/1521. Use the data
folder\nnamed `data_most_types.zip` because it has almost all types
of\ndeprecations.\n* Verify unfreeze modal.\n* Check read-only index
modal\n* Check data stream read-only modal\n* Check changes in accept
checkbox in Data stream reindex modal\n\n###
Screenshots\n<details>\n<summary>Index unfreeze modal</summary>\n<img
width=\"989\" alt=\"Screenshot 2025-06-19 at 10 36
08\"\nsrc=\"https://github.com/user-attachments/assets/056e5cbf-1f53-409a-a2ab-6c897869ce7b\"\n/>\n<img
width=\"918\" alt=\"Screenshot 2025-06-19 at 10 37
53\"\nsrc=\"https://github.com/user-attachments/assets/e226df22-d450-47f8-a2e8-8301c3c79a7f\"\n/>\n<img
width=\"813\" alt=\"Screenshot 2025-06-19 at 10 38
04\"\nsrc=\"https://github.com/user-attachments/assets/4bdcc229-1664-418a-9d8f-2e8eed54e23e\"\n/>\n\n\n</details>\n\n<details>\n<summary>Index
read-only modal</summary>\n\n\n<img width=\"911\" alt=\"Screenshot
2025-06-19 at 10 37
27\"\nsrc=\"https://github.com/user-attachments/assets/069aabdf-5de1-4c6c-970a-180a6f29bf1d\"\n/>\n\n<img
width=\"776\" alt=\"Screenshot 2025-06-19 at 10 37
34\"\nsrc=\"https://github.com/user-attachments/assets/61416fc0-1008-4e21-87bc-e75c45f160fb\"\n/>\n\n<img
width=\"816\" alt=\"Screenshot 2025-06-19 at 10 37
43\"\nsrc=\"https://github.com/user-attachments/assets/9e509720-9346-416f-8ffa-1a0cbef5d918\"\n/>\n\n</details>\n\n\n<details>\n<summary>Data
stream read-only modal</summary>\n\n<img width=\"877\" alt=\"Screenshot
2025-06-19 at 10 39
36\"\nsrc=\"https://github.com/user-attachments/assets/dd2a5f94-f7cc-4ef9-aca6-a9cb789f0ce9\"\n/>\n\n<img
width=\"1066\" alt=\"Screenshot 2025-06-19 at 10 40
23\"\nsrc=\"https://github.com/user-attachments/assets/083fc674-3503-4cf8-bec5-24d551bd8e6d\"\n/>\n\n<img
width=\"865\" alt=\"Screenshot 2025-06-19 at 10 40
30\"\nsrc=\"https://github.com/user-attachments/assets/53cda862-41e1-4825-8309-090ebfbe9739\"\n/>\n\n<img
width=\"937\" alt=\"Screenshot 2025-06-19 at 10 40
43\"\nsrc=\"https://github.com/user-attachments/assets/8140917b-16a9-4e61-bf14-cb53bebe7ca5\"\n/>\n\n</details>\n<details>\n<summary>Data
stream flyout checkbox</summary>\n<img width=\"583\" alt=\"Screenshot
2025-06-19 at 10 40
54\"\nsrc=\"https://github.com/user-attachments/assets/8a9a6023-f474-4c7d-985c-26db11011934\"\n/>\n</details>","sha":"4da40d22780516ffea86be8eaf5092a1a6b3ad85","branchLabelMapping":{"^v8.16.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Kibana
Management","release_note:skip","Feature:Upgrade
Assistant","backport:version","v8.19.0","UA_needs_forwardport_9.1"],"title":"[Upgrade
Assistant] Create modal for setting to read-only and
unfreeze","number":224525,"url":"https://github.com/elastic/kibana/pull/224525","mergeCommit":{"message":"[Upgrade
Assistant] Create modal for setting to read-only and unfreeze
(#224525)\n\nFixes https://github.com/elastic/kibana/issues/222037\nPar
to of https://github.com/elastic/kibana/issues/221977\n\n## Summary\n*
This PR creates the modal for the read-only actions in the
ES\ndeprecations table.\n* It add a confirm step for `Unfreeze`. \n* It
changes the `WarningCheckbox` for the data streams for both the\nmodal
and the flyout so it looks like the Index ones.\n* Introduces the
explicit name of the data stream in the steps for both\nreindex and
read-only.\n\n### Mocks\n<img width=\"395\" alt=\"Screenshot 2025-06-19
at 10 52
43\"\nsrc=\"https://github.com/user-attachments/assets/fe72c007-4299-4a05-9ec8-f2f375b4f55f\"\n/>\n\n\n**Note**:
As agreed with @jovana-andjelkovic, the warning checkbox would\nkeep the
border and the same format that it has in the flyout.\n\n\n### How to
test\n* Follow the instructions
in\nhttps://github.com/elastic/kibana-team/issues/1521. Use the data
folder\nnamed `data_most_types.zip` because it has almost all types
of\ndeprecations.\n* Verify unfreeze modal.\n* Check read-only index
modal\n* Check data stream read-only modal\n* Check changes in accept
checkbox in Data stream reindex modal\n\n###
Screenshots\n<details>\n<summary>Index unfreeze modal</summary>\n<img
width=\"989\" alt=\"Screenshot 2025-06-19 at 10 36
08\"\nsrc=\"https://github.com/user-attachments/assets/056e5cbf-1f53-409a-a2ab-6c897869ce7b\"\n/>\n<img
width=\"918\" alt=\"Screenshot 2025-06-19 at 10 37
53\"\nsrc=\"https://github.com/user-attachments/assets/e226df22-d450-47f8-a2e8-8301c3c79a7f\"\n/>\n<img
width=\"813\" alt=\"Screenshot 2025-06-19 at 10 38
04\"\nsrc=\"https://github.com/user-attachments/assets/4bdcc229-1664-418a-9d8f-2e8eed54e23e\"\n/>\n\n\n</details>\n\n<details>\n<summary>Index
read-only modal</summary>\n\n\n<img width=\"911\" alt=\"Screenshot
2025-06-19 at 10 37
27\"\nsrc=\"https://github.com/user-attachments/assets/069aabdf-5de1-4c6c-970a-180a6f29bf1d\"\n/>\n\n<img
width=\"776\" alt=\"Screenshot 2025-06-19 at 10 37
34\"\nsrc=\"https://github.com/user-attachments/assets/61416fc0-1008-4e21-87bc-e75c45f160fb\"\n/>\n\n<img
width=\"816\" alt=\"Screenshot 2025-06-19 at 10 37
43\"\nsrc=\"https://github.com/user-attachments/assets/9e509720-9346-416f-8ffa-1a0cbef5d918\"\n/>\n\n</details>\n\n\n<details>\n<summary>Data
stream read-only modal</summary>\n\n<img width=\"877\" alt=\"Screenshot
2025-06-19 at 10 39
36\"\nsrc=\"https://github.com/user-attachments/assets/dd2a5f94-f7cc-4ef9-aca6-a9cb789f0ce9\"\n/>\n\n<img
width=\"1066\" alt=\"Screenshot 2025-06-19 at 10 40
23\"\nsrc=\"https://github.com/user-attachments/assets/083fc674-3503-4cf8-bec5-24d551bd8e6d\"\n/>\n\n<img
width=\"865\" alt=\"Screenshot 2025-06-19 at 10 40
30\"\nsrc=\"https://github.com/user-attachments/assets/53cda862-41e1-4825-8309-090ebfbe9739\"\n/>\n\n<img
width=\"937\" alt=\"Screenshot 2025-06-19 at 10 40
43\"\nsrc=\"https://github.com/user-attachments/assets/8140917b-16a9-4e61-bf14-cb53bebe7ca5\"\n/>\n\n</details>\n<details>\n<summary>Data
stream flyout checkbox</summary>\n<img width=\"583\" alt=\"Screenshot
2025-06-19 at 10 40
54\"\nsrc=\"https://github.com/user-attachments/assets/8a9a6023-f474-4c7d-985c-26db11011934\"\n/>\n</details>","sha":"4da40d22780516ffea86be8eaf5092a1a6b3ad85"}},"sourceBranch":"8.19","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/224525","number":224525,"mergeCommit":{"message":"[Upgrade
Assistant] Create modal for setting to read-only and unfreeze
(#224525)\n\nFixes https://github.com/elastic/kibana/issues/222037\nPar
to of https://github.com/elastic/kibana/issues/221977\n\n## Summary\n*
This PR creates the modal for the read-only actions in the
ES\ndeprecations table.\n* It add a confirm step for `Unfreeze`. \n* It
changes the `WarningCheckbox` for the data streams for both the\nmodal
and the flyout so it looks like the Index ones.\n* Introduces the
explicit name of the data stream in the steps for both\nreindex and
read-only.\n\n### Mocks\n<img width=\"395\" alt=\"Screenshot 2025-06-19
at 10 52
43\"\nsrc=\"https://github.com/user-attachments/assets/fe72c007-4299-4a05-9ec8-f2f375b4f55f\"\n/>\n\n\n**Note**:
As agreed with @jovana-andjelkovic, the warning checkbox would\nkeep the
border and the same format that it has in the flyout.\n\n\n### How to
test\n* Follow the instructions
in\nhttps://github.com/elastic/kibana-team/issues/1521. Use the data
folder\nnamed `data_most_types.zip` because it has almost all types
of\ndeprecations.\n* Verify unfreeze modal.\n* Check read-only index
modal\n* Check data stream read-only modal\n* Check changes in accept
checkbox in Data stream reindex modal\n\n###
Screenshots\n<details>\n<summary>Index unfreeze modal</summary>\n<img
width=\"989\" alt=\"Screenshot 2025-06-19 at 10 36
08\"\nsrc=\"https://github.com/user-attachments/assets/056e5cbf-1f53-409a-a2ab-6c897869ce7b\"\n/>\n<img
width=\"918\" alt=\"Screenshot 2025-06-19 at 10 37
53\"\nsrc=\"https://github.com/user-attachments/assets/e226df22-d450-47f8-a2e8-8301c3c79a7f\"\n/>\n<img
width=\"813\" alt=\"Screenshot 2025-06-19 at 10 38
04\"\nsrc=\"https://github.com/user-attachments/assets/4bdcc229-1664-418a-9d8f-2e8eed54e23e\"\n/>\n\n\n</details>\n\n<details>\n<summary>Index
read-only modal</summary>\n\n\n<img width=\"911\" alt=\"Screenshot
2025-06-19 at 10 37
27\"\nsrc=\"https://github.com/user-attachments/assets/069aabdf-5de1-4c6c-970a-180a6f29bf1d\"\n/>\n\n<img
width=\"776\" alt=\"Screenshot 2025-06-19 at 10 37
34\"\nsrc=\"https://github.com/user-attachments/assets/61416fc0-1008-4e21-87bc-e75c45f160fb\"\n/>\n\n<img
width=\"816\" alt=\"Screenshot 2025-06-19 at 10 37
43\"\nsrc=\"https://github.com/user-attachments/assets/9e509720-9346-416f-8ffa-1a0cbef5d918\"\n/>\n\n</details>\n\n\n<details>\n<summary>Data
stream read-only modal</summary>\n\n<img width=\"877\" alt=\"Screenshot
2025-06-19 at 10 39
36\"\nsrc=\"https://github.com/user-attachments/assets/dd2a5f94-f7cc-4ef9-aca6-a9cb789f0ce9\"\n/>\n\n<img
width=\"1066\" alt=\"Screenshot 2025-06-19 at 10 40
23\"\nsrc=\"https://github.com/user-attachments/assets/083fc674-3503-4cf8-bec5-24d551bd8e6d\"\n/>\n\n<img
width=\"865\" alt=\"Screenshot 2025-06-19 at 10 40
30\"\nsrc=\"https://github.com/user-attachments/assets/53cda862-41e1-4825-8309-090ebfbe9739\"\n/>\n\n<img
width=\"937\" alt=\"Screenshot 2025-06-19 at 10 40
43\"\nsrc=\"https://github.com/user-attachments/assets/8140917b-16a9-4e61-bf14-cb53bebe7ca5\"\n/>\n\n</details>\n<details>\n<summary>Data
stream flyout checkbox</summary>\n<img width=\"583\" alt=\"Screenshot
2025-06-19 at 10 40
54\"\nsrc=\"https://github.com/user-attachments/assets/8a9a6023-f474-4c7d-985c-26db11011934\"\n/>\n</details>","sha":"4da40d22780516ffea86be8eaf5092a1a6b3ad85"}}]},{"author":{"name":"Sonia
Sanz
Vivas","email":"sonia.sanzvivas@elastic.co"},"sourceCommit":{"committedDate":"2025-06-19T11:22:22Z","message":"[Upgrade
assistant] Unify read-only copies (#224532)\n\nPart of:
https://github.com/elastic/kibana/issues/222037\n\n## Summary\nThis PR
unifies the copies for the `Set to read-only` option. We had\ndifferent
copies option such as \"Mark as read-only\", \"Flag as read-only\"\nor
\"Make
read-only\".","sha":"b414ba4d25320e8eddb8f2d68dce0604544a061c","branchLabelMapping":{"^v8.16.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Kibana
Management","release_note:skip","Feature:Upgrade
Assistant","backport:version","v8.19.0","UA_needs_forwardport_9.1"],"title":"[Upgrade
assistant] Unify read-only
copies","number":224532,"url":"https://github.com/elastic/kibana/pull/224532","mergeCommit":{"message":"[Upgrade
assistant] Unify read-only copies (#224532)\n\nPart of:
https://github.com/elastic/kibana/issues/222037\n\n## Summary\nThis PR
unifies the copies for the `Set to read-only` option. We had\ndifferent
copies option such as \"Mark as read-only\", \"Flag as read-only\"\nor
\"Make
read-only\".","sha":"b414ba4d25320e8eddb8f2d68dce0604544a061c"}},"sourceBranch":"8.19","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/224532","number":224532,"mergeCommit":{"message":"[Upgrade
assistant] Unify read-only copies (#224532)\n\nPart of:
https://github.com/elastic/kibana/issues/222037\n\n## Summary\nThis PR
unifies the copies for the `Set to read-only` option. We had\ndifferent
copies option such as \"Mark as read-only\", \"Flag as read-only\"\nor
\"Make
read-only\".","sha":"b414ba4d25320e8eddb8f2d68dce0604544a061c"}}]},{"author":{"name":"Sonia
Sanz
Vivas","email":"sonia.sanzvivas@elastic.co"},"sourceCommit":{"committedDate":"2025-06-19T11:12:58Z","message":"[Upgrade
Assistant] Small cosmetic fixes (#224535)\n\nPart of
https://github.com/elastic/kibana/issues/221977\n\n## Summary\nThis PR
introduces two small cosmetic fixes:\n* Change Transforms callout color
to primary (not warning) to use the\nsame as other of the same
characteristics (ML, frozen, follower...)\n<img width=\"499\"
alt=\"Screenshot 2025-06-19 at 11 14
55\"\nsrc=\"https://github.com/user-attachments/assets/b04be621-15e4-4069-a7e8-4fc5755c72ea\"\n/>\n\n*
Modifies the size of the size of the info icon in the ES
deprecations\ntable so it doesn't compete visually with the Action
icons\n<img width=\"388\" alt=\"Screenshot 2025-06-19 at 11 33
00\"\nsrc=\"https://github.com/user-attachments/assets/df33fc14-1c96-437c-b19d-8729e0d974d9\"\n/>","sha":"f61f702ea7b2fad6f78529030b948706251d66ff","branchLabelMapping":{"^v8.16.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Kibana
Management","release_note:skip","Feature:Upgrade
Assistant","backport:version","v8.19.0","UA_needs_forwardport_9.1"],"title":"[Upgrade
Assistant] Small cosmetic
fixes","number":224535,"url":"https://github.com/elastic/kibana/pull/224535","mergeCommit":{"message":"[Upgrade
Assistant] Small cosmetic fixes (#224535)\n\nPart of
https://github.com/elastic/kibana/issues/221977\n\n## Summary\nThis PR
introduces two small cosmetic fixes:\n* Change Transforms callout color
to primary (not warning) to use the\nsame as other of the same
characteristics (ML, frozen, follower...)\n<img width=\"499\"
alt=\"Screenshot 2025-06-19 at 11 14
55\"\nsrc=\"https://github.com/user-attachments/assets/b04be621-15e4-4069-a7e8-4fc5755c72ea\"\n/>\n\n*
Modifies the size of the size of the info icon in the ES
deprecations\ntable so it doesn't compete visually with the Action
icons\n<img width=\"388\" alt=\"Screenshot 2025-06-19 at 11 33
00\"\nsrc=\"https://github.com/user-attachments/assets/df33fc14-1c96-437c-b19d-8729e0d974d9\"\n/>","sha":"f61f702ea7b2fad6f78529030b948706251d66ff"}},"sourceBranch":"8.19","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/224535","number":224535,"mergeCommit":{"message":"[Upgrade
Assistant] Small cosmetic fixes (#224535)\n\nPart of
https://github.com/elastic/kibana/issues/221977\n\n## Summary\nThis PR
introduces two small cosmetic fixes:\n* Change Transforms callout color
to primary (not warning) to use the\nsame as other of the same
characteristics (ML, frozen, follower...)\n<img width=\"499\"
alt=\"Screenshot 2025-06-19 at 11 14
55\"\nsrc=\"https://github.com/user-attachments/assets/b04be621-15e4-4069-a7e8-4fc5755c72ea\"\n/>\n\n*
Modifies the size of the size of the info icon in the ES
deprecations\ntable so it doesn't compete visually with the Action
icons\n<img width=\"388\" alt=\"Screenshot 2025-06-19 at 11 33
00\"\nsrc=\"https://github.com/user-attachments/assets/df33fc14-1c96-437c-b19d-8729e0d974d9\"\n/>","sha":"f61f702ea7b2fad6f78529030b948706251d66ff"}}]},{"author":{"name":"Sonia
Sanz
Vivas","email":"sonia.sanzvivas@elastic.co"},"sourceCommit":{"committedDate":"2025-06-20T13:41:49Z","message":"[Upgrade
Assistant] Add manually resolve for follower readonly (#224600)\n\nPart
of https://github.com/elastic/kibana/issues/221977\n\n## Summary\nWhen
testing all my changes I realized I missed a case for sugestions:\nwhen
an index is a follower index and is set to read-only it still\nappears
in the table with a warning but we suggested to set to read-only\n(what
already was).\n\nThis PR improves the verification for the suggestions
and now, for a\nfollower that is already read-only, it display `Resolve
manually` and\nindicates the termination of replication in the
tooltip.\n<img width=\"628\" alt=\"Screenshot 2025-06-19 at 17 12
07\"\nsrc=\"https://github.com/user-attachments/assets/4a29b641-181e-4881-a008-5ccc80681376\"\n/>\n\n\n###
How to test\n* Follow the instructions
in\nhttps://github.com/elastic/kibana-team/issues/1521. Use the data
folder\nnamed `data_most_types.zip`.\n* Set to read-only the index
called `follower-index`\n* Refresh the page\n* Verify that know it
displays the `Resolve manually` suggestion and the\ntooltip explains
that replication can be
terminated.","sha":"802256e73dd1f52e2159bd8f0b413b94e40e8b31","branchLabelMapping":{"^v8.16.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Kibana
Management","release_note:skip","Feature:Upgrade
Assistant","backport:version","v8.19.0","UA_needs_forwardport_9.1"],"title":"[Upgrade
Assistant] Add manually resolve for follower
readonly","number":224600,"url":"https://github.com/elastic/kibana/pull/224600","mergeCommit":{"message":"[Upgrade
Assistant] Add manually resolve for follower readonly (#224600)\n\nPart
of https://github.com/elastic/kibana/issues/221977\n\n## Summary\nWhen
testing all my changes I realized I missed a case for sugestions:\nwhen
an index is a follower index and is set to read-only it still\nappears
in the table with a warning but we suggested to set to read-only\n(what
already was).\n\nThis PR improves the verification for the suggestions
and now, for a\nfollower that is already read-only, it display `Resolve
manually` and\nindicates the termination of replication in the
tooltip.\n<img width=\"628\" alt=\"Screenshot 2025-06-19 at 17 12
07\"\nsrc=\"https://github.com/user-attachments/assets/4a29b641-181e-4881-a008-5ccc80681376\"\n/>\n\n\n###
How to test\n* Follow the instructions
in\nhttps://github.com/elastic/kibana-team/issues/1521. Use the data
folder\nnamed `data_most_types.zip`.\n* Set to read-only the index
called `follower-index`\n* Refresh the page\n* Verify that know it
displays the `Resolve manually` suggestion and the\ntooltip explains
that replication can be
terminated.","sha":"802256e73dd1f52e2159bd8f0b413b94e40e8b31"}},"sourceBranch":"8.19","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"8.19","label":"v8.19.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/224600","number":224600,"mergeCommit":{"message":"[Upgrade
Assistant] Add manually resolve for follower readonly (#224600)\n\nPart
of https://github.com/elastic/kibana/issues/221977\n\n## Summary\nWhen
testing all my changes I realized I missed a case for sugestions:\nwhen
an index is a follower index and is set to read-only it still\nappears
in the table with a warning but we suggested to set to read-only\n(what
already was).\n\nThis PR improves the verification for the suggestions
and now, for a\nfollower that is already read-only, it display `Resolve
manually` and\nindicates the termination of replication in the
tooltip.\n<img width=\"628\" alt=\"Screenshot 2025-06-19 at 17 12
07\"\nsrc=\"https://github.com/user-attachments/assets/4a29b641-181e-4881-a008-5ccc80681376\"\n/>\n\n\n###
How to test\n* Follow the instructions
in\nhttps://github.com/elastic/kibana-team/issues/1521. Use the data
folder\nnamed `data_most_types.zip`.\n* Set to read-only the index
called `follower-index`\n* Refresh the page\n* Verify that know it
displays the `Resolve manually` suggestion and the\ntooltip explains
that replication can be
terminated.","sha":"802256e73dd1f52e2159bd8f0b413b94e40e8b31"}}]}]
BACKPORT-->
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Updates the Dataset Quality functional test suite to skip tests
when running in Kibana 8.19 against Elasticsearch 9.0 in a forward
compatibility test run. , where the `read_failure_store` index privilege
is not available. The privilege checks for `read_failure_store` fail as
they are incompatible with ES 9.0, since ES 9.0 does not support Failure
Store.
#### Context
While investigating e2e test failures related to the missing
`read_failure_store` privilege in ES 9.0, it was found that almost all
Dataset Quality test suites fail. The failures occur because the
following endpoints which most of the e2e tests depend on, check for
this privilege and error out:
- `/settings`
- `/details`
- `/total_docs`
- `/stats`
#### Error thrown by endpoints:
```yaml
error: "Internal Server Error"
message: "illegal_argument_exception\n\tRoot causes:\n\t\tillegal_argument_exception: unknown index privilege [read_failure_store]. a privilege must be either one of the predefined fixed indices privileges [all,auto_configure,create,create_doc,create_index,cross_cluster_replication,cross_cluster_replication_internal,delete,delete_index,index,maintenance,manage,manage_data_stream_lifecycle,manage_follow_index,manage_ilm,manage_leader_index,monitor,none,read,read_cross_cluster,view_index_metadata,write] or a pattern over one of the available index actions"
statusCode: 500
```
#### Screenshots
<table>
<tr><th>Main Page</th><th>Details Page</th></tr>
<tr>
<td>
</td>
<td>
</td>
</tr>
</table>
## Summary
[Support collapsible section in Integration
README](https://github.com/elastic/integration-experience/issues/82)
The public Integrations docs page recently added support for collapsible
sections (e.g., for field tables and sample events). This PR brings the
same functionality to Kibana to reduce scrolling and help users focus on
the most relevant information.
To display an accordion, the README should include the following markup:
```
<details>
<summary>Click to expand</summary>
This content is hidden by default.
</details>
```
However, we do not want to modify the integration READMEs directly.
Doing so would cause these tags to appear as raw HTML in older versions
of Kibana
Bumping the minimum supported Kibana version for each integration is
also not a solution, as it would complicate backports and maintenance.
#### Proposed solution
Detect in Kibana parts that should be collapsible, like `exported
fields` and update the markdown with the necessary markups. Similar to
what the `integration-docs` does in
https://github.com/elastic/integration-docs/issues/342
#### Dependencies added:
- `rehype-raw`: Parse and render HTML inside Markdown.
- `rehype-sanitize`: Sanitize potentially unsafe HTML.
#### Version pinning for compatibility
- `rehype-sanitize@4.0.0`: Uses hast-util-sanitize@3+, which provides a
built-in default schema and is compatible with CommonJS environments.
- `rehype-raw@5.1.0`: The latest version that supports CommonJS. Later
versions are ESM-only.
https://github.com/user-attachments/assets/15f0822b-9b36-45e6-a47e-c8fa0dedd4c3
### 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
- [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
- [ ] 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.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR makes the following fields available as advanced policy options
in Elastic Defend.
* `windows.advanced.events.security.provider_etw`
## Release Note
{elastic-defend} Adds advanced policy options that let users enable or
disable the Microsoft-Windows-Security-Auditing ETW provider for
security events collection.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] 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)
- [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>
## 📓 Summary
Given the setting introduced in [#221286 [ML] AIOps: Adds ability to
disable AIOps features in
Kibana](https://github.com/elastic/kibana/pull/221286), this adds the
expected configuration value to disable all the AIOPS features for
`logs_essentials` projects.
**Addresses:** https://github.com/elastic/kibana/issues/202078
**Resolves:** https://github.com/elastic/kibana/issues/166215
## Summary
This PR actualizes prebuilt rule upgrade test plans to correspond to the current feature state.
## Details
The changes are summarized in the following items
- Missing scenarios were added
- https://github.com/elastic/kibana/issues/166215 was addressed
- The wording was fixed to make the test scenarios shorter and focused
- Prebuilt Rules Customization Milestone 2 test scenarios were migrated to a separate test plan `prebuilt_rule_json_diff.md`. The functionality is still relevant and used for rule type changes and under low-tier licenses.
Fixes some issues introduced by
https://github.com/elastic/kibana/pull/217865
## Summary
While testing something in Serverles, we realized that the Console
copy/cut/paste commands weren't working as expected: cut wasn't working
and paste something from outside Kibana behaved weird. Those changes
were introduced in https://github.com/elastic/kibana/pull/217865.
This PR fixes it by:
* Uncomment commented line (probably by mistake), allowing cut.
* Deletes the keybindings lines, allowing them to be native to the
user's OS.
* Removes the trick done for set position when copying. This glitch was
caused by the keybindings let them to default by OS fix it.
Note: You may need to do `yarn kbn clean && yarn kbn bootstrap` before
starting the dev server to see the changes.
Closes#224081
This PR enables Traces in Discover by default. There's no longer a need
to enable trace related profiles in the yml configuration, it will work
out of the box.
Depends on https://github.com/elastic/kibana/pull/221610
This PR adds the import index workflow to privileged user monitoring and
API changes required to support it.
### API Enhancements
* **New API for privilege monitoring index creation**: Added a new API
endpoint (`PUT /api/entity_analytics/monitoring/privileges/indices`) to
create indices for privilege monitoring with support for `standard` and
`lookup` modes. This includes the implementation of request and response
schemas (`create_indidex.gen.ts`, `create_indidex.schema.yaml`).
[[1]](diffhunk://#diff-68329bb90dea945f343e1637990d5d05bc159e0aa2511ef1e45d37ed1a6cda51R1-R41)
[[2]](diffhunk://#diff-e979499654a27b3c1930d63c5b1002113c1c3f53f84ce27a4d75a5c492717a96R1-R42)
* **Updated privilege monitoring health response**: Modified the health
response schema to include a `status` field and an optional `error`
object for detailed error handling
(`privilege_monitoring/health.gen.ts`,
`privilege_monitoring/health.schema.yaml`).
[[1]](diffhunk://#diff-00f39a3e65a336eaddf7d3203d1370d910f5ecd2062b6cc21d9c06922c12884eR19-R28)
[[2]](diffhunk://#diff-83afa72b7a1fc48f3cc063e9fb855190d3525228bc0488fb8b871e112b90e961L22-R33)
### Frontend Integration
* **Introduce the create index modal that opens when the create index
button is clicked.
* **Onboarding modal improvements**: Updated the `AddDataSourcePanel`
component to handle index creation more robustly by passing callbacks to
the modal (`add_data_source.tsx`).
* **Error handling in UI**: Enhanced the `PrivilegedUserMonitoring`
component to display error callouts when privilege monitoring data fails
to load (`privileged_user_monitoring/index.tsx`).
[[1]](diffhunk://#diff-273ad32c97dcf15c6c6054fd7c5516d587132674578d25986b235cd174c75789R22-R26)
[[2]](diffhunk://#diff-273ad32c97dcf15c6c6054fd7c5516d587132674578d25986b235cd174c75789R38-R51)
### How to test it?
* Go to the priv mon page with an empty cluster
* Click on the data source by the index button
* Search for available indices, it should return indices with
`user.name.keyword` fields
* Click 'create index' and create a new index
* Choose the created index and click 'Add privileged users'
* You should be redirected to the dashboard (The API is currently not
working)
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] 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)
### 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Implements #213020
Partially implements filter bar seen with #213015
This PR adds a callout on the alert details page to encourage users to
visit the related alerts page when at least one alert was triggered
within 30 minutes of the current alert. If no alerts were triggered, the
message remains without a call to action.
https://github.com/user-attachments/assets/23b2d3e9-353b-45e1-a007-d188db5617fc
## Testing
The related alert query usually find alerts that were raised within a
day of each other. To find alerts that were raised within a few minutes,
try creating an SLO with a chosen groupBy field that will easily violate
a burn rate rule. Alerts should be triggered for each instance within
seconds. Once the filter is executed, these alerts should appear without
alerts that were triggered earlier in the day.
## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR adds `kbn/cypress-test-helper` as platform shared package to
replace invalid imports from private `security-solution` plugin in
platform shared plugin `osquery`.
The reason is that we are **currently blocked with x-pack relocation due
to circular dependency**, e.g. in
https://github.com/elastic/kibana/pull/223897
```
info starting [tsc] > node_modules/typescript/bin/tsc -b tsconfig.refs.json --pretty
--
| 2025-06-13 13:17:30 UTC | proc [tsc] error TS6202: Project references may not form a circular graph. Cycle detected: /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/tsconfig.refs.json
| 2025-06-13 13:17:30 UTC | proc [tsc] /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/x-pack/platform/plugins/shared/osquery/cypress/tsconfig.type_check.json
| 2025-06-13 13:17:30 UTC | proc [tsc] /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/x-pack/test_serverless/tsconfig.type_check.json
| 2025-06-13 13:17:30 UTC | proc [tsc] /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/x-pack/solutions/security/test/tsconfig.type_check.json
| 2025-06-13 13:17:30 UTC | proc [tsc] /opt/buildkite-agent/builds/bk-agent-prod-gcp-1749820368903967112/elastic/kibana-pull-request/kibana/x-pack/test/security_solution_endpoint/tsconfig.type_check.json
```
**Important:**
This PR focuses only on replacing test helpers imports from
`@kbn/security-solution-plugin` and `@kbn/test-suites-xpack` in
`osquery` plugin, no code cleanup and updates in other plugins / test
packages.
We expect code owners to update other imports / refactor package to
avoid code duplication
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
## Summary
### What is included?
* Improves the auth dashboard to display system events
* Add data view index patterns as visualisations index
* Move ESQL query generation to a shared folder
* Parse ESQL query and validate if fields exist in the dataview
* Rewrite the ESQL query if a FORK command has missing fields
* Add a visualisation warning message when there is no valid FORK branch
### Pros
* To be able to render parts of the query depending on whether indices
or fields exist in the cluster
* The queries become much easier to read, maintain and fix
### Cons
* We need to test the performance
* FORK is in tech preview
* The commands we can use in a fork are limited to “WHERE, LIMIT, SORT,
EVAL, STATS, DISSECT”
### How to test it?
* Open the dashboard without privmon data, some of the visualisations
should display the warning message
* Add privmon data, the visualisation should display the data
(https://github.com/elastic/security-documents-generator/pull/163)
* Check if the visualisation displays the correct data.
* To test if the FORK rewrite logic is working, I update the queries on
my local environment to use a non-existent field and update the page.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] 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)
- [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
- [ ] 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
Objective: avoid exposing the entire API surface area of `HttpService`
(and it's internal preboot/setup/start contracts) to test code outside
core.
* Refactor the `createHttpService -> createInternalHttpService` mock
test helper moved to scoped folder
`./src/core/server/integration_tests/utilities`
* Create an "integration test ready" version of the original
`createHttpService` for plugins to use from
`@kbn/core-http-server-mocks`
* Clean up some types
* Refactor the 2 plugin test usages of the internal `HttpService`
### Notes
* We have been exposing this surface area already in
`src/core/packages/http/server-mocks/src/http_service.mock.ts`. But it
seems to not have a adoption outside Core code... I wonder if we need a
concept of `mock-internal`?
* I don't think this is a **massive** issue, I just happened to realise
this when [messing
around](https://github.com/elastic/kibana/pull/222956) with an
`HttpService` related refactor. Would be nice to not leak more
information about internal code than necessary (it's clearly too late
for that, but maybe we can improve the situation for HttpService a bit).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
When checking the Overview cluster, I noticed that we previously had
`labels.error_type` in APM. In this PR, I changed the label that I've
added in the following PRs for fatal react errors and toast errors to
use `labels.error_type` instead of `labels.errorType` for consistency.
- Toast error: https://github.com/elastic/kibana/pull/217948
- Fatal react error: https://github.com/elastic/kibana/pull/218846
## Summary
Prior to this change, with data view manager feature flag enabled, we
would only see the "expand" cell action in the alerts. Now,
all the actions should be visible. This was because cell actions
rendering was unintentinally omitted in the initial batch of changes
that added data view sourcing from the new store / hooks.
fixes https://github.com/elastic/security-team/issues/12853
### Testing
```
xpack.securitySolution.enableExperimental: ['newDataViewPickerEnabled']
```
then navigate to alerts page, hovering on timeline cell for example
should render full set of hover actions.
### 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
## Summary
Filters we applied but no listed in the timeline, again - some mismatch
in how the data view object was passed around.
## Testing
Set the feature flag:
```
xpack.securitySolution.enableExperimental: ['newDataViewPickerEnabled']
```
Then, adding a filter via cell action should render the correct pill in
the top level filters pane.
### Checklist
Check the PR satisfies following conditions.
- [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
## Summary
Recently, an alarm was fired in the Kibana Serverless Slack Channel due
a problem with Data Usage. Issue explanation:
> Kibana's data_usage plugin allows collecting misc stats about Kibana
usage.
> The browser side performs requests to /internal/api/data_usage/*,
providing stats related to the user interaction with the UI.
> Recently, in an internal customer project, on production, one of these
requests (POST /internal/api/data_usage/metrics) contained a payload
that was deemed invalid by the server-side validation logic.
>
> The handler on that endpoint logged an error message.
> This error message was spotted by a Rule.
> Consequently, the rule fired an alert in our Slack channel.
>
> We shouldn't have invalid payloads coming from browser side, so unless
someone intentionally tampered with the HTTP request, this indicates a
bug in our browser-side logic.
> Customer Impact: This was an isolated error on an internal project,
but other folks within Elastic have spotted the same error message in
their projects. Due to that error, we might be missing a few data_usage
metrics.
The issue was caused because the plugin validation was waiting for an
array for the data property, but the payload from the API was returning
`null`. The validation was incorrect in the Kibana side since only
[name](https://github.com/elastic/autoops-services/blob/master/monitoring/service/specs/serverless_project_metrics_api.yaml#L189)
is mandatory.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR is for a feature branch that is being merged into main.
The relevant PRs are:
- https://github.com/elastic/kibana/pull/219211
- https://github.com/elastic/kibana/pull/222820
- https://github.com/elastic/kibana/pull/223241
- https://github.com/elastic/kibana/pull/224388
- https://github.com/elastic/kibana/pull/224682
## Summary
This PR adds 4 new indexes with case analytics data, which are created
when the cases plugin starts.
- `.internal.cases`
- `.internal.cases-comments`
- `.internal.cases-attachments`
- `.internal.cases-activity`
After the indexes are created, a backfill task for each of them is
scheduled to run 1 minute after creation. This task populates the
indexes with relevant data from `.kibana_alerting_cases`.
A second type of task is registered, the index synchronization task.
Four of these tasks, one for each index, are scheduled to run every 5
minutes. The synchronization tasks populated the indexes with data from
`.kibana_alerting_cases` that was created or updated in the last five
minutes.
## How to test
You might want to start Kibana with `--verbose` to see relevant index
messages in the console.
Alternatively(what I normally do), is go to `analytics_index.ts`,
`backfill_task_runner.ts`, and `synchronization_task_runner.ts`, and
change the `logDebug` function to call `this.logger.info` instead. This
way, you will have less spam in the console.
Every log message starts with the index name between square brackets, so
you can look for `[.internal.cases-` and follow what is happening.
1. You should have some existing case data, so before anything else,
please create some activity, attachments, etc.
2. Add `xpack.cases.analytics.index.enabled: true` to `kibana.dev.yml`
and restart Kibana.
3. Check out [this
branch](https://github.com/elastic/elasticsearch/pull/129414) from the
ES project.
4. Start Elastic Search with `yarn es source`. This will use the above
version of Elasticsearch.
5. Wait a bit for the indexes to be created and populated(backfilled).
6. Using the dev tools:
- Confirm the indexes exist.
- Check the index mapping. Does it match the one in the code? Is the
`_meta` field correct?
-
`x-pack/platform/plugins/shared/cases/server/cases_analytics/******_index/mappings.ts`
- Check that the painless scripts match the code.
-
`x-pack/platform/plugins/shared/cases/server/cases_analytics/******_index/painless_scripts.ts`
- Confirm your existing case data is in the indexes. (See **Queries**
section below.)
7. Play around with cases. Some examples:
- Create a case
- Change status/severity
- Attach alerts
- Add files
- Change category/tags
- Add comments
- etc
8. Go to the dev tools again and confirm all this shows up in the
relevant indexes. (See **Queries** section below.)
## Queries
In addition to the ones, below I have a few more. Things like reindexing
with specific scripts or fetching relevant data from
`.kibana_alerting_cases`. Ping me if you want those queries.
### Checking index content
```
GET /.internal.cases/_search
GET /.internal.cases-comments/_search
GET /.internal.cases-attachments/_search
GET /.internal.cases-activity/_search
```
### Checking index mappings
```
GET /.internal.cases
GET /.internal.cases-comments
GET /.internal.cases-attachments
GET /.internal.cases-activity
```
### Fetching the painless scripts
```
GET /_scripts/cai_cases_script_1
GET /_scripts/cai_attachments_script_1
GET /_scripts/cai_comments_script_1
GET /_scripts/cai_activity_script_1
```
### Emptying the indexes
It is sometimes useful for testing.
```
POST /.internal.cases/_delete_by_query
POST /.internal.cases-comments/_delete_by_query
POST /.internal.cases-attachments/_delete_by_query
POST /.internal.cases-activity/_delete_by_query
```
### Deleting the indexes
It is sometimes useful for testing.
```
DELETE /.internal.cases
DELETE /.internal.cases-comments
DELETE /.internal.cases-attachments
DELETE /.internal.cases-activity
```
## Release notes
Four dedicated case analytics indexes were created, allowing users to
build dashboards and metrics over case data. These indexes are created
on Kibana startup and updated periodically with cases, comments,
attachments, and activity data.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
## Summary
Issue reported by users that some unenrolled agents on the UI are not
being deleted by the background task.
The cause turned out to be a discrepancy in how unenrolled agents are
determined on the UI versus the background task.
The UI shows agents as unenrolled if `active:false` field matches (logic
[here](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/shared/fleet/server/services/agents/build_status_runtime_field.ts#L115-L119))
The delete unenrolled agents task also queried on the existence of
`unenrolled_at` field.
It seems some agents don't have this field set, those should be deleted
too.
Integrating latest translations extracted from main branch.
Skipping backports from main to target branches since the `i18n_check`
might trim unused translations that are still used in different
branches. Integration script is ran against each target branch
separately.
## Summary
This PR customized Discover's Security Root Profile with 3 new changes.
\
With this change Discover's Security profile ceases to be
`experimental`. Below are the changes listed one in this profile.
>[!Note]
> This change also removes the Flyout changes that were added for
security solution to the Discover's security profile.
### Row Indicators.
Adds row indicators based on Alert or an event as shown in the
screenshot below. Note the highlights on the left of the row.
`Yellow` for Alerts.
`Gray` for Events.
### Default list of Columns.
Adds the list of default columns that should appear when security
profile is activated.
### Explore in Security Flyout.
As shown the demo below, this action explores and event or an alert in
security solution as shown in the screenshot below.
https://github.com/user-attachments/assets/4c228bb1-60af-433b-8e8f-1a5d4d049985
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] 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/packages/kbn-i18n/README.md)
- [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
### 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Davis McPhee <davis.mcphee@elastic.co>
## Summary
This PR fixes some code paths/requests for calculating Duration
histograms and Trace summaries to account for unprocessed OTEL data. It
isn't the nicest way of doing things, because deep in APM, there is of
course an assumption that data is being dealt with in ECS format.
Probably longer term, this should be refactored, but this at least adds
in support for unprocessed OTEL for the duration widget.
Related to #221521
## How to test
* Add the following to your `kibana.dev.yml` file:
```yaml
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
* Set up a source of unprocessed OTEL data to feed into ES (Open
telemetry demo, etc)
* Set your space to Observability mode, and go to Discover.
* Query for `traces-*` and open any record for the document viewer
* The Span Overview waterfall should show the duration histogram that
match the document's formatted duration in the Table/JSON tabs, as well
as the trace summary information (trace id & span name)
---------
Co-authored-by: Milosz Marcinkowski <38698566+miloszmarcinkowski@users.noreply.github.com>
Closes: https://github.com/elastic/kibana/issues/220954
`fleet/remote_synced_integrations/<output-id>/remote_status` includes
non-http request errors in the error field of the status response for
improved client handling.
## Summary
Resolves#222051.
This PR makes a richer empty state UX for the Investigation Guide
feature we added to the Alert Details page.
Before, when a rule did not have an investigation guide, the tab on the
alert details page dedicated to the feature was disabled. Now, the tab
is always enabled. When an investigation guide is present on a rule, a
badge will display to indicate the tab contains content.
If the user clicks into the tab when the rule does not have an
investigation guide, they will see an empty state with a call to action
to create a guide. If the user decides to click the empty state button,
it will open the Rule Edit flyout. I have added additional functionality
that allows the flyout to take an `initialStep` prop, so we pre-set the
flyout to the `Details` step which contains the text field the user can
use to create their guide.
The copy, iconography, and layout of the tab heading are all in draft
state pending some design feedback. I will also add some tests to the
code that I have added.
## Reviewing this PR
_Note to technical writers:_ You can see the copy added for the empty
state
[here](https://github.com/elastic/kibana/pull/223974/files#diff-71b439414e4974e2decb0f25c136f52ccea4b49ebe393af68dfc5fd184d56e1cR37).
Here's a screenshot as well:
<img width="375" alt="image"
src="https://github.com/user-attachments/assets/491d87ac-b473-484e-82cd-45a1bd197c61"
/>
### Technical review
1. Create a rule that will generate alerts; _do not_ define an
Investigation Guide for it
1. Trigger an alert, and go to the details page
1. You should see the Investigation guide tab is available, whereas on
`main` it would be disabled
1. Open the Investigation Guide tab, you should see the empty state with
its CTA
1. Click this button, the rule flyout should open in Edit mode, and the
Details step should be pre-selected
1. Define an investigation guide, this can be any text. Save the rule.
1. Once you have saved the rule you should see the rule data update in
the page. The empty state will be gone and the investigation guide you
defined will be there instead.
## Summary 🌷
Resolves https://github.com/elastic/observability-dev/issues/4568
### Test Now flyout
Checked this by throwing an error within the flyout:
<img width="1584" alt="image"
src="https://github.com/user-attachments/assets/d8cfe96e-8b1b-4c28-819e-82411b5f20af"
/>
### Monitor detail flyout
In the case of this flyout, IMO, we should not use an error boundary. We
are receiving an error that has been caught and placed into the plugin's
Redux store, and then selecting that as part of the render procedure of
this component. Thus, we should display it using `EuiCallout`, which is
the recommended course per [the
docs](https://eui.elastic.co/docs/patterns/error-messages/error-banners/).
Example implementation below:
_note:_ all the copy here is placeholder and we should run it by our
tech writers.
<img width="607" alt="image"
src="https://github.com/user-attachments/assets/ef60258e-e50e-4fa7-adc5-b77469ddc0fb"
/>
We should not use an error boundary, as they are there specifically to
handle unforeseen errors that we can't account for at development time.
In this case, we have already caught the error and persisted it in app
state, so I don't think it's appropriate to display it in an error
boundary as the runtime is still progressing and is not broken.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes tab selection issue when user opens alert details page from
"Related alerts" tab. In this case, "Overview" tab should be selected by
default. In other cases, tab Id passed from URL should be used otherwise
default to "Overview".
## Summary
- Adds configuration for the product intercept in `oblt`, `es` and
`security` serverless offerings, alongsides stateful offering too. The
configuration provided sets the intercept to display every 90days, this
is configurable through the config `xpack.product_intercept.interval`.
The intercept can also be turned off through the config
`xpack.product_intercept.enabled`
- Also tweaks prompter timer implementation to accommodate inherent
[issue with long timer
delays](https://developer.mozilla.org/en-US/docs/Web/API/Window/setTimeout#maximum_delay_value)
in the browser
- Adjusts the signature of the `registerIntercept` method, such that a
deferred value to be evaluated when the intercept is to be displayed is
passed. This unlocks the ability to have consumers provide dynamically
imported modules that provide the config for the intercept, see
0e07892217
for an example.
### How to test
- Add the following config to your `kibana.dev.yml` file;
```yml
xpack.product_intercept.enabled: true
# we set the interval to 30s so the wait long period to display the
intercept is bearable
xpack.product_intercept.interval: '30s'
```
- Start kibana in stateful, and serverless mode, in either scenario you
should be presented the product intercept, with the intercept
specifically stating the current product the user is interacting with.
See below for an example of observability solution;
https://github.com/user-attachments/assets/6ca6baf2-58d3-4002-ac94-ec6e9a0902ae
<!--
### 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)
- [ ] 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
- [ ] 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
-->
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/222104
## Summary
Adds optional flag when registering a rule type for "dangerously
creating alerts in all spaces". If a rule type opts into this flag,
alerts created during rule execution will persist the `kibana.space_ids`
field as `"*"` instead of the space ID of the rule. Note that we store
`kibana.space_ids` as a string array, so the final alert document will
have
```
'kibana.space_ids': ['*']
```
This PR just adds the flag and updates the code to respect the flag. It
does not opt any rule types into using it. You can look at the
functional tests to see example test rule types that use it.
Because the streams rule type that we expect to be the first user of
this flag uses the `persistenceRuleTypeWrapper` in the rule registry for
writing alerts, we also had to update the rule registry code.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Addresses a bug with the `ConnectorTokenClient` when using the
`UnsecuredActionClient` to execute actions directly (vs enqueuing a task
for execution). We previous pass in an internal saved objects repository
(that doesn't require a user request) to the `ConnectorTokenClient` when
using the `UnsecuredActionsClient` but this does not create the
`connector_token` saved object correctly so the next time it's read, we
get a `Failed to decrypt attribute` error.
This only occurs when using the `sendAttachmentEmail` with the MS
Exchange connector function added in this PR:
https://github.com/elastic/kibana/pull/219164. It does not affect the
other email service methods.
## To Verify
1. Ask me for MS Exchange credentials
2. Add this to your Kibana config:
```
xpack.actions.preconfigured:
test-exchange-email:
name: preconfigured-exchange-email
actionTypeId: .email
config:
service: exchange_server
clientId: <clientId>
tenantId: <tenantId>
from: <from>
secrets:
clientSecret: <secret>
notifications.connectors.default.email: test-exchange-email
```
3. Make this change to the code so Kibana sends 2 emails when it starts
up:
```
--- a/x-pack/platform/plugins/shared/notifications/server/plugin.ts
+++ b/x-pack/platform/plugins/shared/notifications/server/plugin.ts
@@ -40,6 +40,27 @@ export class NotificationsPlugin
public start(_core: CoreStart, plugins: NotificationsServerStartDependencies) {
const emailStartContract = this.emailServiceProvider.start(plugins);
+ const emailService = emailStartContract.getEmailService();
+ emailService
+ .sendAttachmentEmail({
+ to: ['<email>'],
+ subject: 'yo',
+ message: 'i am here',
+ attachments: [],
+ spaceId: 'default',
+ })
+ .then(() => {
+ new Promise((resolve) => setTimeout(resolve, 5000)).then(() => {
+ emailService.sendAttachmentEmail({
+ to: ['<email>'],
+ subject: 'yo',
+ message: 'i am here again',
+ attachments: [],
+ spaceId: 'default',
+ });
+ });
+ });
+
return {
```
4. Verify there are no decryption errors for the `connector_token` SO
logged and that the emails are sent successfully.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This is a farewell PR to Cases. Probably my last PR to the cases
codebase. It was quite a journey, and I learned a lot. I hope the best
for the feature of Cases.
## Decisions
Just before Cases was forbidden to do migrations, we did a last
migration to all cases to persist `total_alerts: -1` and
`total_comments: -1`. We did that so that in the future, when we would
want to populate the fields, we would know which cases have their fields
populated and which do not. In this PR, due to time constraints and
criticality of the feature, I took the following decisions:
- Cases return from their APIs the total comments and alerts of each
case. They do that by doing an aggregation, getting the counts, and
merging them with the response. I did not change that behavior. In
following PRs, it can be optimized and fetch the stats only for cases
that do not yet have their stats populated (cases with -1 in the counts)
- When a case is created, the counts are zero.
- When a comment or alert is added, I do an aggregation to get the stats
(total alerts and comments) of the current case, and then update the
counters with the number of the newly created attachments. The case is
updated without version checks. In race conditions, where an attachment
is being added before updating the case, the numbers could be off. This
is a deliberate choice. It can be fixed later with retries and version
concurrency control.
- The case service will continue to not return the `total_alerts` and
`total_comments`.
- The case service will accept the `total_alerts` and `total_comments`
attributes to be able to set them.
Fixes: https://github.com/elastic/kibana/issues/217636
cc @michaelolo24
### 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
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [papaparse](https://www.papaparse.com/)
([source](https://redirect.github.com/mholt/PapaParse)) | dependencies |
patch | [`^5.5.2` ->
`^5.5.3`](https://renovatebot.com/diffs/npm/papaparse/5.5.2/5.5.3) |
---
### Release Notes
<details>
<summary>mholt/PapaParse (papaparse)</summary>
###
[`v5.5.3`](e3c7b2628c...a4f8b0f1e3)
[Compare
Source](e3c7b2628c...a4f8b0f1e3)
</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:eyJjcmVhdGVkSW5WZXIiOiIzNy40MjUuMSIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOiBTZWN1cml0eVNvbHV0aW9uIiwiYmFja3BvcnQ6YWxsLW9wZW4iLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Marshall Main <55718608+marshallmain@users.noreply.github.com>
## Rule gaps callout
### Summary
This PR introduces a new callout on the **Rules** page and improves the
**Gaps** panel with clearer metrics and filtering logic to enhance the
user experience when managing gap filling.
---
### Key Changes
1. **Rules Page – Callout for Recent Gaps**
- A dismissible callout is displayed if there are any unfilled gaps in
the **last 24 hours**.
- The callout includes:
- A link to the Gaps dashboard.
- A link to relevant documentation.
- Once dismissed, the callout won’t reappear for 24 hours **unless** new
gaps are detected during that time.
2. **Gaps Panel – Rule Count Display**
- Displays two separate counts:
- The **number of rules with unfilled gaps**.
- The **number of rules currently in progress** (gaps are being filled).
- Provides users with a quick overview of the current gap state.
3. **Filtering Logic**
- The filter now only shows **rules with unfilled gaps that can still be
filled**.
- Example: If 5 rules had unfilled gaps and filling started for 3, the
filtered list will only show the remaining 2.
**Note**: we don't immediately update number for rules with gap
"in-progress", because gap update async and can happen after bulk
request if finished.
https://github.com/user-attachments/assets/3c913129-16c3-449a-9847-a01e2657e9aa
### How to test
Enable FF `storeGapsInEventLogEnabled`.
[Use this tool to create a lot of rules with/without
gaps](https://github.com/elastic/security-documents-generator)
```
// will create 100 without gaps, and 5 minute interval
yarn start rules --rules 100 -g 0 -c -i "5m" -f 1
```
Alternatively you can create a rule with small interval (1m) and
lookback time(1s). Enable rule, wait for completion and then disable it.
Wait 5m (> 4x interval). Then enable it and rule should fail and
generate gap.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- Moved `search_navigation` to `plugins` root
- `search_navigation` being inside the search_solution folder was a
pre-cursor to the solutions/search migration. The introduction of the
solutions/search folder made the search_solution folder redundant,
therefore this migrates the search_navigation plugin up with all the
other search plugins.
- Moved the base classic nav items list to the search_navigation plugin.
The classic nav items are now a static list and can be servered from the
search_navigation plugin instead of being shared from
`enterprise_search`. This is mainly a devx improvement to allow all
search related navigation changes to eventually be maintained in the
search navigation plugin.
### Checklist
- [x] 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Changes are in support of space awareness:
- Updated response action service utility for retrieving action requests
(list) so that response actions with a tag of
`INTEGRATION-POLICY-DELETED` will be returned when in a space that
matches the space defined in the `ORPHAN-RESPONSE-ACTIONS-SPACE` ref.
data key
- Updated response action service utility that retrieve a single action
to allow returning an action request with tag
`INTEGRATION-POLICY-DELETED` if the active space matches the space
defined in `ORPHAN-RESPONSE-ACTIONS-SPACE` ref. data key
- `ensureActionRequestsIndexIsConfigured()` was adjusted to be more
robust at checking index for missing mappings
## Summary
This PR changes the "soft delete" mechanism in the CSV upload to use
scripted updates.
There were 2 main reasons for this:
1. We need to check if a privileged user has been added from some other
data source
In this case, not including the user in the CSV upload shouldn't delete
it, instead only remove the `"csv"` source label.
2. The soft delete needs to take into account the full list of users
being uploaded, and not only the current batch
This means we need to collapse the stream first and then run the soft
delete logic. Doing this allows the soft delete to search the Privmon
index for all users not included in the full csv file
## How to test
#### Prerequisite
Make sure you have a CSV file with usernames
Check
[here](https://gist.github.com/tiansivive/0be2f09e1bb380fdde6609a131e929ed)
for a little helper script
Create a few copies where some of the users are deleted, in order to
test soft delete.
Make sure to create files that are over the batch size (`100`) or change
the batch size in the code.
1. Start up kibana and ES
2. Navigate to Security > Entity Analytics > Privilege User Monitoring
3. Select the `File` option to add data
4. Add one of the CSV files to the open modal and upload
5. Repeat but now upload one of files with the omitted users
Alternatively, testing only the backend only is possible by directly
hitting the API wit curl
```sh
curl -u elastic:changeme \
-X POST "http://localhost:5601/api/entity_analytics/monitoring/users/_csv" \
-H "kbn-xsrf: true" \
-F "file=@test.csv;type=text/csv"
```
#### Verifying
Easiest way is to use the dev tools to `_search` the privmon users index
with:
```
GET .entity_analytics.monitoring.users-default/_search
```
Look for number of hits and/or use `query` to search for omitted users
like:
```json
{
"query": {
"bool": {
"must": [
{ "term": { "labels.monitoring.privileged_users": "deleted" } }
]
}
}
}
```
Verify that the `"deleted"` users are _only_ the ones missing from the
last uploaded file.
## Summary
This PR introduces Fleet’s agent space awareness to the Osquery plugin.
The primary goal is to ensure that agents, policies, packs, and queries
remain isolated to their respective Kibana spaces. Specifically:
1. Agents enrolled in policy A (belonging to Space A) are not accessible
from Space B—live queries cannot be performed on them from other spaces.
2. Packs created in Space A are not visible in Space B.
3. Saved queries created in Space A are not visible in Space B.
4. Agent policies, agents, and space-exclusive operating systems from
Space A are not visible from Space B.
5. Live query history is only visible in a space if it includes agents
from that space.
## Implementation Details
- All usages of the Saved Object Client have been updated to use the
space-aware SO client, ensuring queries only return results from the
current space.
- When creating live queries, we now add a `space_id` field to
`.logs-osquery_manager.actions-default` documents. This field stores the
integration policy (osquery_manager) IDs of the agents involved in each
query.
- When reading live queries, searches are filtered to include only
documents with `policy_ids` that are present in the current space.
This ensures strict separation of Osquery data and actions across
different spaces.
## Feature Flag Considerations
At this stage, we believe no feature flag or gating is necessary. In all
cases, we default to the `default` space ID. We have tested these
changes with the feature flag turned off and observed the following:
| Scenario | Result |
|------------------------------------------------------|:-----------:|
| Agents and policies are visible in the Live query UI |
✅ |
| Users can query different agents/policies | ✅ |
| Live queries are saved in the live query history | ✅
|
| Users can create both packs and saved queries | ✅ |
| Users can run packs and saved queries | ✅ |
| Users can enable packs for interval execution | ✅ |
Based on these results, we conclude that this PR can be safely merged
without enabling the feature flag, as it does not impact current
operations.
**The index mappings for `.logs-osquery_manager.actions-default` will be
updated to introduce the `policy_ids` field. This field will also be
populated when actions are created. This change is fully backward
compatible and does not introduce any breaking changes.**
### Enable feature flags
```yaml
xpack.securitySolution.enableExperimental:
- endpointManagementSpaceAwarenessEnabled
xpack.fleet.enableExperimental:
- useSpaceAwareness
```
### Switch Fleet to Space aware
```http request
POST /internal/fleet/enable_space_awareness
Elastic-Api-Version: 1,
```
## Manual Test Cases for Space Awareness (Feature Enabled)
### Setup
- **Space A:** Policies `PolicyA1`, `PolicyA2`, `PolicyAB` (each with an
enrolled agent)
- **Space B:** Policies `PolicyB1`, `PolicyB2`, `PolicyAB` (each with an
enrolled agent)
- `PolicyAB` is present in both spaces
---
### 1. Agent Visibility
| Test Step | Expected Result | Pass |
|---------------------------------------------------------------------------|------------------------------------------------------|----------|
| In Space A, view the list of agents and policies | Only agents for
`PolicyA1`, `PolicyA2`, `PolicyAB` are visible | ✅ |
| In Space B, view the list of agents and policies | Only agents for
`PolicyB1`, `PolicyB2`, `PolicyAB` are visible | ✅ |
| `PolicyAB`'s agents are visible in both spaces | Agents enrolled in
`PolicyAB` are visible in both spaces | ✅ |
---
### 2. Live Query Permissions
| Test Step | Expected Result | Pass |
|---------------------------------------------------------------------------|------------------------------------------------------|----------|
| In Space A, attempt a live query on an agent from `PolicyB1` or
`PolicyB2`| Agent is not available for selection/query |
✅ |
| In Space B, attempt a live query on an agent from `PolicyA1` or
`PolicyA2`| Agent is not available for selection/query |
✅ |
| In either space, perform a live query on an agent from `PolicyAB` |
Query is allowed and succeeds | ✅ |
| In Space A, attempt a live query on an agent from `PolicyA1` or
`PolicyA2`| Query is allowed and succeeds | ✅ |
| In Space B, attempt a live query on an agent from `PolicyB1` or
`PolicyB2`| Query is allowed and succeeds | ✅ |
---
### 3. Packs and Saved Queries
| Test Step | Expected Result | Pass |
|---------------------------------------------------------------------------|------------------------------------------------------|----------|
| In Space A, create a pack and a saved query | Only visible in Space A
| ✅ |
| In Space B, create a pack and a saved query | Only visible in Space B
| ✅ |
| In Space A, check for packs/queries created in Space B | Not visible |
✅ |
| In Space B, check for packs/queries created in Space A | Not visible |
✅ |
| In Space A, live query a pack that has Agent A and Agent AB. | In
space B user doesnt see results from Agent A | ✅ |
---
### 4. Live Query History
| Test Step | Expected Result | Pass |
|---------------------------------------------------------------------------|------------------------------------------------------|----------|
| In Space A, view live query history | Only queries involving agents
from Space A (including `PolicyAB`) are visible | ✅ |
| In Space B, view live query history | Only queries involving agents
from Space B (including `PolicyAB`) are visible | ✅ |
---
### 5. Pack Execution
| Test Step | Expected Result | Pass |
|---------------------------------------------------------------------------|------------------------------------------------------|----------|
| In Space A, run a pack on agents from `PolicyA1`, `PolicyA2`,
`PolicyAB` | Execution succeeds | ✅ |
| In Space B, run a pack on agents from `PolicyB1`, `PolicyB2`,
`PolicyAB` | Execution succeeds | ✅ |
| Attempt to run a pack on an agent from another space | Not possible;
agent not available for selection | ✅ |
---
### 6. Interval Execution of Packs
| Test Step | Expected Result | Pass |
|---------------------------------------------------------------------------|------------------------------------------------------|----------|
| In Space A, enable interval execution for a pack | Only
agents/policies in Space A are affected | ✅ |
| In Space B, enable interval execution for a pack | Only
agents/policies in Space B are affected | ✅ |
closes https://github.com/elastic/kibana/pull/222935
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
> [!TIP]
> looks huge, but
> - 5,402 lines snapshot tests
> - 714 lines yaml files
## Summary
This PR adds a new feature version `siemV3` with the required role
migrations, in order to enable the new privilege
`global_artifact_management_all` for users where needed.
### What's in the PR?
- Required changes around security role migration from `siemV2` to
`siemV3`
- Improvements by parameterizing `siemV3` in lots of places, to ease
future role migrations by decreasing the occurrences that have to be
changed.
- A new function called `baseFeatureConfigModifier()` in
`ProductFeaturesConfig`: now product features have the ability to modify
the base Kibana feature. de05a3b167
- Product feature `endpointArtifactManagement` is split to
ESS/Serverless counterparts, and adds role migrations to the base Kibana
config using `baseFeatureConfigModifier()`
(1c31f56b43). This solves 2 problems:
- Different migrations are needed for ESS and Serverless.
- The product feature `endpointArtifactManagement`, and hence the
privilege `global_artifact_management_all` is not available on all
serverless tiers (see [these
fails](https://buildkite.com/elastic/kibana-pull-request/builds/310534/summary/annotations?jid=019788c8-d03e-44e7-867f-ff1557f9e894#019788c8-d03e-44e7-867f-ff1557f9e894/256-4872)),
therefore the migration needed to be separated from the base Kibana
feature config.
- (note: these changes were safeguarded by the role migration tests and
snapshot tests)
- Security / **Global Artifact Management** [space awareness]:
- moves the sub-privilege out of feature flag, in order to be able to
target it for role migrations
- adds a 'Coming soon' test to the privilege
- `endpointManagementSpaceAwarenessEnabled:false`
<img width="500" alt="image"
src="https://github.com/user-attachments/assets/fdfd5fc7-7f7d-4210-96c9-09e2357530c0"
/>
- `endpointManagementSpaceAwarenessEnabled:true`
<img width="500" alt="image"
src="https://github.com/user-attachments/assets/f8361a4c-da6e-416c-b728-5788eb1a053e"
/>
- role migration is added: in short, any artifact ALL privilege causes
the new Global Artifact Management ALL privilege to be added
(https://github.com/elastic/security-team/issues/11717)
- predefined roles are updated locally
(note: in elasticsearch-controller, it'll be updated after this PR is
merged and deployed,
https://github.com/elastic/elasticsearch-controller/pull/1010)
- tests!
- testing the migration itself: b8d90d085f
and 309abb30a8
- snapshot test with deprecated features:
https://github.com/elastic/kibana/pull/219566/files#diff-ed11536475a7a6f0a835cbc950c3b7405093058ad42bab30cf06f41ed21561a3
- some functional tests enabled for deprecated features:
4b4f49ea3d
## Global Artifact Management role migrations
```mermaid
flowchart LR
subgraph siemV2[siem/siemV2]
none1[none]
end
subgraph siemV3
none2[none]
end
none1 --> none2
```
```mermaid
flowchart LR
subgraph siemV2[siem/siemV2]
read1[read]
end
subgraph siemV3
read2[read]
end
read1 --> read2
```
```mermaid
flowchart LR
classDef serverless stroke:blue,stroke-dasharray: 5 5
subgraph siemV2[siem/siemV2]
subgraph minread1[minimal_read]
minread1_subs["`trusted_applications_read
event_filters_read
blocklist_read
host_isolation_exceptions_read`"]
minall1_subs["`trusted_applications_all
event_filters_all
blocklist_all
host_isolation_exceptions_all`"]
eer1["`endpoint_exceptions_read
(only serverless)`"]:::serverless
eea1["`endpoint_exceptions_all
(only serverless)`"]:::serverless
end
end
subgraph siemV3
subgraph minread2[minimal_read]
minread2_subs["`trusted_applications_read
event_filters_read
blocklist_read
host_isolation_exceptions_read`"]
minall2_subs["`trusted_applications_all
event_filters_all
blocklist_all
host_isolation_exceptions_all`"]
eer2["`endpoint_exceptions_read
(only serverless)`"]:::serverless
eea2["`endpoint_exceptions_all
(only serverless)`"]:::serverless
g2[global_artifact_management_all]
end
end
minread1 --> minread2
minread1_subs -->|each to his own| minread2_subs
minall1_subs -->|global for any of these| g2
minall1_subs -->|each to his own| minall2_subs
eer1 -->|only serverless| eer2
eea1 -->|only serverless| eea2
eea1 -->|only serverless| g2
linkStyle 4,5,6 stroke:#00f,color:blue
```
notes for above:
- `global_artifact_management_all` have to be added for **any** artifact
write privilege (trusted apps, event filters, blocklists, host isolation
exceptions)
- on serverless, there is a separate endpoint exceptions privilege, it
counts as an artifact
```mermaid
flowchart LR
subgraph siemV2[siem/siemV2]
all1[all]
end
subgraph siemV3
subgraph minall2[minimal_all]
g1[global_artifact_management_all]
end
end
all1 -->|keep access to the included Endpoint Exceptions ALL| g1
all1 -->|enable sub-feature toggle| minall2
```
notes for above:
both on serverless and ESS, Endpoint Exceptions are included in ALL,
hence the migration
> [!note]
> `siem` sub-privileges are not included in READ/ALL parent privileges.
The user needs to enable them one-by-one after enabling the sub-feature
privileges toggle. So Endpoint Exception here is an exception. In any
sense of the word.
```mermaid
flowchart LR
classDef serverless stroke:blue,stroke-dasharray: 5 5
subgraph siemV2[siem/siemV2]
subgraph minall1[minimal_all]
minread1_subs["`trusted_applications_read
event_filters_read
blocklist_read
host_isolation_exceptions_read`"]
minall1_subs["`trusted_applications_all
event_filters_all
blocklist_all
host_isolation_exceptions_all`"]
eer1["`endpoint_exceptions_read
(only serverless)`"]:::serverless
eea1["`endpoint_exceptions_all
(only serverless)`"]:::serverless
end
end
subgraph siemV3
subgraph minall2[minimal_all]
minread2_subs["`trusted_applications_read
event_filters_read
blocklist_read
host_isolation_exceptions_read`"]
minall2_subs["`trusted_applications_all
event_filters_all
blocklist_all
host_isolation_exceptions_all`"]
g2[global_artifact_management_all]
eer2["`endpoint_exceptions_read
(only serverless)`"]:::serverless
eea2["`endpoint_exceptions_all
(only serverless)`"]:::serverless
end
end
minall1 -->|only on ESS to keep access to the included Endpoint Exceptions ALL| g2
minall1 --> minall2
minread1_subs -->|each to his own| minread2_subs
minall1_subs -->|global for any of these| g2
minall1_subs -->|each to his own| minall2_subs
eer1 -->|only serverless| eer2
eea1 -->|only serverless| eea2
eea1 -->|only serverless| g2
linkStyle 5,6,7 stroke:#00f,color:#00f
linkStyle 0 stroke:#0a0,color:#0a0
```
notes for above:
when sub-feature privileges are enabled,
- on ESS endpoint exceptions are still automatically included, that's
why we need to add global access
- on serverless, endpoint exceptions are controlled by the sub-feature
privilege (just like all other artifact privileges, see the note above)
## Background
- Previous role migration PR:
https://github.com/elastic/kibana/pull/201780
- Role migration description:
https://github.com/elastic/kibana/pull/186800
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] 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
- [ ] 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)
After merging [this PR](https://github.com/elastic/kibana/pull/210769)
that updates Playwright to 1.50.1 we started to see failures in
onboarding e2e tests. After an investigation, turns out that playwright
1.50.1 has an issue where `test` CLI command is not exposed and we use
that command to run the tests.
This change updates playwright to 1.53.1 which returns the `test` CLI
command.
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
This PRs builds on top of the [extension point added to the E|QL
editor](https://github.com/elastic/kibana/pull/221474) by registering
recommended ES|QL queries from the Observability plugin.
It registers two recommended queries for logs and two for metrics:
- Kubernetes pods sorted by memory usage
- Kubernetes pods sorted by CPU usage
- Logs with "error" or "warn" messages
- Error occurrences by host name
### Demo - Solution navigation enabled
https://github.com/user-attachments/assets/ca06b89b-5574-4775-8beb-157fa1eaa97a
### Demo - Solution navigation disabled
Only the default recommended ES|QL queries are enabled in this mode.
https://github.com/user-attachments/assets/52043076-6467-44fa-a847-937d3e723afc
## Testing instructions
There is an environment deployed with `/oblt-deploy` that has logs and
metrics (check last month in Discover), you can find the credentials in
the issue posted by the bot in the issue timeline below
For local testing:
- Ingest logs and metrics. This can be done by running a Synthtrace
scenario, e.g. `node scripts/synthtrace.js logs_traces_hosts`
- Enable the Observability solution navigation
- Start writing an ES|QL query targeting indices that match the `logs-*`
or `metrics-*` patterns
## Open questions
- Should the `KQL` command be used in the queries?
Closes https://github.com/elastic/kibana/issues/224027
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Automatically maps ECS fields to Otel semantic conversion.
Mapping logic is pulled from
https://www.elastic.co/guide/en/ecs/master/ecs-otel-alignment-details.html
using
`x-pack/platform/plugins/shared/streams/scripts/extract_otel_mappings.js`
## Testing
The only way to test this logic is to setup an AI connector and use the
"Generate patterns" button.
To setup EIS see email from Dario title "AI for everyone":
1. Run command - `VAULT_ADDR={...} vault login -method oidc`
2. Run command - `node scripts/eis.js` (This will output the config for
the connector which needs to be pasted to kibana.dev.yml)
3. Run Elasticsearch - `yarn es snapshot --license trial -E
xpack.inference.elastic.url=http://localhost:8443`
4. Start Kibana as usual
5. The connector should be visible in the connectors list in Kibana and
in the AI Assistant
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
This PR updates the ES|QL grammars (lexer and parser) to match the
latest version in Elasticsearch.
- The `RERANK` command is in development by Elasticsearch, as such, this
PR comments out and disables `RERANK` tests where necessary to get the
lates grammar changes merged. Kibana will add `RERANK` command support
once it is ready in Elasticsearch.
---------
Co-authored-by: vadimkibana <vadimkibana@gmail.com>
## Summary
Follow up to #210579. Close#193683.
This PR removes the deprecated `visualization:useLegacyTimeAxis`
advanced setting and all related code. This setting was previously used
to enable legacy time axis behavior for charts in Lens, Discover,
Visualize and TSVB, but has been deprecated and is no longer needed. All
usage of the setting was already removed in #210579, this PR just cleans
up the advanced setting itself.
## Changes
- Removed the `visualization:useLegacyTimeAxis` UI setting registration
from the charts plugin
- Removed `LEGACY_TIME_AXIS` constant export from charts common module
- Cleaned up related TypeScript configuration dependencies
- Removed telemetry schema entries for the deprecated setting
- Removed translation strings for the deprecated setting
- Adds a saved object migration to remove the setting (see [advanced
settings
migrations](https://docs.elastic.dev/kibana-dev-docs/tutorials/advanced-settings#registering-migrations))
### Identify risks
- Identified that a saved object migration needs to be added for the
removal of the setting. See this
[PR](https://github.com/elastic/kibana/pull/157699) for reference.
- Advanced settings [can be
overridden](https://www.elastic.co/docs/extend/kibana/ui-settings-service#uisettings-overrides)
in `kibana.yml`. If the setting is present in `kibana.yml` and we remove
support for it, if verification of the file was too strict, it would
fail to start Kibana. I verified that Kibana still starts when support
for the advanced setting was removed but it's still present in
`kibana.yml`.
## Release note
Removal of the deprecated `visualization:useLegacyTimeAxis` advanced
setting.
Closes https://github.com/elastic/kibana/issues/179173.
## Rule type
A dedicated stack rule type was created `datasetQuality.degradedDocs`.
<img width="1759" alt="image"
src="https://github.com/user-attachments/assets/5004a08d-6f12-4f5e-b27f-5f4db242dcf0"
/>
<img width="2318" alt="image"
src="https://github.com/user-attachments/assets/f8b2664a-f1c6-48c5-a617-c6f1b79bf0f7"
/>
This new rule is aggregated by default using `_index` and could be
further configured by the user (e.g. user can also aggregate by
`cloud.provider`).
A new rule type was needed to be created since there is no actual way to
aggregate all documents in a dataStream if we use a DataView like
`logs-*-*`. Inside datasStream documents there is no indication about
the dataStream where they belong to, instead we just have `_index` which
contains backingIndexName instead of actual index.
It's important to note, that this rule type is also visible from
`Observability > Alerts`, which is useful specially for serverless.
https://github.com/user-attachments/assets/000aee51-4895-4f4c-9484-924ace4325c5
## Role Based Access-Control (RBAC)
RBAC for dataset quality alerts is defined within dataQuality kibana
feature.
We have three privileges defined:
1. `all`: This privilege now contains a subFeature `manage_rules` that
will allow for more granularity on alerting level. It's by default
assigned to `all` but can be disabled.
2. `read`: This privilege is only related to serverless (when we don't
have yet custom roles).
https://github.com/user-attachments/assets/70ed5bde-bf45-4024-b448-228799fcaf71
3. `none`: This privilege is only relevant for stateful (in serverless
we don't have custom roles).
## 🎥 Demo
### Serverless
#### `all` privileges
https://github.com/user-attachments/assets/8dad6e30-a261-4a69-979f-6dfc2a41c888
#### `read` privileges
https://github.com/user-attachments/assets/e1cb108d-22a0-4e7f-b252-9cc12d1e9d65
### Stateful
#### `all` privileges
https://github.com/user-attachments/assets/d96f3b70-35b2-466b-aa59-a07190d24d93
#### `all` privileges with subFeature disabled
https://github.com/user-attachments/assets/808ab811-9320-43e4-b2a6-06d530a78b82
#### `none` privileges (Stateful)
https://github.com/user-attachments/assets/18f2a2d6-d825-4713-acea-0d72f451e9ab
## How to test?
1. run synthrace scenario `degraded_logs` in live mode
```
node scripts/synthtrace degraded_logs --live
```
2. Open dataset quality page (/app/management/data/data_quality)
3. Select `synth.3` dataset
(/app/management/data/data_quality/details?pageState=(dataStream:logs-synth.3-default)
4. Click on `Actions` and then select `Create rule`
5. Fill out the alert form
6. Go to `Observability > Alerts` or `Stack management > Alerts`
(/app/observability/alerts)
## Release note
Adds the Create alert rule action to dataset quality page and dataset
quality details. This allows you to generate an alert when the
percentage of degraded docs on the chart crosses a certain threshold.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@elastic.co>
Co-authored-by: Faisal Kanout <faisal.kanout@elastic.co>
## Summary
Adds the ability to register recommended fields per datasource. It
follows the logic [of the recommended queries]
(https://github.com/elastic/kibana/pull/221474).
These fields will get prioritized in the editor. So the fields
prioritization goes like:
- recommended fields from the registry first
- ecs schema second
- everything else
### How to register them
- Use the esql server side registry as described in the aforementioned
PR
- Register the fields like that
```
this.extensionsRegistry.setRecommendedFields(
[
{
name: 'log_level',
pattern: 'logs*', // This field is relevant for any index starting with 'logs...'
},
{
name: 'host.ip.keyword',
pattern: 'logs-apache_error', // This field is specific to 'logs-apache_error'
},
{
name: 'http.request.method',
pattern: 'logs*',
},
],
'oblt'
);
```
You will see that the fields are getting prioritized in the editor
<img width="730" alt="image"
src="https://github.com/user-attachments/assets/c4941579-c04f-4c5f-875d-369355420a3d"
/>
As a bonus: The good thing with the recommended fields is that we are
prioritizing fields that exist in the datasource. So this means that a
solution team can register fields per datasource and not afraid if these
fields do not exist at the instance
### 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
## Details
⚠️ This PR was created by an automated tool. Please review the changes
carefully. ⚠️
Add permissions `pull-requests: write` to the docs-build workflow.
## Why
We want to comment on the PR with the links to modified docs pages.
See https://github.com/elastic/docs-builder/issues/1395 for further
details
## 📓 Summary
Closes#212728
There was already an empty prompt in place when samples are not
available for the simulation; this change makes it clearer that pipeline
changes can be saved, but we can't confirm they'll work correctly.
<img width="3006" alt="Screenshot 2025-06-18 at 12 39 57"
src="https://github.com/user-attachments/assets/c4dc7d4e-7634-4790-a356-b3de07098adb"
/>
Closes https://github.com/elastic/observability-dev/issues/4563
## Summary
This PR updates the Obs AI Assistant system prompt to explicitly inform
the LLM about the presence of anonymized entities (e.g., hashes or
placeholder tokens). The goal is to prevent the LLM from attempting to
interpret or hallucinate the meaning of these anonymized tokens.
What Changed
- Modified the system prompt to include a new instruction:
```txt
Some entities in this conversation (like names, locations, or IDs) have been anonymized using placeholder hashes (e.g., `PER_123`, `LOC_abcd1234`). These tokens should be treated as distinct but semantically unknown entities. Do not try to infer their meaning. Refer to them as-is unless explicitly provided with a description.
```
- This instruction is now included in all prompts sent to the LLM as
part of the chat completion setup when there are anonymization rules.
# Overview
This pull request adds capabilities associated with the [Privileged
Access Detection (PAD) anomaly integration
package](https://www.elastic.co/docs/reference/integrations/pad) as a
first-class-citizen into the Entity Analytics Privileged User Monitoring
feature.
# How to test
- Pull this branch into your local machine
- Ensure that the security experimental flag
`privilegeMonitoringEnabled` has been enabled, for example by setting
`xpack.securitySolution.enableExperimental:
[privilegeMonitoringEnabled]` in your `config/kibana.dev.yml` file
- Start Elasticsearch and Kibana
- From the
[security-documents-generator](https://github.com/elastic/security-documents-generator)
repository, run the following command: `yarn start
privileged-user-monitoring` (ensuring your config is pointing to your
locally running Elastic cluster). This will load "source" events that
are anomalous in nature. You can run this command more than once if
desired to upload more than 10 users.
- Grab the CSV file that the generator created in its console output.
- Open the Entity analytics page and navigate to dashboards (by clicking
"Go to dashboards")
- Add the privileged users from the previous step to the privileged
users index using the CSV File Upload option.
> [!NOTE]
> Any errors regarding risk scoring are unrelated to this PR, and are
being resolved separately
- You should see a panel that says "Enable Privileged access detection".
Click "Install", and you'll meet a loading state.
- Once complete, you shouldn't see any results. That's because, even
though we **install** the ML jobs by default, we don't **run** them by
default.
- Click "ML Job Settings", and note that only `pad` jobs should be
displaying in this callout. Feel free to test this callout's links and
filtering options.
- Click "Run job" next to the job called
`pad_linux_high_count_privileged_process_events_by_user`. This is the
job for which we have anomaly data.
- Click away from the callout. **You still shouldn't see data.** That's
because there just aren't any anomalies "today".
- Change the global date filter at the top of the screen to "Last 30
days".
- You should see something similar to this:
<img width="1441" alt="Screenshot 2025-06-16 at 12 50 25 AM"
src="https://github.com/user-attachments/assets/2b3f11f2-f45d-4716-bb8e-79d2b585aa3e"
/>
- Congrats for making it this far! Some things to play around with:
- Click around on the anomaly filters (i.e., click 25-50), and notice
that the results will change.
- Ensure that the ordering of the users is based on the **highest single
anomaly score in any visible bucket**. Meaning, if user `samwise` has
only one anomaly, but its score is 99, and user `frodo` has dozens of
anomalies, but no higher than, say, 80, `samwise` will be on the top of
the list.
- Click the user names to open the appropriate user flyout
- Change the global time filter to change ranges, and ensure the data
shows up appropriately. The buckets will try to roughly show 30 buckets
total, but will have a maximum of 3 hours, meaning if your range is too
small, it may show fewer than 30 buckets. This is intentional behavior,
as the PAD jobs have an anomaly job window of 3 hours.
- Click the button that says "View all in Anomaly Explorer", which uses
the currently selected global time range, and compare results
> [!WARNING]
> Remember that the users in the privileged user monitoring table are
only those that you designated as privileged users in a previous step.
In contrast, the Anomaly Explorer page shows **all** users.
Additionally, note that there may be very slight differences between the
swimlanes, because ES|QL calculates the bucket dates slightly
differently than the Anomaly Explorer. **This should not affect the
results themselves, only the buckets that an individual anomaly score
might fall in.** You might see a single anomaly fall into one visual
bucket instead of another, but the date should be correct.
# Helpful hints
If you'd like an easy way to "reset" the Privileged Access Detection
package and delete its associated jobs (and anomaly data), so that you
can redo the onboarding flow, you can run the below commands (changing
any credentials as necessary):
```shell
curl "http://localhost:5601/api/fleet/epm/packages/pad/0.5.0" \
-X 'DELETE' \
-H 'elastic-api-version: 2023-10-31' \
-H 'kbn-xsrf:true' \
--user elastic:changeme
curl "http://localhost:5601/internal/ml/jobs/delete_jobs" \
-H 'kbn-xsrf:true' \
--user elastic:changeme \
-X 'POST' \
-H 'elastic-api-version: 1' \
-H 'x-elastic-internal-origin:kibana' \
-H 'Content-Type: application/json' \
--data-raw '{
"jobIds": [
"pad_linux_high_count_privileged_process_events_by_user",
"pad_linux_high_median_process_command_line_entropy_by_user",
"pad_linux_rare_process_executed_by_user",
"pad_okta_high_sum_concurrent_sessions_by_user",
"pad_okta_rare_host_name_by_user",
"pad_okta_rare_region_name_by_user",
"pad_okta_rare_source_ip_by_user",
"pad_okta_spike_in_group_application_assignment_changes",
"pad_okta_spike_in_group_lifecycle_changes",
"pad_okta_spike_in_group_membership_changes",
"pad_okta_spike_in_group_privilege_changes",
"pad_okta_spike_in_user_lifecycle_management_changes",
"pad_windows_high_count_group_management_events",
"pad_windows_high_count_special_logon_events",
"pad_windows_high_count_special_privilege_use_events",
"pad_windows_high_count_user_account_management_events",
"pad_windows_rare_device_by_user",
"pad_windows_rare_group_name_by_user",
"pad_windows_rare_privilege_assigned_to_user",
"pad_windows_rare_region_name_by_user",
"pad_windows_rare_source_ip_by_user"
],
"deleteUserAnnotations": true,
"deleteAlertingRules": false
}
'
```
# What's left?
- This PR does not implement "proactive" permissions checks. Instead,
relevant permission issues will cause requests/queries to fail, which
are appropriately shown in the UI for troubleshooting. This proactive
check will be tackled in [this (private) followup
issue](https://github.com/elastic/security-team/issues/12822).
- There is not yet a way to "upgrade" the package directly from the
Privileged User Monitoring screen. This would be a nice addition later
on, instead of requiring users to navigate to the integration page. This
behavior will be tackled in [this (private) followup
issue](https://github.com/elastic/security-team/issues/12823).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR updates Asset Inventory Grouping and Datagrid functionalities to
accommodate the `asset.criticality` soft delete mechanisms, which sets
the value of `asset.criticality` to "delete" once an entity is manually
"Unassigned" after having a value before:
- Added condition on grouping to treat both "deleted" and "missing
value" as Unassigned.
- Added rendering condition on the datatable to display the Unassigned
badge when `asset.criticality` value is either missing or "deleted".
### Recording
https://github.com/user-attachments/assets/37d7e44f-cb57-4c29-b49d-cda9b341497d
---------
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [form-data](https://redirect.github.com/form-data/form-data) |
devDependencies | patch | [`^4.0.2` ->
`^4.0.3`](https://renovatebot.com/diffs/npm/form-data/4.0.2/4.0.3) |
---
### Release Notes
<details>
<summary>form-data/form-data (form-data)</summary>
###
[`v4.0.3`](https://redirect.github.com/form-data/form-data/compare/v4.0.2...v4.0.3)
[Compare
Source](https://redirect.github.com/form-data/form-data/compare/v4.0.2...v4.0.3)
</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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOm9icy11eC1tYW5hZ2VtZW50IiwiYmFja3BvcnQ6YWxsLW9wZW4iLCJjaTphbGwtY3lwcmVzcy1zdWl0ZXMiLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
---------
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Jon <jon@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
# Overview
This PR does various small things regarding the Privileged user
monitoring and Entity Analytics workflow, including:
- Adds technical preview labels where appropriate
- Adds in the screenshots for the navigation
- Removes the onboarding video in favor of an onboarding illustration
- Temporarily removes the integration cards from onboarding
# How to test
- Pull the code down and ensure the `privilegeMonitoringEnabled`
experimental flag is set
- Go to the "Entity Analytics" navigation menu in classic nav, and see
the new screenshots
- See that the Privileged user monitoring onboarding page should show
"Technical Preview"
- See that the Privileged user monitoring onboarding page should not
show Integration cards
- See that the video in the onboarding has been replaced with an
illustration
- Click "Go to dashboards =>", and see that the Privileged user
monitoring onboarding page should show "Technical Preview"
## 🧵 Summary
This PR introduces a few structural and cleanup improvements:
1. Moves core Emotion CSS helpers (`useMemoizedStyles` renamed as
`useMemoCss`, `kbnFullBodyHeightCss`, `kbnFullScreenBgCss`) from
`core/public` to a new package: `@kbn/css-utils`.
2. Removes a significant portion of legacy SCSS from the core plugin.
3. Replaces scss mixin with emotion `kbnFullScreenBgCss` across Kibana
(we have scss and emotion version, but emotion version wasn't widely
used yet).
4. As a result of (3), some plugin tests were migrated to React Testing
Library. This was necessary because Emotion-generated snapshots in
Enzyme were difficult to read and maintain when moving to emotion.
### Considerations
I initially tried to add the package to the [shared-deps
bundle](8e15517ddd),
but couldn’t get the SVG imports for `kbnFullScreenBgCss` to work
correctly in that setup.
As a workaround, I opted to import the helpers directly from their
source files.
An alternative approach could be to convert the used SVGs into React
components and use those within the shared package. Or explore something
like a static package and try to somehow wire in that in the webpack
internal compilers, but it doesn't seem to be worth the effort at the
moment.
### 💡 Motivation
- These utils don’t need to live in Core and are now decoupled to
improve performance and flexibility.
- Importing from `core/public` (even just for a small hook) was adding
noticeable overhead to test runs:
- ~1–2s delay on first Jest execution
- ~200ms added on subsequent runs
- Occasional CI timeouts due to deep import graph
### 👥 Ownership
I assigned this package to sharedux team. Thank you!
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Addresses https://github.com/elastic/kibana/issues/151636 .
This test was leftover from migration. Does not appear to be used.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Adding license check for list and disable scheduled report APIs
## To Verify
1. Run ES with basic license
2. Try accessing the scheduled report list and disable APIs from the Dev
Console. You should get a 403 error.
This PR removes the current GET user route as it works with IDs and we
do not use IDs in privmon.
We'd rather remove this before it gets documented and pushed out. We can
revert this PR later if needed
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Mark Hopkin <mark.hopkin@elastic.co>
## Summary
The following changes are in support of space awareness:
- A new reference data item type to store the space ID that should be
used to display orphaned response actions
- With space awareness, where the visibility of response actions is tied
to the Fleet integration policy associated with the agents, its possible
that response actions (older one) may become unaccessible when the
associated integration package policy is deleted. To mitigate this for
customer that may want to continue to see them, we will allow for a
specific space ID to be defined where these should be made visible
- Two new **internal** APIs to read and update the space id where orphan
response actions should be visible
- Both APIs are currently only allowed to be used by any user having the
`superuser` role
- Read API: `GET /internal/api/endpoint/action/_orphan_actions_space`
- Update API: `POST /internal/api/endpoint/action/_orphan_actions_space`
- with a `body` of `{ spaceId: "space_id_here" }`
- `spaceId` can also be set to an empty string (default out of the box),
which results in the orphan response actions not being display in any
space
- A new internal `ReferenceDataClient` for managing reference data
items.
This makes the existing 'deactivate_all_instrumentations' and
'deactivate_instrumentations' agent configuration settings
available to EDOT Node.js agents (`agent.name:
opentelemetry/nodejs/elastic`).
**Addresses:** https://github.com/elastic/kibana/issues/202068
## Summary
This PR actualizes prebuilt rule customization test plan with the current feature state and desired test coverage we expect for prebuilt rule customization sub-feature.
## Details
The changes include
- Adding an extra test scenario for prebuilt rule customization via public API
- Fixing a scenario under Licensing section
- Fixing wording to make scenarios simpler
Closes https://github.com/elastic/kibana/issues/223954
Closes https://github.com/elastic/kibana/issues/223921
## Summary
This PR adds support for ESQL autocompletion inside single quotes, which
allows suggestions that include triple quotes such as `KQL(``````)`.
<img width="1165" alt="Screenshot 2025-06-19 at 13 39 51"
src="https://github.com/user-attachments/assets/8ff59bf7-534e-4539-8cf8-2a1145dbf842"
/>
**Changes include:**
- The lexer rules have been updated to recognize single-quote query as
ESQL so that the highlighting is correct
- We escape and unescape characters that are invalid in a Console string
when we suggest inside single quotes so that we don't cause errors in
Console
**How to test:**
Make sure that ESQL suggestions are displayed inside both `"query":
"...` and `"query": """...` and that suggestions that contain quotes are
correctly escaped inside single-quote queries.
---------
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
## Summary
Summarize your PR. If it involves visual changes include a screenshot or
gif.
On cloud connector, cloud formation redirection kibana replaces the
value of the parameter param_ElasticResourceId=RESOURCE_ID with:
We used the deployment ID for hosted. While in ESS, we need to replace
with Kibana Component ID for hosted, instead of Deployment ID. We
extract `cloud.cloudId` base64 and decode `cloudId` in the following
format
`deployment_name:base64(<host>$<es_cluster_id>$<kibana_component_id>)`
and get the Kibana Component ID
Resolves: #213391
This PR adds validation for task interval where it is updated.
There are 5 places in the TaskStore that we update the interval:
`schedule`, `bulkSchedule`, `update`, `bulkUpdate` and
`bulkPartialUpdate`
For the bulk operations we just skip the task with invalid interval, for
schedule and update throw an error and stop the execution.
## To verify:
Create a rule with connector.
Let it run for a while.
Then update the rule.
There shouldn't be any error.
**Addresses:** https://github.com/elastic/kibana/issues/223446
## Summary
This PR fixes an issue when time duration normalized to day(s) is shown as 0 seconds. The fix is performed by allowing using days time unit at rule schedule.
## Details
The issue happens when rule schedule's look-back gets normalized to day(s). The reason is that look-backs input doesn't support Days time unit. It leads to inability to parse the value and displaying the default value which is 0 seconds.
Rule schedule is shown to the users as rule `interval` and `look-back` while rule's SO saves the schedule by using three fields `interval`, `from` and `to`. Where `look-back` represents a logical value calculated as `lookback` = `to` - `from` - `interval`. Taking that into account it's becomes harder to maintain the original time duration unit value during prebuilt rules upgrade workflow (See https://github.com/elastic/kibana/pull/204317 for more details).
The easiest way to fix this issue is to allow Days time unit in rule schedule inputs. On top of that 24 hours are always 1 day making hours the largest simply convertible time unit. The PR allows hours in rule schedule.
**Before:**
https://github.com/user-attachments/assets/4f2038f1-4a6a-4a88-b86e-381a5b717605
**After:**
https://github.com/user-attachments/assets/74875bf2-9341-425f-a35f-c8b088c1ef6a
## Summary
* Address https://github.com/elastic/kibana/issues/217145 - Put in place
a check to ensure we're upgrading from Kibana 8.18.0 or newer.
* Address https://github.com/elastic/kibana/issues/220521 - New attempt
at removing the `switchToModelVersionAt` property, inspired on
https://github.com/elastic/kibana/pull/219029.
The previous attempt caused a regression: index meta information started
storing _modelVersions_ that were older than the previously stored ones,
which were defaulting to 10.0.0 for SO types that did NOT define
`modelVersions`.
This was due to the removal of the applyTypeDefaults, which was ensuring
all SOs had the `switchToModelVersionAt` property set.
This flag was then used by
`src/core/packages/saved-objects/base-server-internal/src/model_version/version_map.ts`
to determine whether to use `modelVersions` or the legacy `migrations`
property in order to determine the latest model version for a given
type.
When removing the `switchToModelVersionAt` flag (and its default
backfill), the logic started defaulting to the latest `migrations`
version for those SO types that were not defining any `modelVersion`,
resulting in older versions that those stored in the SO indices. This
caused incident https://elasticco.atlassian.net/browse/INC-3818.
This regression has been shipped in 9.0.0 (the PR was
[backported](https://github.com/elastic/kibana/pull/219329)), so in top
of the cleanup, we now need to address
https://github.com/elastic/kibana/issues/220521 to ensure a smooth
transition _OnPrem => Serverless_.
---------
Co-authored-by: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
In Universal Profiling views, avoid to display the 0 value address
appended to executable file names.
Planned improvements on aggregations in the ES profiling plugin require
to reset the address for unsymbolized or partly symbolized frames.
For example, aggregating Kernel frames from two different hosts with
different kernel versions will currently end up with two distinct
entries in the TopN functions:
```
vmlinux: _raw_spin_unlock_irqrestore
vmlinux+0x124
vmlinux: _raw_spin_unlock_irqrestore
vmlinux+0x542
```
When aggregating these into a single line, displaying the address would
be misleading or wrong.
So the ES plugin may set the address to 0 for the aggregated entry
```
vmlinux: _raw_spin_unlock_irqrestore
vmlinux+0x0
```
Now, the `+0x0` seems superfluous and is not helpful to the user.
This PR would drop the address.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Related to https://github.com/elastic/kibana/issues/221521
This PR updates the logic that determines whether a clicked node in the
waterfall is a span or a transaction, making it compatible with
non-processed OTel traces data.
The approach used is the same as in the document profile enablement:
d80885a454/src/platform/plugins/shared/discover/public/context_awareness/profile_providers/observability/traces_document_profile/span_document_profile/profile.ts (L70-L79)
**Extra fix**
- Added a focus trap to the flyout because without it, focus sometimes
stayed on the waterfall behind, causing unexpected behavior when trying
to filter in the "Table" tab.
## How to test
- Enable the discover profiles by adding this to the` kibana.yml `file:
```discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
- Make sure your space has Observability as Solution View.
- Open Discover and query non-processed OTel traces
- Open any flyout and go to the full screen waterfall
- Click on any node of the trace, it should be opened as "Span document"
## Summary
Closes https://github.com/elastic/kibana/issues/224596
The “View related errors” link in the full-screen waterfall was
resolving to an invalid ES|QL query in some specific scenarios (it
worked fine in edge-oblt, for example).
To work around this and make the query less restrictive for ES|QL, we’ve
updated it to use `QSTR` instead. It provides the same type of search
and gives us the expected results without triggering errors.
**Before**
**After**
## How to test
- Enable the discover profiles by adding this to the` kibana.yml `file:
```discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
- Make sure your space has Observability as Solution View.
- Open Discover and query a trace with errors
- Open any flyout and go to the full screen waterfall
- Click on "View related links" on any of the nodes
Fixes https://github.com/elastic/kibana/issues/204668
## Summary
This PR adds a custom context menu to Console that correctly copies,
cuts, and pastes the selected text in the editor. Previously, when we
did right click (or Ctrl + click), the native browser context menu is
open but only the word on which we clicked was selected, rather than the
whole selected text in the editor. This is because the native browser
context menu is not aware of Monaco's selection and treats the text in
the editor as regular text in the browser. To fix this, we add a custom
context menu that is aware of Monaco editor's selection, which correctly
copies and cuts the selected text.
**Note for changes in CodeEditor component**: In order to enable the
custom context menu, we need to add the `import
'monaco-editor/esm/vs/editor/contrib/contextmenu/browser/contextmenu.js';`
import, which would enable the Monaco context menu in all code editors
in Kibana unless we explicitly disable it with `contextmenu: false`,
which we do in the CodeEditor component as a default behavior. This
ensures that all other code editors in Kibana still have the native
browser context menu. @elastic/appex-sharedux please let us know if you
would like us to add this custom context menu to the Code editor
component so that all editors in Kibana have the same context menu with
a correct behaviour.
https://github.com/user-attachments/assets/ceb65438-a17e-46fd-be6a-a1cce4d98df7
This PR contains the following updates:
| Package | Update | Change |
|---|---|---|
| docker.elastic.co/wolfi/chainguard-base-fips | digest | `799fc6d` ->
`d55453a` |
---
### 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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOk9wZXJhdGlvbnMiLCJiYWNrcG9ydDpza2lwIiwiY2k6YnVpbGQtZG9ja2VyLWZpcHMiLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
This change is in support of space awareness which is currently behind a
feature flag:
- Adds new processing logic to the Fleet package policy delete extension
point to update response action that reference that package policy with
a tag indicating that policy was deleted
- This check is done for all packages that support response actions -
currently `endpoint`, `crowdstrike`, `microsoft_defender_endpoint` and
`sentinel_one`
### Checklist
- [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
## Summary
The following changes are being done in support of space awareness:
- Ensure that a `tags` field is added to the response actions request DS
index
- FYI: the elastic defend package will soon also be updated with this
new field
- Update migration of response actions to populate the new `tags` field
with `INTEGRATION-POLICY-DELETED` for cases where the migration is
unable to determine the policy information associated with the agent(s)
the action was sent to
- Update internal response action utilities that retrieve action request
to ensure `tags` is an array
### Checklist
- [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
This PR updates the ES|QL grammars (lexer and parser) to match the
latest version in Elasticsearch.
Changes:
- moves sample on tech preview
<img width="818" alt="image"
src="https://github.com/user-attachments/assets/24441300-72c5-4055-b316-6e9ad3939d0a"
/>
- Sample now supports variables
- Fork is on tech preview but I didn't do this at this PR, I will do on
a follow up PR
- there is a breaking change in from, we dont allow anymore
"index"::"selector", fixed the tests and the parsers
- small changes in like, rlike expressions
---------
Co-authored-by: Stratoula <efstratia.kalafateli@elastic.co>
## Summary
We have [this RFC](https://github.com/elastic/ecs/pull/2493) in, I think
this is a safer bet and might save us a migration in the future:
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/search-team/issues/10121
Add a base set of retrieval oriented tools, and expose them to the
default agent.
## Tools
**Warning: names are still TBD**
We're starting to see two different "layers" of tool appear: "simple"
tools, which are doing a simple programmatic (understand: no LLM) task,
and "smart" tools, which are more like workflows, with some of the steps
relying on a LLM.
This PR introduces the following tools:
### Simple tools
Simple tools (name TBD) are "programmatic" tools not relying on an LLM
for their execution.
This PR introduces this base set of tools:
- `get_document_by_id`: resolve a full document based on its id/index.
- `list_indices`: list the indices the current user has access to.
- `get_index_mappings`: retrieve the full mappings based for a given
index.
- `execute_esql`: executes a provided ES|QL query
### Smart tools
Smart tools can have multiple internal steps (even if it remains an
implementation detail), and are using LLM calls for some, or all, of
them.
*Note: there are huge potential areas of improvement in the current
implementation of all those smart tools. One of the intent of this work
is precisely to identify such areas of improvement*
#### `index_explorer`
Based on a natural language query, returns a list of indices that should
be searched, and their corresponding mappings.
<img width="984" alt="Screenshot 2025-06-17 at 16 44 32"
src="https://github.com/user-attachments/assets/edff3964-31e3-40ea-a761-adf7c45fcb17"
/>
#### `generate_esql`
Based on a natural language query, generates an ES|QL query.
- use the `nl-2-esql` task under the hood
- optional use `index-explorer` if `index` is not specified.
<img width="891" alt="Screenshot 2025-06-17 at 16 51 56"
src="https://github.com/user-attachments/assets/ce141d6b-dd4f-4eb9-ab32-823b81bc810b"
/>
#### `relevance_search`
Perform a "full-text search" based on given term and returns the most
relevant highlights.
<img width="1071" alt="Screenshot 2025-06-17 at 16 59 49"
src="https://github.com/user-attachments/assets/1f873e70-e277-424d-93e4-24b269a554e5"
/>
#### `natural_language_search`
Retrieve data based on a natural language query.
Converts a natural language query to an ES|QL one then executes it,
useing `generate_esql` and `execute_esql` under the hood.
<img width="768" alt="Screenshot 2025-06-18 at 08 31 52"
src="https://github.com/user-attachments/assets/cb319831-17ed-4ad7-9e1f-2fe90c2472fa"
/>
## Researcher assistant
The second part of this PR is implementing a researcher agent for deep
research tasks.
The researcher assistant is following a very classic
"act->process->reflect" cycle.
<img width="960" alt="Screenshot 2025-06-18 at 09 16 17"
src="https://github.com/user-attachments/assets/c24be323-ecf2-4c43-88fb-eaf874b18afc"
/>
The implementation of the cycle is currently as follow:
**1. Act**
Given a research topic, the research history and a list of tools, select
the tool best suited to search for this topic, and call it.
The tools exposed to the agent in this phase are:
- `index_explorer`
- `relevance_search`
- `nl_search`
*Note: later the whole `act` step could evolve to instead call sub
search agent with planning and multi-step execution.*
**2. Process**
Process the results from the latest `act` phase and create a
corresponding entry in the search log.
At the moment, we're simply storing the whole tool call + results to the
search log in a LLM-friendly format.
**3. Reflect**
Based on the main research query and the search log, identify where the
information collected are enough to answer the question. If not,
identify follow-up questions or sub-problems that it would be useful to
solve to gather more information
## What is out of scope of the current PR
- Figuring out which set of tools should be exposed by default to the
main agent (right now, all the tools listed in this PR are)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
The PR skips test suites for ES `9.0.*` which were failing when these
tests ran in Kibana `8.19` branch against ES `9.0.*` in forward
compatibility runs. The tests were failing because the index privilege `read_failure_store` isn't available available in ES 9.0.
## Summary
This PR introduces the concept of internally managed rule types. The
purpose of this PR is to hide alerts in the alerts table in the UI
produced by internally managed rule types. In following PRs, we will
enhance the framework to handle more cases when the product requirements
are clearer. If, in the future, the streams team wants to use the alerts
table to show stream alerts, we could introduce a new parameter in the
alerting API to allow alerts produced by internally managed rule types
to be returned.
Fixes: https://github.com/elastic/kibana/issues/221379
cc @kdelemme @dgieselaar
### Checklist
- [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
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
- Adds the `in_progress_at` timestamp to Cases Saved Objects
- Adds the `time_to_acknowledge`, `time_to_investigate` and
`time_to_resolve` timing metrics to Cases Saved Objects
## References
Closes#217638
### 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] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed (passed ✅)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>
Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
## Summary
This PR updates the @elastic/security-threat-hunting-explore codeowners
to @elastic/security-threat-hunting-investigations as both teams are
getting merged together.
I used this opportunity to do some clean up as some folders did not
exist anymore.
## Summary
Closes https://github.com/elastic/ingest-dev/issues/5444
* Add `enablePackageRollback` feature flag
* Save package policy previous revision on package upgrade
* Add `latest_revision` boolean property to
`ingest-package-policies/fleet-package-policies` saved object type
* Package policy SO are created with `latest_revision: true`
* When a package policy is updated with a new package version, the
previous SO is saved to ES with id `{id}:prev` and `latest_revision:
false`
* Backfill existing SO with `latest_revision: true`
* GET logic filters for `latest_revision: true`
* Save package previous version
* Add `previous_version` property to `epm-packages` saved object type
* When a package is upgraded to a new version, set `previous_version`
### Testing
* Install an integration on an outdated version (edit the version in the
URL and add the integration).
* Check the package policy SO: it should have been created with
`latest_revision: true`.
* Check the package SO: the `previous_version` property should not be
set.
* Upgrade the integration and upgrade package policies.
* Check the package policy SO: there should now be 2 SO for this package
policy:
* The updated one with `latest_revision: true` and policy id
* The previous one with `latest_revision: false` and `{policy_id}:prev`
* Check the package SO: the `previous_version` property should be set to
the old version
Note: it seems Fleet only allows upgrading packages to the latest
version (please correct me if that's wrong); for testing two consecutive
updates (e.g. check that only the most recent revision is saved), it
might be necessary to run a custom EPR.
### Checklist
- [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
Risk of bad requests across Fleet wherever packages or package policies
are queried.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## ES|QL support for partial results
[Issue](https://github.com/elastic/kibana/issues/211622)
We have 2 use cases:
- For aggregation query, we set `allow_partial_results` to false
- For normal query we are set warning status if there cluster failures
### How to test
1. Create a datastream
```
PUT _index_template/my_datastream_template
{
"index_patterns": ["my_datastream*"],
"data_stream": {},
"template": {
"mappings": {
"properties": {
"@timestamp": {
"type": "date"
},
"host": {
"properties": {
"name": {
"type": "keyword"
}
}
}
}
}
}
}
PUT /_data_stream/my_datastream
```
2. For a single specific index set broken mapping
```
GET my_datastream
PUT .ds-my_datastream-2025.06.11-000001/_mapping
{
"runtime": {
"broken": {
"type": "keyword",
"script": {
"source": "emit(doc['nonexistent_field'].value)"
}
}
}
}
```
3. Ingest document
```
POST my_datastream/_doc
{
"@timestamp": "2025-06-05T09:04:11.493Z"
}
```
4. Check that query return partial result true:
```
POST _query/async?drop_null_columns=true&allow_partial_results=true
{
"query": "from my_datastream* METADATA _id | limit 101",
"keep_alive": "60s"
}
```
response:
```
{
"is_running": false,
"took": 5,
"is_partial": true,
...
```
4. Create rule ES|QL with the same query and lookback which overlap
documents you created on step 3.
Observe warning
<img width="1261" alt="Screenshot 2025-06-11 at 08 52 07"
src="https://github.com/user-attachments/assets/c371f57b-51ff-4a13-96e3-19e2094d794c"
/>
---------
Co-authored-by: Vitalii Dmyterko <92328789+vitaliidm@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/220927
- Introduces *tuple* lists, which use round parens `()`. Now we have two
list types, one with square brackets `[]` (literal list) and one with
round `()` (tuple list).
- Literal lists: `[1, 2, 3]`, `[TRUE, FALSE]`
- Tuple lists: `x IN ("a", "b", "c")`, `y IN (1, 2, fn(field))`
- Adds support for tuple lists in pretty-printers.
- Fixes a bug where right paren is inside trailing line comment `// ...
)`.
### Checklist
- [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
This PR closes#221508.
https://github.com/user-attachments/assets/0b57487a-7188-4722-99dc-5cb44c15f129
- Added a new API endpoint to edit the label of private locations.
- When a label is updated, all monitors deployed in that location are
automatically updated to reflect the change.
- The UI now allows users to edit only the label of a private location.
- Added comprehensive API tests to cover the new functionality.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
Closes#218408
This work initially started with the introduction of a simple search bar
on the streams enrichment samples, but as we realized it didn't fit well
with the requirements for a smooth simulation experience, we moved in
another direction.
## Data sources
As we want to let users pull documents from multiple sources to simulate
their processors (such as docs from Discover, failure store, custom
documents pasted into the simulator, etc...), this work introduces a
data source entity in the simulation playground.
On top of how it used to work, it converts the random samples previously
fetched automatically to a dedicated data source.
As this becomes now a scalable concept, we provide users with the
ability to add/remove/enable different data sources for the same
simulation:
- **Random samples**: This is always available by default to have at
least a data source always available; it can still be enabled/disabled
on demand.
- **KQL search**: Provides a KQL search bar, similar to the one found in
Discover and across Kibana, which enables patterns for pulling documents
into this page from Discover or elsewhere.
- **Custom samples**: Paste raw documents that will be used among the
other data sources for the whole simulation.
## 💡 Reviewer hints
- The data fetching now relies on the `data` plugin interfaces as we
needed a more capable API than the `_sample` one (now removed), and it
aligns with the data fetching practice used for the partitioning page.
- The data source can behave differently depending on its state
(enabled/disabled). To treat it as an isolated concept, a representing
actor machine is introduced and the root streamEnrichment machine
coordinates event-based communication as it happens already for the
processors' instantiation and management.
- The data sources are consistently persisted to the URL, with a couple
of exceptions:
- The `Custom samples` data source is not persisted, as it's not only
descriptive of the data source configuration but it also holds the
custom samples defined by the user. This could easily hit the URL
limits, so we warn the user this won't be persisted anyhow.
- The `Random samples` data source is always available and restored in
the URL to guarantee a data source available on the page.
## Summary
This PR resolves the issue of stale data in react-query on Automatic
Migrations' `Transtaled Rules` page when migrations are reprocessed.
As can be seen in the demo below, the value of columns `Risk Score`,
`Status` and `Severity` do not change when `Reprocessing` is complete (
Success Toast can be seen on bottom right ).
But those values are correctly updated when page is refreshed.
https://github.com/user-attachments/assets/b9262e7e-f7bc-4ffd-b027-fe348f281d97
### Issues
There were couple of issue causing the problem mentioned above:
1. `react-query` cache for `migration rules` was not being cleared when
migration was completed. So it was showing stale old data from the time,
when migration just started.
2. Secondly, below `useQuery` hook was registering `siem-migration`'s
queries in Cases' `queryClient` instead of security solution
queryclient. This makes it difficult to get the handle on security
solution's `queryClient` and use it to invalidate the queries.
d67c52710e/x-pack/solutions/security/plugins/security_solution/public/siem_migrations/rules/logic/use_get_migration_rules.ts (L32-L34)
### Changes
1. Invalidate siem-migrations query cache when a migration is finished.
2. Moves CasesContext outside of Security Solution's
`ReactQueryClientProvider`. This makes sure by default queries in
`Security Solution` will use Security Solution's `queryClient` by
default.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This removes the deprecated website search guided onboarding from
Kibana. Deprecated because we no longer offer a managed web crawler.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR modifies the Span doc viewer check to be better equipped for
dealing with unprocessed OTEL trace spans. If there is no
`processed.event` field, we can start assuming there'd be OTEL specific
fields to check. Here, we check for `kind` which *should* be present, so
any value determines this to be a trace span. In the absence of `kind`
being present and no `processed.event` field (just a `data_stream.type`
field, we can assume it is a span regardless.
## How to test
* Add the following to your `kibana.dev.yml` file:
```yaml
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
* Set up a source of unprocessed OTEL data to feed into ES (Open
telemetry demo, etc)
* Set your space to Observability mode, and go to Discover.
* Query for `traces-*` and open any record for the document viewer
* The Span Overview tab should be visible.
## Summary
fixes https://github.com/elastic/kibana/issues/211540
User will be able to choose maintenance window in the form
<img width="1723" alt="image"
src="https://github.com/user-attachments/assets/c4d75aff-687f-40d3-a614-160e99ce9ac2"
/>
A callout will be displayed on the form
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/124727bd-0bb6-4934-9406-a36c3584670a"
/>
### Task manager
When changes are made to maintenance windows, those are sync via task
manager to private location monitors, public location monitors are
automatically synced as well in already existing task.
### Testing
Create a maintenance window in stack management UI, apply it to monitor,
make sure, it never runs during maintenance window.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Currently, there's the assumption with duration data that it is in
microseconds format with how Trace Waterfall handles and calculates the
span blocks and the duration labels. This works fine with APM and
processed OTEL data, however, unprocessed OTEL duration fields are in
nanoseconds, not microseconds. This means the duration labels get
formatted incorrectly. A 10us duration is formatted as 10ms, and so
forth.
This PR creates a quick fix to resolve this duration input mismatch, by
correcting the nanosecond values into microsecond value equivalents.
| | Screenshot |
| -- | -- |
| Before | 
|
| After | 
|
## How to test
* Add the following to your `kibana.dev.yml` file:
```yaml
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
* Set up a source of unprocessed OTEL data to feed into ES (Open
telemetry demo, etc)
* Set your space to Observability mode, and go to Discover.
* Query for `traces-*` and open any record for the document viewer
* The Span Overview waterfall should show durations that match the
document's formatted duration in the Table/JSON tabs
Adds a new optional `kibana.yml` config setting
`xpack.aiops.ui.enabled`.
When set to `false` all aiops features in kibana are hidden.
- AIOps Labs pages in the ML plugin (Log rate analysis, Log pattern
analysis, Change point detection)
- Patterns tab in Discover
- AIOps embeddables in Dashboards (Log rate analysis, Log pattern
analysis, Change point detection)
- AIOps embeddables in Cases (Log rate analysis, Log pattern analysis,
Change point detection)
- Actions to run log rate analysis and log pattern analysis from the
anomalies table in the Anomaly Explorer and Single Metric Viewer
- Log rate analysis in the Log Threshold Alert details page, and it's
use in the contextual AI assistant in that page
Adds a new kibana capability `capabilities.aiops.enabled` which will be
`false` if aiops is disabled in the yml file.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes#222590
Use unified trace waterfall in expandable view in Discover.
Pending items:
- [x] missing legend implementation
- [x] missing items in the waterfall (updating on scroll issue?)
- [x] missing colors per resource type?
- [x] check if API needs `entryTransaction`
- [x] connect on onClick action
- [x] connect error link
- [x] styling: use error badge instead of button
- [x] styling: gap above the timeline
Pending items outside the scope of this PR:
- [ ] add support for span.type (legend and waterfall colors - classic
APM only)
- [ ] add # of error in the error badge (refer to the old waterfall)
## Summary
This PR applies **lossless compression** to all SVG and JPG/PNG assets
across Kibana using:
- [`svgo`](https://github.com/svg/svgo) — for optimizing SVGs
- [`image-optimize`](https://www.npmjs.com/package/image-optimize) — for
JPG/PNG compression
‼️**Please scroll to ''Unknown metric groups" accordion to see what's
the gain for your code.**
<img width="542" alt="Screenshot 2025-06-18 at 13 24 20"
src="https://github.com/user-attachments/assets/191afb28-44fc-4551-9026-756a8385c66a"
/>
The goal is to reduce asset size and improve load performance without
compromising visual quality.
This PR achieves a **23 MB** reduction in asset size across all images
bundled in Kibana’s running code—meaning these compressed images
directly impact what ships in Kibana.
Some assets get bundled into chunks due to our bundling strategy but
might not actually be requested at runtime.
Additionally, I ran the same optimization script on the docs assets as a
harmless extra step, but those savings aren’t included in the 23 MB
total.
---
## Why
While working on Emotion rewrites, I noticed some SVGs seemed
unnecessarily heavy. That led to a broader investigation into our image
assets, and it turns out we’re not consistently optimizing them during
development or build.
---
## Notes
- Visual fidelity of optimized assets has been manually verified — no
visible differences
- The optimization is **lossless**, meaning no quality degradation
- Some assets (like large background images) could benefit further from
**lossy compression**
---
## Follow-ups / Ideas
1. **Automate compression in the dev/build pipeline**
- e.g. add `svgo` as a pre-commit or CI step for SVGs
2. **Improve CI reporting**
- Currently, bundle size diffs for images are hidden under "Unknown
metric groups" in the GitHub CI comment. We may want to make these more
visible.
-
3. **Audit large assets manually** — apply lossy compression where
appropriate
4. **Avoid redundant image loading**
- e.g. background images on the login page are loaded again on the space
selector page since they’re bundled twice. I’m working on a separate PR
to address that.
## Snippets I used to apply the compression
```
# Find SVG files
find . -type f -iname "*.svg" \
-not -path "*/node_modules/*" \
-not -path "*/functional/*" > svg-files.txt
# Compress SVGs
while IFS= read -r file; do
svgo "$file"
done < svg-files.txt
```
This snippet has been used for png and jpg, but the example below is for
png:
```
# Find PNG files
find . -type f -iname "*.png \
-not -path "*/node_modules/*" \
-not -path "*/functional/*" > png-files.txt
# Compress PNGs
while IFS= read -r file; do
image-optimize -f jpg "$file"
done < png-files.txt
```
## Summary
This PR passes the logs essentials tier setting to the local ES test
server in FTR test configs. This is required by elasticsearch serverless
to disable certain features.
## Summary
Fix bulk actions incorrectly selecting agents with namespaces filter.
The namespaces filter `namespaces:(default) or not namespaces:*` was
introduced with space awareness feature, it is incorrectly concatenated
with other filters, ending up selecting all agents.
To verify:
- Enroll Fleet Server and 10 agents with horde
- Search on horde agents by filtering on `eh*`
- Select rows per page to be 5
- Select all agents on all pages (should be 10)
- Click on bulk unenroll action
- Verify that only the selected 10 agents are unenrolled
- Previously with the bug, all agents were unenrolled, including Fleet
Server
Filters included in the search:
`[
"(namespaces:(default) or not namespaces:*) AND (eh*) and (status:online
or (status:error or status:degraded) or status:orphaned or
(status:updating or status:unenrolling or status:enrolling) or
status:offline)",
"NOT status:unenrolled"
]`
<img width="1412" alt="image"
src="https://github.com/user-attachments/assets/4740f0c7-67ab-41c3-9dd4-0b122ed472aa"
/>
<img width="1278" alt="image"
src="https://github.com/user-attachments/assets/b7944d43-c4a6-42ca-b1c8-c8be78fc40cf"
/>
### Checklist
- [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
## Summary
Add an advanced setting to enable streams UI. The setting is enabled by
default for observability serverless deployment
### Testing
- `yarn start --serverless oblt` - streams UI is activated by default -
do not forget to set `xpack.cloud.serverless.project_id: test-123` to
have a proper serverless deployment
- `yarn start` - streams UI is not activated by default
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR updates the ES|QL grammars (lexer and parser) to match the
latest version in Elasticsearch.
## COMPLETION command update
```
completionCommand
: COMPLETION (targetField=qualifiedName ASSIGN)? prompt=primaryExpression WITH inferenceId=identifierOrParameter
```
* No longer parse `COMPLETION ... AS <targetField>`
* Add parsing support for `COMPLETION <targetField> = <prompt>`
* Allow `=` to be used within COMPLETION
* Update autocomplete and validation accordingly.
https://github.com/user-attachments/assets/6884bde4-fc14-4adb-9187-8e1ca125c52e
## RENAME
```
renameClause:
oldName=qualifiedNamePattern AS newName=qualifiedNamePattern
| newName=qualifiedNamePattern ASSIGN oldName=qualifiedNamePattern
```
Now renames support an ASSIGN expression.
* Support assign in the autocomplete.
* Support assign in the rename expression.
* Assign is treated in the same way as `AS`, only difference is that the
params are reversed.
https://github.com/user-attachments/assets/3ccdaa62-bba5-4221-8f93-8b9b6e761a1e
## SAMPLE
```
sampleCommand
: DEV_SAMPLE probability=decimalValue
```
* It does not parse seed value anymore.
* Cleaned tests.
## FORK
* Fixed failing test
* Couldn't make CHANGE_POINT work within FORK, so didn't pushed anything
related to supporting the commands within it.
---------
Co-authored-by: Sebastian Delle Donne <sebastian.delledonne@elastic.co>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Closes https://github.com/elastic/kibana/issues/202423
## Summary
This PR updates the URL validation logic in the UI to allow hostnames
without a dot character. This brings the UI behavior in line with the
API, which already accepts such URLs.
<img width="914" alt="Screenshot 2025-04-14 at 13 53 48"
src="https://github.com/user-attachments/assets/4774b743-d9b6-4a25-8b4a-8e8a8c6f2536"
/>
---------
Co-authored-by: Dima Arnautov <arnautov.dima@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Christos Nasikas <christos.nasikas@elastic.co>
## Summary
This PR reuses sourcerer data view creation logic for security solution
and applies it to the new flow with data view manager (discover data
view picker).
Closes https://github.com/elastic/security-team/issues/12570
Closes https://github.com/elastic/kibana/issues/220589
## Testing
Starting kibana from scratch with the feature flag enabled should create
default security solution view, **in either default or custom Kibana
Space**.
The FF:
```
xpack.securitySolution.enableExperimental: ['newDataViewPickerEnabled']
```
### Checklist
Check the PR satisfies following conditions.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated / added
---------
Co-authored-by: Michael Olorunnisola <michael.olorunnisola@elastic.co>
This is largely based of @clintandrewhall's work that he extracted from
the new workspace layout poc. These components are a decent starting
point for [new grid layout
](https://github.com/elastic/kibana-team/issues/1581) and I
[validated](https://github.com/elastic/kibana/pull/223021) that the
layout mostly works for Kibana (fixing a couple of edge cases)
I believe the components are ready to be merged into the main branch to
make future reviews easier:
Bootstraps a new `@kbn/core-chrome-layout-components` package to provide
composable React primitives for Kibana’s Chrome layout, including region
components, a debug overlay, Storybook stories, and initial docs.
- Adds layout region components (Banner, Header, Navigation, Sidebar,
Panels, Application, Footer) and a debug overlay with Emotion styling.
- Provides a README with usage examples (Storybook-driven) and API
documentation.
`yarn storybook sharedux`
---------
Co-authored-by: Clint Andrew Hall <clint@clintandrewhall.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### 🍒 Summary
resolves https://github.com/elastic/kibana/issues/224476
This PR changes how the summary indices are constructed when remote
clusters is enabled.
When `useAllRemoteCluster` is true, we simply use `*:summary-index`
instead of listing each remote individually.
We also removed the need to fetch the remote clusters info when we use
`useAllRemoteCluster`.
### Release notes
Fix SLO federated view bug when remote clusters and index name listed
exceeded 4096 bytes.
While working on [this
PR](https://github.com/elastic/kibana/pull/221515) I noticed an issue
when trying to bulk update saved objects overriding the current space
for the operation.
---------
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
Co-authored-by: Shahzad <shahzad31comp@gmail.com>
Co-authored-by: Rudolf Meijering <skaapgif@gmail.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/222635
When the rule import file contains a connector that specifies an
`originId`, the specified `originId` is carried through to the connector
that gets created even if the connector `id` gets regenerated. In this
case, the created connector does not contain the `id` that was specified
in the import file at all - the `originId` is from the import file, and
the new `id` is a regenerated one. This means that when we attempt to
migrate the connector references on the rules (which reference
connectors by `id`), there is no connector with the expected `id` value
in either the `id` or `originId` field.
This PR fixes the issue by stripping `originId` from connectors before
importing so that the `originId` will be the original `id` value in
cases where the `id` needs to be regenerated (e.g. when a connector with
the same `id` already exists in another space).
## Testing
Steps to reproduce:
1. Export a custom rule with an action connector that has an `originId`
2. Create a new space (or use an existing space without the rule or
connector) and attempt to import the rule with the connector (the
overwrite options checked or unchecked result in the same behavior).
3. Observe that the rule import fails due to the lack of action
connector with the supplied ID. However, the action connector does
import but the ID is changed so it does not match with the original
imported ID.
An `ndjson` export sample that triggers the issue is attached to the bug
ticket. Simply import the sample into one space (which should work) then
import it into a second space (should fail without the fix in this PR).
### Additional Testing Note
I tried creating a rule with a connector in a non-default space on
7.17.28 then upgraded to 8.18.2 to force the connector SO ID to be
regenerated and populate `originId` with the original SO ID. This was to
check if a rule could be exported with a reference to the `originId`
instead of the actual `id`. In this scenario the exported rule does
reference the connector by `id`, not `originId`, so stripping the
`originId` on re-import does not cause a problem.
I also tried upgrading directly from 7.17.28 to 8.0.0 to see if any
intermediate version might cause rule to reference connectors by
`originId`, but the connector reference on the rule is migrated during
the upgrade process. This migration is possible because on the rule SO
in the framework the connector ID is stored in the SO references array,
**not** directly in the `actions` array as it appears in the rules APIs.
So in this scenario as well, stripping the `originId` should not be an
issue because the rules should never be referencing connectors by
`originId`.
## Summary
Original issue: https://github.com/elastic/security-team/issues/10688
This PR adds a new function to the rules client called
`bulkFillGapsByRuleIds`, that takes a list of rule ids and a date range,
and attempts to fill out the gaps simultaneously, 10 rules at a time
(can be customizable).
For all rules we verify if the user has access to write to the gaps
object, then for each rule we fetch gaps and trigger the backfilling of
its unfilled intervals.
During the execution, we aggregate the errors and the rules that are
skipped in lists and return them along with the scheduling outcomes.
### Error handling
There are 2 error types that are handled throughout the scheduling of a
gaps backfilling for a rule:
- A user doesn't have access the rule
- We fail to backfill gaps
### Skipped rules
A rule can be skipped when it doesn't have unfilled gaps in the given
time range, or when gaps are found, but they are currently "in
progress".
### Endpoint
This PR also updates the existing bulk actions endpoint by adding the
action `fill_gaps`. The endpoint for now should limit the amount of
rules per call to 100.
The bulk actions endpoint returns a summary of the execution which is a
list of counters of rules that succeeded, failed or were skipped.
## How to test?
1. Create several rules that run every 5 seconds and disable them. Leave
them disabled for a couple of minutes and then re-enable them in order
to create some gaps for it. You can confirm that there are gaps by
clicking on the rule, then on the "Execution results" tab, and then
scrolling down to "Gaps".
Alternatively you can 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"
```
2. Get the ids of each rule that you created and call the endpoint to
backfill them. You can select a time range that is smaller than the gaps
so that you can call it several times. Here is an example of a curl to
do this
```
curl -X POST "http://localhost:5601/api/detection_engine/rules/_bulk_action?dry_run=false" \
-H "Accept: */*" \
-H "Content-Type: application/json" \
-H "kbn-version: 9.1.0" \
-H "kbn-build-number: 9007199254740991" \
-H "elastic-api-version: 2023-10-31" \
-H "Authorization: Basic $(echo -n 'elastic:changeme' | base64)" \
--data-raw '{
"action": "fill_gaps",
"ids": ["307bdea8-28be-419f-bb25-dac0024f32af"],
"fill_gaps": {
"start_date": "2025-05-09T08:12:09.457Z",
"end_date": "2025-05-09T09:12:09.457Z"
}
}'
```
3. Then you can go to the "Gaps" tab from step 1 and verify that the
gaps are being filled. Additionally, you can see that there are manual
runs scheduled for the rule in order to fill the gaps.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR implements the frontend for opening a Saved Playground. As a
part of that there are several refactors to the current playground that
warrant regression testing.
### Testing
To test the saved playground view the search mode feature flag should be
enabled, either with a config override or via console:
```
POST kbn:/internal/kibana/settings/searchPlayground:searchModeEnabled
{"value": true}
```
Then you will need to manually save a playground:
```
curl -X "PUT" "http://localhost:5601/internal/search_playground/playgrounds" \
-H 'elastic-api-version: 1' \
-H 'kbn-xsrf: dev' \
-H 'x-elastic-internal-origin: Kibana' \
-H 'Content-Type: application/json; charset=utf-8' \
-u 'elastic_serverless:<PASSWORD>' \
-d $'{
"elasticsearchQueryJSON": "{\\"retriever\\":{\\"standard\\":{\\"query\\":{\\"semantic\\":{\\"field\\":\\"text\\",\\"query\\":\\"{query}\\"}}}},\\"highlight\\":{\\"fields\\":{\\"text\\":{\\"type\\":\\"semantic\\",\\"number_of_fragments\\":2,\\"order\\":\\"score\\"}}}}",
"indices": [
"search-test"
],
"name": "Test playground",
"queryFields": {
"search-test": [
"text"
]
}
}'
```
*Note this creates a saved playground in the Default space, and
playgrounds are space aware so it will only be available in the default
space. If you want to create a playground in another space you will need
to update this URL to include the space.
This assumes you have a `search-test` index created using the
semantic_text onboarding workflow mapping.
Then you can open the saved playground page at:
`/app/search_playground/p/<ID_RETURNED_FROM_CURL>`
## Screenshots
Chat
Chat - Query
Search - Query
### Checklist
- [x] 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
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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>
Introduces new config key to allow passing app tokens for elasticsearch
and fleet server for agentless deployment:
```
xpack.fleet.agentless.deploymentSecrets:
fleetAppToken: TOKEN1
elasticsearchAppToken: TOKEN2
```
This new config will be passed to the agentless-api to be used by
agentless agents to support traffic filtering.
---------
Co-authored-by: Michel Losier <michel.losier@elastic.co>
Closes#224425
## Summary
This PR adds support for the text panel in the APM dashboards inside the
metrics tab
## Testing
⚠️ UPDATE: The dashboard won't be part of the PR so ⬇️ won't work now
- with connection to edge oblt cluster:
- Open Applications > Service Inventory and click on the `cart` (or any
EDOT .NET service) service
- Go to the metrics tab
- The dashboard should be visible
## Summary
Resolves#219264
The issue revolves around the possiblity of the Entity Store being
enabled without the Asset Inventory DataView being installed. This can
happen when the Entity Store is enabled from the Entity Store page
instead from the Asset Inventory Page.
The original plan was to enhance the enablement process with the
DataView installation but after further considerations it was decided to
decouple the process. Here is a little diagram to explain the thought
process:
(Option 1 is the original plan, option 2 is what we ended up going with)
### Server-side checking
Visiting the Asset Inventory Page triggers a check for the data view
(happening within the status API), if it does not exists, installs it:
https://github.com/user-attachments/assets/d57409e8-9d85-4569-9ef5-90e5136b30a7
### Client-side error handling
In some scenarios, the user might not have the permission to install the
DataView, in this case, there's an error handling:
https://github.com/user-attachments/assets/ee1c348f-9950-4a97-9ce1-8ee5d798f063
---------
Co-authored-by: Paulo Silva <paulo.henrique@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
another attempt of https://github.com/elastic/kibana/pull/224432
@elastic/appex-sharedux Has a couple of dependency groups that need a
lot of manual intervention or are being phased out. We want to reduce
the noise from automatic updates and decided to pin automatic updates to
some of those to minor/patch version
- React - team is working on it manually
https://github.com/elastic/kibana-team/issues/1564
- React-Router - will be huge manual phased dependency upgrade when we
get to it
- Enzyme - Deprecated and teams are migrating away
https://github.com/elastic/kibana/issues/222949, Let's not spend time
upgrading related dependencies since the pull request for the upgrade to
newer versions is failing.https://github.com/elastic/kibana/pull/219581
- Styled Components - Deprecated and teams are moving away from it.
https://github.com/elastic/kibana-team/issues/1417 .I suggest we don't
upgrade and avoid spending time on visual regression testing.
## Summary
Add license gate around agents automatic upgrades feature:
- Hide UI elements if license is less than Enterprise - hide Manage auto
upgrade button in Agent policy details
- Add license gate around API to update target versions in agent policy
update
- Add license gate around auto upgrade task
### Testing
With a basic license, try to access the agent auto upgrades feature and
verify that is not available
### 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
## Summary
This PR adds a background task to `share` plugin which periodically
deletes saved objects of type `url` which have been older than a value
controlled by `share.url_expiration.duration` config - the default is 1
year.
The task can be run manually by calling `POST
/internal/unused_urls_task/run` with `superuser` privileges.
Config options (with their default values):
```yaml
share.url_expiration.enabled: false # controls whether the task is enabled
share.url_expiration.duration: '1y' # controls the expiration threshold
share.url_expiration.check_interval: '7d' # controls how often the task runs
share.url_expiration.url_limit: 10000 # controls how many urls should be fetched at once
```
Closes: #179146
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR introduces a new "Overview" page within the Entity Analytics
section of the Kibana Security Solution app.
The scope of this PR is to reuse the existing Entity Analytics dashboard
components while providing a new entry point for Overview.
## Key Changes:
- Added a new navigation item called "Overview" under the Entity
Analytics section.
- Introduced a new route at /entity_analytics/overview that renders the
existing EntityAnalyticsDashboard component.
- The new page is searchable via Kibana
- Ensured all code reuse follows existing patterns with no duplication
of dashboard layout or components.
## Testing Steps
1. Navigate to the Security Solution page in Kibana.
2. In the left-hand navigation panel, click on Entity Analytics. You
should see a new submenu item labeled Overview.
3. Click on Overview. You should be directed to a new page with the
heading Entity Analytics, which mirrors the existing Entity Analytics
dashboard.
4. Use the global search at the top of the page to search for
"Overview". You should see a result under Security → Entity Analytics →
Overview. Clicking this result should navigate you to the same Overview
page as described in step 3.
5. The URL of the Overview page should be similar to
`/app/security/entity_analytics/overview?sourcerer=(default:(id:security-solution-default,selectedPatterns:!(%27logs-*%27)))&timerange=(global:(linkTo:!(),timerange:(from:%272025-05-28T18:30:00.000Z%27,fromStr:now%2Fd,kind:relative,to:%272025-05-29T18:29:59.999Z%27,toStr:now%2Fd)),timeline:(linkTo:!(),timerange:(from:%272025-05-28T07:32:08.611Z%27,kind:absolute,to:%272025-05-29T07:32:08.611Z%27)))&timeline=(activeTab:query,graphEventId:%27%27,isOpen:!f)`
6. The timeline (`Untitled timeline`) should be visible at the bottom of
the page.
7. Scroll down to the entities and the entity flyout (the tilted
double-header arrow icon) should get opened.
8. Execute a KQL search query. It should return results for the data
present.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] 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)
- [ ] 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
- [ ] 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
Closes https://github.com/elastic/kibana/issues/221927
## Summary
#### New Component: `AttributesOverview`
- Introduced a new component to provide a unified, user-friendly
overview of document attributes in the Observability context.
- The component organizes attributes into three main groups:
- Signal attributes (e.g., attributes.*)
- Resource attributes (e.g., resource.attributes.*)
- Scope attributes (e.g., scope.attributes.*)
- Each group is rendered in its own accordion section for clarity and
ease of navigation.
#### Search and Filtering
- Added a search bar to filter attribute fields by name or value,
improving discoverability.
- Filtering logic ensures only relevant fields are shown in each
section, based on both prefix and search term.
#### Table Actions for Fields
- Each attribute row in the table now includes cell actions, allowing
users to:
- Filter by field value directly from the table.
- Add or remove fields as columns in Discover with a single click.
- These actions improve workflow efficiency and align with Discover’s
interactive capabilities.
#### Integration
- The new overview is integrated into the unified doc viewer, replacing
or enhancing previous attribute display mechanisms.
- Each accordion section uses the `AttributesAccordion` and
`AttributesTable` components.
#### Result
The new attributes overview provides a clear, organized, and filterable
view of all relevant document attributes, improving usability and
consistency across the Observability UI.
<img width="770" alt="image"
src="https://github.com/user-attachments/assets/36fee343-fe63-4c55-ab37-0317a8512abf"
/>
### 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.yml`
```
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
```
## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR relocates few test files from `/src/platform/test` dir that
imports from `@kbn/enterprise-search-plugin`, which is Search solution
plugin.
Before:
```
/src/platform/test/api_integration/guided_onboarding
| - get_guides.ts
| - put_state.ts
```
After:
```
/x-pack/solutions/search/test/api_integration/guided_onboarding
| - get_guides.ts
| - put_state.ts
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds the ability to upload a CSV file with privileged users from
the Entity Analytics pages
## Changes
### Backend
- Added (or completed) the upload CSV route:
`/api/entity_analytics/monitoring/users/_csv`
- Added shared utilities for batching with Node streams
- Added bulk processing actions for the upload
- Parsing users from CSV
- Soft delete for omitted users
- Batch upsert via the bulk API
- Added a check for installing all required privmon resources
### Frontend
- File uploader components
- File validation logic
- Updated EA privmon page to account for the new flow
- Added managing users panels
- open upload flow (same as asset criticality)
## Screen recording
https://github.com/user-attachments/assets/7956f1cf-49e0-4430-8c23-7d6178a15342
## How to test
#### Prerequisite
Make sure you have a CSV file with usernames
Check
[here](https://gist.github.com/tiansivive/0be2f09e1bb380fdde6609a131e929ed)
for a little helper script
Create a few copies where some of the users are deleted, in order to
test soft delete
1. Start up kibana and ES
2. Navigate to Security > Entity Analytics > Privilege User Monitoring
3. Select the `File` option to add data
4. Add one of the CSV files to the open modal and upload
5. Repeat but now upload one of files with the omitted users
Alternatively, testing only the backend only is possible by directly
hitting the API wit curl
```
curl -u elastic:changeme \
-X POST "http://localhost:5601/api/entity_analytics/monitoring/users/_csv" \
-H "kbn-xsrf: true" \
-F "file=@test.csv;type=text/csv"
```
#### Verifying
Easiest way is to use the dev tools to `_search` the privmon users index
with:
```
GET .entity_analytics.monitoring.users-default/_search
```
Look for number of hits and/or use `query` to search for omitted users.
## Remaining work
- [x] API integration tests
- [ ] Batching logic unit tests
- [ ] E2E tests?
---------
Co-authored-by: machadoum <pablo.nevesmachado@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
- anonymization rules shows up correctly in advanced settings, once
registered.
- adds default rules (disabled)
- updates schema, type, and advanced settings description. removes `id`,
`description` and makes `entityClass` required for regex only
Still unregistered for now, but can [register to
view](https://github.com/elastic/kibana/blob/main/x-pack/platform/plugins/private/observability_ai_assistant_management/server/plugin.ts#L24-L25)
To make sure the rules function without having to register the setting
(and have it show in the UI), you can run the below in dev tools:
```
POST kbn:/api/kibana/settings
{
"changes": {
"observability:aiAssistantAnonymizationRules": "[\n {\n \"type\": \"regex\",\n \"pattern\": \"[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\\\.[A-Za-z]{2,}\",\n \"enabled\": true,\n \"entityClass\": \"EMAIL\"\n },\n {\n \"type\": \"regex\",\n \"pattern\": \"https?://[^\\\\s]+\",\n \"enabled\": true,\n \"entityClass\": \"URL\"\n },\n {\n \"type\": \"regex\",\n \"pattern\": \"\\\\b(?:\\\\d{1,3}\\\\.){3}\\\\d{1,3}\\\\b\",\n \"enabled\": true,\n \"entityClass\": \"IP\"\n },\n {\n \"type\": \"ner\",\n \"enabled\": true\n }\n]"
}
}
```
or with kibana config:
```
uiSettings:
overrides:
"observability:aiAssistantAnonymizationRules": |
[
{
"type": "regex",
"pattern": "[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[A-Za-z]{2,}",
"enabled": true,
"entityClass": "EMAIL"
},
{
"type": "regex",
"pattern": "https?://[^\\s]+",
"enabled": true,
"entityClass": "URL"
},
{
"type": "regex",
"pattern": "\\b(?:\\d{1,3}\\.){3}\\d{1,3}\\b",
"enabled": true,
"entityClass": "IP"
},
{
"type": "ner",
"enabled": true
}
]
```
---------
Co-authored-by: Arturo Lidueña <arturo.liduena@elastic.co>
Partially addresses
https://github.com/elastic/observability-dev/issues/4492
This change makes a set of adjustments to the quickstart onboarding
flows to prepare them for Logs Essentials product tier:
* Hides the "Application" onboarding category
* Removes mentions of metrics ingestion from all quickstart onboarding
flows (Host Auto-detect, Host OTel, K8S Elastic Agent, K8S OTel, Cloud
Firehose)
* Disables creation the CloudWatch metric stream for the Firehose flow
* Hides the application instrumentation step for K8S OTel flow
* Changes layout of the onboarding landing page to 3 columns
This change don't disable actual metric collection on the flows (except
Firehose), only changes the copy. Disabling metrics requires
coordination with other teams and will be done in separate PRs.
## How To Test
* Modify `config/serverless.oblt.dev.yml` to include:
```yaml
pricing.tiers.products:
- name: observability
tier: logs_essentials
```
* Run Kibana locally
* Click through all categories on the onboarding landing page and make
sure none of the quickstart flows mention metrics collection
* Enter individual flow pages and also make sure there no mention of
metrics collection
* Enter K8S Otel flow and make sure there is no application
instrumentation step
Additionally, switch back to `tier: complete` in
`config/serverless.oblt.dev.yml` and make sure that onboarding flows
looks as usual.
## Summary
To prepare for demos, we manually set all integrations `isUniverified`
status to false, so this is now reverting that change and enabling the
integration to show its true status.
Reverts https://github.com/elastic/kibana/pull/219277
## Summary
Closes https://github.com/elastic/kibana/issues/213337
When requests to install a package as part of the logic ensuring that a
package is installed are fired concurrently, the second request fails
with a 409 `version_conflict_engine_exception`, which causes flakiness
in tests. Ignoring these errors in transform installs was already
attempted in https://github.com/elastic/kibana/pull/177380. This PR adds
a retry mechanism directly into the package install to consolidate the
flow.
### Identify risks
Low probability risk of slower package policy creation.
## Summary
Resolves https://github.com/elastic/kibana/issues/211534
This PR adds a recurring task which will
- run once every day
- collect maintenance windows which have expiration date within 1 week
- updates expiration date to +1 year if it is recurring
- generate events for the next 1 year
- adds new events to maintenance window
### Checklist
- [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
### How to test
- Set expiration date to less than 1 week before creating maintenance
windows: update line 70 `expirationDate = moment().utc().add(1,
'year').toISOString();` to `expirationDate = moment().utc().add(5,
'days').toISOString();` in the file
`x-pack/platform/plugins/shared/alerting/server/application/maintenance_window/methods/create/create_maintenance_window.ts`
- Create maintenance windows with different scenarios (recurring, non
recurring, etc.)
- Update task schedule to run every five minutes to test: set `{
interval: '1d' }` to `{ interval: '5m' }` in file
`x-pack/platform/plugins/shared/alerting/server/maintenance_window_events/task.ts`
- Verify the task ran successfully
- Verify maintenance windows are updated properly with new expiration
date and new events
### Flaky test runner:
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/8358
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/222591
This PR adds the link to the “View related error” / "View X related
errors" badge in the full-screen waterfall.
Unlike the same badge in APM, here it’s handled as a native `href`, so
the user keeps the option to open it in a new tab—avoiding loss of
context from Discover if they prefer.
**Highlights**
* Created `ApmErrorsContextService` to access the configured APM error
indices.
* I had considered merging this with `TracesContextService` into a
shared `ApmContextService` (for both traces and errors), but decided to
keep them separate to avoid mixing methods and logic. Totally open to
revisit this if anyone feels that a shared service would make things
cleaner or more maintainable.
* Created `DataSourcesProvider` to easily access the relevant indices
within our flyouts.
* Built the Discover URL using the locator, preparing an ESQL query to
filter by `span.id` and `trace.id` across both error and log indices.
* Added `getRelatedErrorsHref` as a prop to `TraceWaterfallEmbeddable`,
allowing us to pass the errors URL directly.
* Why this approach instead of triggering a callback to the parent? We
wanted to preserve native link behavior (e.g., open in new tab), which
wouldn't work if navigation was handled via `navigateTo` from the
parent.
* Created `EmbeddableRelatedErrors` to handle the badge link.
* Agreed with the EUI team to cast the `href` as `any`, since due to the
component nesting in the waterfall, it was the cleanest way to make the
native link behavior work in this context.
* Created `ExitFullScreenButton` wrapper to enable exiting full-screen
mode with the `ESC` key.
https://github.com/user-attachments/assets/d3e476ae-ee10-410f-b003-02521dc35e13
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Carlos Crespo <crespocarlos@users.noreply.github.com>
Co-authored-by: Milosz Marcinkowski <38698566+miloszmarcinkowski@users.noreply.github.com>
Wired streams are not available as a regular feature yet, but for
internal testing we should make onboarding to them as simple as
possible.
However, when using the observability onboarding flows, the generated
api keys to not grant permission to write to `logs,logs.*`. This PR
extends the index patterns to do so.
## Summary
Replaces enzyme with React Testing Library in a Data Set Quality test.
### Test instructions
It can be validated through CI but you can run it manually through:
```
npx jest --config=x-pack/platform/plugins/shared/dataset_quality/jest.config.js ----testPathPattern=dataset_quality_details_link.test
```
Closes https://github.com/elastic/kibana/issues/223020
Closes https://github.com/elastic/kibana/issues/208450
## Summary
This PR adds ESQL autocomplete support to Console. The ESQL suggestions
are only displayed inside triple-quotes queries (`"query": """...`).
**How to test:**
1. Open Kibana and load some data (e.g. the sample data sets).
2. Navigate to Dev Tools -> Console and type in the following query:
```
POST _query
{
"query": """ """
}
```
3. Verify that ESQL suggestions are displayed inside the triple quotes
and work as in the ESQL editor in Discover. Example ESQL query:
`FROM kibana_sample_data_ecommerce | WHERE order_date >= ?_tstart AND
order_date <= ?_tend | LIMIT 10`
4. Verify that no ESQL suggestions are displayed outside triple-quotes
queries
5. Verify that no Console suggestions are displayed inside triple-quotes
queries
6. Verify that the functionality also works in embeddable Console.
https://github.com/user-attachments/assets/63f1b82d-50a2-4af4-b5ad-812eab9a55a5
## Release notes
These changes add autocompletion for ESQL query requests in Console.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Co-authored-by: Jean-Louis Leysens <jloleysens@gmail.com>
## Summary
issue: https://github.com/elastic/security-team/issues/11535
Adds the switch to toggle data errors highlighting in the ESQL editor
when used inside the automatic migrations.
## Implementation details
- A new `dataErrorsControl` property is exposed by the ESQL editor
component to allow controlling the "data errors" switch state from
outside. The type is defined as follows:
```ts
export interface DataErrorsControl {
enabled: boolean;
onChange: (value: boolean) => void;
}
```
- The ESQL editor is responsible for:
- Rendering the switch according to the `dataErrorsControl` state
provided.
- Hide the data errors highlighting when the dataErrorsControl.enabled
is `false` (strictly)
- Not rendering the switch when `dataErrorsControl` is not provided, and
highlighting data errors.
- The Automatic migrations flyout in Security that uses the ESQL editor
is responsible for:
- Managing the state of the `dataErrorsControl` provided to the editor.
- Persist the state to local storage to be shared between all the
instances of the ESQL editor on that page.
### Considerations
- Managing the "data errors" switch state internally in the ESQL editor
would make it hard to apply this behaviour (including local storage
persistence) only in the Automatic migrations page in Security.
- The "data errors" validation is performed even when the highlighting
is disabled. The number of errors is necessary anyway, to know whether
the "N errors" popover button in the footer (where the switch is
displayed) should be rendered or not.
## Screenshots
Data errors enabled:
Data errors disabled (highlights syntax errors only):
### Edge cases
#### No syntax errors
When there are data errors but no syntax error, and the switch is off,
we render the `0 errors` popover button:
just to be able to turn the switch on and see the underlying data
errors:
#### No errors
When there is no error at all, we hide the `N errors` popover button,
regardless of the switch value:
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
## Summary (Updated May 16)
* [[Security Solution] [Elastic Defend] Add
disable_origin_info_collection in endpoint advanced policy
setting](https://github.com/elastic/kibana/pull/222030)
Last week, we merged the above PR. However, we decided to change the
advanced policy from opt-out to opt-in after extensive discussions.
Thus, this PR changes the following fields available as advanced policy
options in Elastic Defend.
Also, we will set `file.origin_info_collection` to `true` as default.
* `windows.advanced.events.file.disable_origin_info_collection`
* `windows.advanced.events.process.disable_origin_info_collection`
* `windows.advanced.events.image_load.disable_origin_info_collection`
to
* `windows.advanced.events.file.origin_info_collection`
* `windows.advanced.events.process.origin_info_collection`
* `windows.advanced.events.image_load.origin_info_collection`
This advanced policy will allow the following fields in File, Process,
and ImageLoad events to be included whenever needed.
* `{ file | process| dll }.origin_url`
* `{ file | process| dll }.origin_referrer_url`
* `{ file | process| dll }.Ext.windows.zone_identifier`
I apologize for requesting further adjustments to the settings so soon
after the initial PR was merged.
## Release note
{elastic-defend} Adds advanced policy options that let users include
origin information from file, process, and image load events when
needed.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] 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)
- [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
Closes https://github.com/elastic/kibana/issues/224275
**Context:** In https://github.com/elastic/kibana/pull/222273, we added
restrictions to the "Reporting redirect app" to make sure it could not
be abused by using unexpected locator types (such as the short URL
locator or the "legacy" locator type) when triggering redirects in the
Reporting headless browser. The restrictions are on the basis of a list
of allowed locator types, which should be a list of every analytical app
that supports Reporting.
**Problem:** Unfortunately that added a regression to Canvas PDF
reporting, because the allow-list for locator types neglected to include
the Canvas locator type.
This PR solves the problem by adding the Canvas locator type to the set
of allowed locator types.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Similar to https://github.com/elastic/kibana/pull/219617, this PR fixes
an issue with the `BedrockConnector` not using the configured
`xpack.actions.proxyUrl`.
To test, add the following
[`xpack.actions.proxyUrl`](https://p.elstc.co/paste/DaM71BUP#iHki8gmY4-LZcfQD0ja6HeMHknuvpEvQtSbapcAEOXb)
to your `kibana.dev.yml`, then create a Bedrock connector and confirm in
the Kibana server logs that the configured proxy is being used and a
successful response is returned. Sample `debug` logs look something
along the lines of:
```
[2025-06-16T11:59:36.282-06:00][DEBUG][plugins.actions.bedrock] executing action .bedrock:sonnet-3-7: Sonnet 3.7 (Bedrock)
[2025-06-16T11:59:36.286-06:00][DEBUG][plugins.actions] Request to external service. Connector Id: sonnet-3-7. Connector type: .bedrock Method: post. URL: https://bedrock-runtime.us-east-1.amazonaws.com/model/us.anthropic.claude-3-7-sonnet-20250219-v1%3A0/invoke
[2025-06-16T11:59:36.286-06:00][DEBUG][plugins.actions] Creating proxy agents for proxy: https://PROXY_URL/
```
Be sure to enable debug logging for the actions plugin ala:
```
logging:
loggers:
- name: plugins.actions
level: debug
```
### 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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Steph Milovic <stephanie.milovic@elastic.co>
## Summary
The following changes are included in this PR in support of Endpoint
Management spaces (currently behind a feature flag):
- Migration of response actions will now check the response action
request index to ensure it has the required mappings
- Should help mitigate issue for customers that might not have the 9.1
endpoint package installed
- Migration of artifacts will check Endpoint Exceptions to ensure they
have the Global `tag`
- Response action clients (base class) was updated to ensure that, if
space awareness feature flag is enabled, the action request index has
required mappings
- Artifact Create and Artifact Update server-side extensions were
updated for Endpoint exceptions to ensure they the Global Artifact `tag`
Resolves https://github.com/elastic/kibana/issues/221447
## Summary
This PR fixes a UI bug when editing an ES query rule that's grouping
over a runtime field.
### Checklist
Check the PR satisfies following conditions.
- [ ] [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
### To verify
1. Create a DSL ES Query rule and include a runtime field. Here is an
example that I like to use
```
"runtime_mappings": {
"day_of_week": {
"type": "keyword",
"script": {
"source": "emit(doc['@timestamp'].value.dayOfWeekEnum.getDisplayName(TextStyle.FULL, Locale.ENGLISH))"
}
}
},
```
2. Select that field to groupover and save your rule
3. Edit your rule and click on `GROUPED OVER`, verify that there is no
error and the runtime field is selected
resolves https://github.com/elastic/kibana/issues/221252
Ensure alert field values added from grouping information are the right
cardinality. Previously, array typed fields were assigned strings and
the string characters were split into an array by down-stream
processing.
## Summary
Improving logging for remote synced integrations feature.
While trying the new feature on cloud I noticed that we don't have
logging covering some early returns and warnings in the code. This makes
hard to debug errors as we only see the task exiting without much
context on what happened - example below:
<img width="2866" alt="Screenshot 2025-06-17 at 16 27 25"
src="https://github.com/user-attachments/assets/7c47921b-7b48-419b-b801-2db2933417a4"
/>
### 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
Adds some control over the table in enrichment mode:
* Control for columns (expose the data grid column selector and sorter)
* Multiline rows (switch like in discover, auto / custom (with number of
lines selectable)
<img width="398" alt="Screenshot 2025-06-04 at 12 30 39"
src="https://github.com/user-attachments/assets/6a978e0f-f2f3-4362-b5d7-92989db858d2"
/>
<img width="462" alt="Screenshot 2025-06-04 at 12 30 54"
src="https://github.com/user-attachments/assets/3a637fe8-5749-4335-9687-783fda0e57fb"
/>
The biggest complexity of this PR is in the management of explicit
column selection and preserving the "smart" mode of showing relevant
columns. It uses the following approach:
* There are three pieces of state: explicitly disabled columns,
explicitly enabled columns, specified column order
* When a column is enabled/disabled/moved in the popover, the state is
updated accordingly
* The displayed columns are determined as follows:
* Determine the columns we would show in the "smart" mode:
* field the processor operates on plus detected fields
* or just the field the processor operates on if it's grok and it
doesn't overwrite the source field (because of the highlighting)
* or all columns if there is no processor
* Apply the expressed user intent (this is the new part):
* Remove explicitly disabled columns
* Add explicitly enabled columns
* Order that set of columns based on the specified order
* Cancelling the editing of a processor resets the state back to default
## Concerns
As this is leveraging the default functionality from the data grid,
there are only minimal options to control the behavior. A couple things
are a little weird:
* "Hide all" hides everything, which renders an empty table - I wouldn't
have added this option when I would have created the popover from
scratch. Maybe that's even OK (can be used to "reset" and only show a
couple columns afterwards)
* The order of non-enabled columns is not passed in the callback, so
there is no way to preserve them - reordering them doesn't have an
effect and enabled columns are always shown at the beginning:
* There is no indicator whether a column is shown because of "auto" or
because it got explicitly enabled/disabled - this is hidden state which
is something that's not great in general
I think we can solve this in a more holistic way, but the effort would
be much higher and I don't think it's worth rebuilding the data grid
toolbar for this - the idea for the main use case of this is that the
auto-mode is good enough for 95% of cases and in cases it isn't, it's
possible to quickly pop in an additional column, so we don't need a more
elaborate field selection process like we have it in Discover.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Saved object migrations should not be modified. They convert legacy
saved object shapes into less-legacy shapes. Since legacy saved object
shapes are not changing, the code migrating them should not be changing
as well.
The following steps where taken to create this PR
* replaced main `dashboard/server/dashboard_saved_object` folder with
8.16 branch `dashboard/server/dashboard_saved_object` folder
* Replaced `dashboard/common` imports with copies from
`dashboard/common` 8.16 branch. Moved copied code into
`dashboard/server/dashboard_saved_object` folder so migrations contain
independent copies of utility functions and types.
* Suffixed types with `810` since the migration system was deprecated in
8.10 and this is the version of the saved objects returned from
migrations.
* Fixed typescript errors.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
**Resolves: https://github.com/elastic/kibana/issues/223399**
## Summary
This PR fixes an error on the "Add Elastic rules" page. The error is
shown when running a local dev environment from `main` branch and going
to the "Add Elastic rules" page.
<img width="1741" alt="Screenshot 2025-06-10 at 11 28 19"
src="https://github.com/user-attachments/assets/f8f81f88-3749-491f-bcdb-cd51f465bda6"
/>
## Changes
PR updates methods of `PrebuiltRuleAssetsClient` to split requests to ES
into smaller chunks to avoid the error.
## Cause
Kibana makes a search request to ES with a filter that has too many
clauses, so ES rejects with an error.
More specifically, `/prebuilt_rules/installation/_review` route handler
calls `PrebuiltRuleAssetsClient.fetchAssetsByVersion` to fetch all
installable rules. To do this, we construct a request with thousands of
clauses in a filter. ES counts the number of clauses in a filter and
rejects because it's bigger than `maxClauseCount`. `maxClauseCount`
value is computed dynamically by ES and its size depends on hardware and
available resources
([docs](https://www.elastic.co/guide/en/elasticsearch/reference/8.18/search-settings.html),
[code](https://github.com/elastic/elasticsearch/blob/main/server/src/main/java/org/elasticsearch/search/SearchUtils.java)).
The minimum value for `maxClauseCount` is 1024.
## Why it didn't fail before
Two reasons:
1. ES changed how `maxClauseCount` is computed. They've recently merged
a [PR](https://github.com/elastic/elasticsearch/pull/128293) that made
queries against numeric types count three times towards the
`maxClauseCount` limit. They plan to revert the change in [this
PR](https://github.com/elastic/elasticsearch/pull/129206).
2. Prebuilt rule packages are growing bigger with each version,
resulting in a bigger number of clauses. I've tested behaviour with ES
change in place on different package versions:
- 8.17.1 (contains 1262 rule versions) - no "too many clauses" error
- 8.18.1 (contains 1356 rule versions) - causes "too many clauses" error
- 9.0.1 (also contains 1356 rule versions) - causes "too many clauses"
error
The precise number of versions that start to cause errors is 1293 on my
laptop.
So even if ES team rolls back their change, we still need to make sure
we don't go over the limit with ever-growing prebuilt rule package
sizes.
Adds a neat shiny Borealis-ish effect that shows up when a new panel is added to a Dashboard
Co-authored-by: Marta Bondyra <4283304+mbondyra@users.noreply.github.com>
## Summary
This fixes the `api/oas` route that was broken due to missing
`security.authz` param.
In #220231 the `security.authz` param is asserted as non-null but when
the route is assigned directly from the `internalSetup.server`, this is
not the case. I believe this is the only such case where this applies.
### Checklist
- [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.
---------
Co-authored-by: Elena Shostak <165678770+elena-shostak@users.noreply.github.com>
## Summary
This PR re-aligns the names used to maintain consistency across the
codebase:
- **SiemMigrationTaskStatus**:
- New `INTERRUPTED` status for when the process was automatically
aborted (server shutdown scenario).
- Use the `STOPPED` status for when the user manually aborts the process
(`/stop` API route via `Stop` button in the UI)
- Avoid using the `ABORTED` as a status since it's confusing. Both of
the scenarios above end up aborting the process.
- **last_execution**:
- `is_aborted` renamed to `is_stopped` for consistency with
`SiemMigrationTaskStatus.STOPPED`.
- `ended_at` renamed to `finished_at` for consistency with
`SiemMigrationTaskStatus.FINISHED`.
There shouldn't be any change in the behaviour.
## Summary
This PR addresses a UI inconsistency in the Risk Score Configuration
section where clicking the "Discard" button after toggling
includeClosedAlerts or changing the date range did not correctly reset
the UI state to the last saved values.
The core issue was due to relying on React state and useEffect to track
and restore the saved state, which failed when parent props did not
change. The changes resolves the issue by:
- Introducing a useRef (savedStateRef) to persist the last saved
configuration.
- Updating savedStateRef only on successful "Save".
- Using savedStateRef to restore toggle and date range when "Discard" is
clicked.
- This ensures consistent behavior whether or not the parent component
re-renders.
Screen recording for ref :
https://github.com/user-attachments/assets/1bb59df6-35c0-4cbc-a7b0-a29affdf7327
### Testing Steps
#### Initial Load:
Open the Risk Score Configuration section.
Verify that the includeClosedAlerts toggle and date range are
initialized correctly.
#### Toggle & Discard:
Click the toggle to change its state.
Verify that the bottom bar ("Save" / "Discard") appears.
Click Discard.
Confirm that the toggle resets to its original state.
#### Toggle & Save:
Click the toggle to change its state.
Click Save.
Confirm success toast appears.
Refresh the page or revisit the config — the toggle should reflect the
newly saved state.
Change Date Range & Discard:
Change the date range via the super date picker.
#### Click Discard.
Confirm the date range resets to the last saved value.
Change Both & Save:
Change both toggle and date range.
Click Save.
Confirm the new configuration is persisted correctly.
### 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)
- [ ] 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
- [ ] 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
Cleanups further the operators. no need to hardcode the signatures
there, we have them already from ES
### 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
---------
Co-authored-by: Vadim Kibana <82822460+vadimkibana@users.noreply.github.com>
## Summary
This PR updates the Dev Console autocomplete for pinned retriever in the
retriever spec.
**Screenshot:**
_Please see attached screenshot showing `pinned retriever options` in
the autocomplete suggestions._
<!--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 |
|---|---|---|---|
|
[@elastic/monaco-esql](https://redirect.github.com/elastic/monaco-esql)
([source](https://redirect.github.com/elastic/highlightjs-esql)) |
dependencies | patch | [`^3.1.1` ->
`^3.1.2`](https://renovatebot.com/diffs/npm/@elastic%2fmonaco-esql/3.1.1/3.1.2)
|
---
### Release Notes
<details>
<summary>elastic/highlightjs-esql
(@​elastic/monaco-esql)</summary>
###
[`v3.1.2`](7a3da16573...ffd1628c1e)
[Compare
Source](7a3da16573...ffd1628c1e)
</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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkVTUUwiLCJiYWNrcG9ydDp2ZXJzaW9uIiwicmVsZWFzZV9ub3RlOnNraXAiXX0=-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
## Summary
Closes https://github.com/elastic/kibana/issues/208017
Added test that starts 2 clusters, sets up remote ES output with sync
feature, sets up CCR between the clusters, and verifies the sync
installs the packages.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
fix https://github.com/elastic/kibana/issues/223536
It wasn't possible to change the page index in the Inspector Data View.
The table was using the `onTableChange` callback, coming from the
`useEuiTablePersist` hook in the wrapping function, in the `onChange`
prop of the `EuiTable` instead of being attached to the `onTableChange`
prop.
When using the `onChange` the EuiTable leave all the pagination/size etc
handling to the consumer, where the `onTableChange` is just a callback
related to the changes, used within the `useEuiTablePersist` to store
some configuration across tabels.
The PR fixes the `onTableChange` callback to the correct prop.
A functional test was also added to check the pagination works within
Lens. I haven't used the existing `inspector.ts` functional tests
because they where within the Legacy Visualize.
I've checked the usage of `useEuiTablePersist` and the returned
`onTableChange` and is correctly used everywhere except for ESQL query
history that doesn't seems to have enabled pagination cc @stratoula
90f65c3dba/src/platform/packages/private/kbn-esql-editor/src/editor_footer/history_starred_queries.tsx (L383)
---------
Co-authored-by: Marco Liberati <dej611@users.noreply.github.com>
## Summary
Partially addresses https://github.com/elastic/kibana/issues/215186
When we insert the *marker* for autocomplete purposes and then remove it
subsequently from the AST, we know the following facts: (1) the marker
is inserted at the end of the query (most efficient to look for it from
the end of the query); (2) we insert only a single marker (once we find
the marker, we don't need to look further), and (3) to remove the marker
AST node from the tree we need its parent node. Below `Walker`
improvements will help with effectively finding and removing the marker:
- Adds ability to traverse AST in reverse order, using `{ order:
'backward' }` walker option.
- Adds ability to terminate traversal early using `walker.abort()` call.
- Now all visitor callbacks also receive the parent node in addition to
the current node `visitSource(source, parent)`.
- Adds static methods to find node parent and a list of all parents:
- `Walker.parent(tree, node): Node`
- `Walker.parents(tree, node): Node[]`
### 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
This PR adds a new share integration type (i.e. the `exportDerivative`).
This integration is a special one that is only to be used in a scenario
where a team would like to offer some extra functionality that depends
on the availability of some `export` integration. Specifically because
of the way this has been coupled to be presented to the user the
`exportDerivative` type integration would only be displayed to the user
when at least one export integration exists.
This particular integration is also much more flexible, in that it only
accepts a label to denote what should be rendered to the user, and a
freeform component that will be rendered into the flyout that will in
turn open when the provided label is clicked.
One might configure an integration for this like so;
```ts
share.registerShareIntegration<ExportShareDerivatives>({
id: 'scheduledReporting',
groupId: 'exportDerivatives',
config: () => ({
label: ({ openFlyout }) =>
React.createElement(
EuiButton,
{ iconType: 'calendar', onClick: openFlyout },
'schedule report'
),
flyoutContent: ({ closeFlyout , flyoutRef }) => {
return React.createElement(
EuiButton,
{
iconType: 'calendar',
},
'Click me'
);
},
}),
});
```
The following config would produce the following experience;
<!--
### 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)
- [ ] 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
- [ ] 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
-->
## Summary
Add `initialDelay` option to the `tryWithRetries` retry service. This is
a common usecase across Kibana where we'd need to wait a little bit
before ES fully refreshes the indexed data to test a specific behavior.
Added a test case to test the new flag as well.
The PR updates the UI counters test case as an example where i needed
this to replace `delay(..)` with the `initialDelay` flag. (original PR
https://github.com/elastic/kibana/pull/224151)
closes https://github.com/elastic/kibana/issues/98240
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
- addresses https://github.com/elastic/kibana/issues/216891
- introduces pages to ES|QL preview logged requests view
<details>
<summary> PREVIEW of pages</summary>
<img width="736" alt="Screenshot 2025-04-15 at 17 47 06"
src="https://github.com/user-attachments/assets/07601a51-7236-4121-a04b-67b964040499"
/>
</details>
We retrieve _id of underlying events for non-aggregating queries.
If some alerts were deduplicated, we can filter out these ids in next
requests.
Example query:
```JSON
POST _query/async
{
"query": "from close* | limit 101",
"filter": {
"bool": {
"filter": [
{
"range": {
"@timestamp": {
"lte": "2025-04-02T16:39:45.965Z",
"gte": "2013-11-04T22:39:45.965Z",
"format": "strict_date_optional_time"
}
}
},
{
"bool": {
"must": [],
"filter": [],
"should": [],
"must_not": [
{
"ids": {
"values": [
"test-1"
]
}
}
]
}
}
]
}
}
}
```
Deduplicated id "test-1" will be filtered out form results.
### Corner case with mv_expand
If some of the expanded results are not in the first page, the rest can
be missed if we exclude event id in subsequent requests. To mitigate
this, the last id on a page won't be excluded in the next page request.
However, if ES|QL query will be sorted by expanded field, it can lead to
missing alerts.
We also won't be creating more than max_signals + 1 alerts from a single
expanded document
Tracks https://github.com/elastic/kibana/pull/221566
Closes https://github.com/elastic/security-team/issues/12824
With this change, whenever a user selects the Elastic LLM connector
within the Automatic Troubleshooting feature, they'll see a callout
informing them about the potential costs of using it. Once the callout
is acknowledged, it will be dismissed and the closed state will be
stored in local storage, so it won’t appear again on future visits.
To enable EIS locally:
```
export VAULT_ADDR=https://secrets.elastic.co:8200/
vault login --method=oidc
node scripts/eis.js
```
and run ES server with provided env + start kibana with .dev.yaml entry
from the output of the command above.
https://github.com/user-attachments/assets/51a2ce77-ed25-4611-9d62-72e9d09bb789
---------
Co-authored-by: Angela Chuang <yi-chun.chuang@elastic.co>
Co-authored-by: Angela Chuang <6295984+angorayc@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: florent-leborgne <florent.leborgne@elastic.co>
Co-authored-by: Viduni Wickramarachchi <viduni.ushanka@gmail.com>
## Summary
This PR includes grouping information in the alert document for no data
alerts.
### 🧪 How to test
- Trigger a no data alert for the custom threshold rule which has a
group by field
- Check the alert document, you should see a `kibana.alert.grouping` +
grouping field name for the related group value
## Summary
[[Issue](https://github.com/elastic/kibana/issues/221111)](https://github.com/elastic/kibana/issues/221111)
Gaps can get stuck in the `in-progress` state if a rule is
backfill-executed with failures.
### Current behavior:
Let's say we have a gap from `12:00–13:00`.
When the gap is initially detected, it has the following state:
```
filled_intervals: []
unfilled_intervals: [12:00–13:00]
in_progress_intervals: []
```
When a backfill starts, we set `in_progress_intervals` to the range that
overlaps with the backfill. We also remove that range from
`unfilled_intervals`:
```
filled_intervals: []
unfilled_intervals: []
in_progress_intervals: [12:00–13:00]
```
After the backfill is successfully executed, we move the range to
`filled_intervals` and clear `in_progress_intervals`:
```
filled_intervals: [12:00–13:00]
unfilled_intervals: []
in_progress_intervals: []
```
However, if the backfill fails, we want to remove the range from
`in_progress_intervals` and move it back to `unfilled_intervals`. The
problem is that we cannot simply do this because there might be other
overlapping backfills still in progress for the same gap. In the case of
a successful execution, this isn’t an issue, as the range is moved to
`filled_intervals`.
When a backfill fails, we refetch all overlapping backfills for the gap
to recalculate the `in_progress_intervals`.
### Problem
In the current implementation, we're updating the gaps **before**
deleting the failed backfill. This causes the recalculated
`in_progress_intervals` to still include the failed backfill’s range,
resulting in a stale state.
### Fix
We should **first delete** the failed backfill, and **then** update the
gap. This ensures that the recalculated `in_progress_intervals` reflect
only the remaining active backfills.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Resolves https://github.com/elastic/kibana/issues/208740
## Summary
This error message comes from the code where we drop the oldest
recovered alerts from being tracked in the task state when there are
more than 1000 (or alert limit) recovered alerts. The flapping refactor
fixed this specific error, but I noticed that the alert documents
weren't being updated before the alerts were dropped. This PR just moves
this logic to the function that gets all the alerts to serialize in the
task state, which happens after the alert documents are updated.
### Checklist
Check the PR satisfies following conditions.
- [ ] [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
### To verify
1. Set `xpack.alerting.rules.run.alerts.max: 3` in kibana.yml
2. Start kibana and create a rule that will generate 3 alerts
3. Stop kibana and set the max alert limit to 2 in kibana.yml
4. Start kibana and update the conditions to recover the alerts. Because
there are 3 alerts recovering and we can only track 2, one alert will be
dropped from the task state.
5. Verify that all the alerts are marked as recovered. Let the rule run
to verify that one of the alert's alert document is no longer updated.
Revisit `waitForWithTimeout` to use 5 retries and an initial waiting
time
closes https://github.com/elastic/kibana/issues/98240
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
# Cloud Connector Behavior Fix and Edit Mode Lockdown
## Summary
This PR introduces the following updates:
- **Disables the Cloud Connectors credentials type** when editing an
existing integration.
- **Hides the Cloud Connector option** in the UI when an agentless
integration was originally created using the `cloud-connector` option.
<Callout type="info" title="Bug Fix">
Fixes an issue where Cloud Connectors did not appear on ESS deployments
due to incorrect cloud ID resolution.
</Callout>
## Technical Details
- Previously, the implementation relied on `cloud.deploymentId` from the
`CloudSetup` interface, which is not available during runtime in the
browser.
- This update uses the `CloudStart` interface in the React component,
which exposes the `cloudId`.
### `cloudId` Format and Decoding
The `cloudId` is a base64-encoded string structured like this:
Steps:
1. Decode the base64 portion of the `cloudId`.
2. Extract:
- **Cloud provider** (e.g., `aws`, `gcp`, `azure`)
- **Deployment ID**
This enables logic to:
- Determine the environment (e.g., ESS or Serverless)
- Dynamically enable or disable Cloud Connector options based on
platform context
## Impact
- Correctly displays Cloud Connector credentials in ESS deployments.
- Prevents credential type changes in edit mode, ensuring integrity of
saved integration configs.
<img width="994" alt="image"
src="https://github.com/user-attachments/assets/7e36297e-52e7-41ec-b57a-dd373e31c11b"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Main ticket: https://github.com/elastic/security-team/issues/12827
These changes fix the issue with the locally running models over the
`HTTP` server. We do always use `HTTPS` agent even when URL uses HTTP
protocol. This leads to an error:
```
TypeError: Protocol "http:" not supported. Expected "https:"
at new ClientRequest (node:_http_client:187:11)
at request (node:http:101:10)
at AsyncLocalStorage.run (node:async_hooks:346:14)
at AsyncLocalStorageRunContextManager.with (/kibana/node_modules/elastic-apm-node/lib/instrumentation/run-context/AsyncLocalStorageRunContextManager.js:57:36)
at Instrumentation.withRunContext (/kibana/node_modules/elastic-apm-node/lib/instrumentation/index.js:1126:30)
at wrappedHttpRequest (/kibana/node_modules/elastic-apm-node/lib/instrumentation/http-shared.js:292:21)
at /kibana/node_modules/node-fetch/lib/index.js:1478:15
at new Promise (<anonymous>)
at fetch (/kibana/node_modules/node-fetch/lib/index.js:1447:9)
at OpenAI.fetchWithTimeout (/kibana/node_modules/openai/src/core.ts:580:18)
at OpenAI.makeRequest (/kibana/node_modules/openai/src/core.ts:476:33)
at OpenAIConnector.invokeAsyncIterator (openai.ts:418:22)
at Object.executor (executor.ts:99:18)
at action_executor.ts:504:23
at ActionExecutor.execute (action_executor.ts:153:12)
at chat_openai.ts:162:28
at RetryOperation._fn (/kibana/node_modules/p-retry/index.js:50:12)
```
### To test
Steps to reproduce the behavior:
1. Run locally hosted model and make sure that the chat completion url
uses the HTTP protocol
2. Add OSS model via Other (OpenAI Compatible Service) provider
3. Turn streaming ON
4. Try to chat via AI Assistant
Thanks @stephmilovic helping to solve the issue!
Resolves https://github.com/elastic/kibana/issues/222426
## Summary
Addresses a bug in the alert deletion task scheduling where
- if the task is already running for a space, scheduling it again would
show a success toast and no indication that nothing had been scheduled
- if the task was already running for a space, scheduling it in another
space would show a success toast and no indication that nothing had been
scheduled.
This PR updates the schedule logic to check whether any alert deletion
tasks were already running for the current space. If any tasks were
running, it will return a descriptive message to the user indicating
this was the case. If a task was running but not for the current space,
another alert deletion task will be scheduled.
Also adds a `Technical preview` badge to the feature:
<img width="375" alt="Screenshot 2025-06-11 at 9 08 58 AM"
src="https://github.com/user-attachments/assets/32352db4-0eb2-4276-b97d-c230bcb306f9"
/>
<img width="608" alt="Screenshot 2025-06-11 at 9 09 05 AM"
src="https://github.com/user-attachments/assets/1e7869cd-9a6b-4549-a198-ecaee898de91"
/>
The test cases in copy_panel_to are better suited to unit tests. This PR
removes the functional test copu_panel_to and replaces the test cases
with unit tests.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Devon Thomson <devon.thomson@elastic.co>
This PR upgrades Puppeteer version to v24.10.1.
Tested locally, works as expected:
<img width="968" alt="Screenshot 2025-06-14 at 02 28 49"
src="https://github.com/user-attachments/assets/52ede4a6-d342-45f6-9fdf-5a01ce77fb47"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Alexi Doak <109488926+doakalexi@users.noreply.github.com>
Co-authored-by: Alexandra Doak <alexandra.doak@elastic.co>
## Summary
Legacy actions context: https://github.com/elastic/kibana/issues/112327
This PR modifies legacy SIEM action migration logic to migrate actions
in bulk, significantly improving performance. Response time and # of
requests to ES for SIEM rule management HTTP APIs are both significantly
reduced. When tested on 800 rules, this saves about 1-1.5 seconds per
bulk API call and eliminates hundreds of individual requests to
Elasticsearch. Bulk disable for example goes from taking ~3.3 seconds to
~2.3 seconds, and the APM transaction for the API call no longer drops
spans due to hitting the max span limit.
## Testing
I added a helper function in the quickstart tooling,
`createRuleWithLegacyAction`, to make it easier to get started with
manual testing. The function creates a connector, a rule, and then a
legacy action referencing the connector and the rule. The legacy action
(a `siem.notification` type rule) and rule can be viewed in the alerting
SO index via dev tools:
```
GET .kibana_alerting_cases/_search
{
"query": {
"bool": {
"filter": {
"term": {
"type": "alert"
}
}
}
}
}
```
Viewing the rule details via the Security Solution UI should display
only one rule with the action as part of the rule. After making any kind
of change to the rule (enable, disable, update, etc), the dev tools
command above should show only a single rule with the action inside the
rule instead of as a separate `siem.notification` type rule.
---------
Co-authored-by: Maxim Palenov <maxim.palenov@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
PR adds migration of Response Actions and Artifacts when the space
awareness feature flag is enabled. Changes include:
- New saved object type (`security:reference-data`) to keep internal
data/information used by security solution. Currently being used to keep
migration state for both the Artifacts and Response actions migrations
- Two records will be populated in this new saved object related to the
migration being introduced here:
- ID: `SPACE-AWARENESS-ARTIFACT-MIGRATION` - keeps state information
about migration of Artifacts (see below for example)
- ID: `SPACE-AWARENESS-RESPONSE-ACTIONS-MIGRATION` - keeps state
information about migration of response actions (see below for example)
- NOTE: my goal was to also introduce a `client` for working with
internal reference data, but due to timing constraints, that will be
done at a later time
- Adds migration for Endpoint artifacts (Trusted applications, Event
filters, Blocklists, Host isolation exceptions and Endpoint exceptions)
to add the `spaceOwnerId:default` to all artifact records
- Adds migration for Response Action Requests (both Elastic Defend and
external EDRs) to populate `originSpaceId` as well `agent.policy.*`
fields.
- NOTE: when populating the `agent.policy.*` data, it may be possible
that the agent that the response action was sent to is no longer
available (ex. unenrolled). In such cases, the migration will populate
any field that it is not able to retrieve information for with the text
`MIGRATION:NOT-FOUND`
> [!IMPORTANT]
> The migration currently assumes that the `9.1.0` endpoint package is
already installed, which will not be the case with a real migration. To
test this PR, you should start a 9.1 stack with the feature flags
disabled... Install the `9.1.0` endpoint package, and then enable the
feature flags.
> We will be working on a solution handling this data condition in a
subsequent PR
Handles :
- https://github.com/elastic/security-team/issues/12236
- https://github.com/elastic/security-team/issues/12012
- https://github.com/elastic/security-team/issues/12235
## Summary
This PR adds the ability to change rule migration execution settings
when `re-processing` a migration. Now users can change :
- `connector` they want to use for this particular occasion.
- whether `prebuilt rules` should be matched or not.
This PR include below changes:
### Changes to `Re-process` workflow
Previously, clicking on `Reprocess Rules` would automatically start the
migration on the Translated Rules Page.
This has been changed to add the ability for user to change the settings
when starting the migrations can be seen below :
> [!Note]
> Sample Graph executions with `skipPrebuiltRulesMatching == true` can
be found
[here](66aedda3-8cfd-4eee-950d-7ba2f93a317e?timeModel=%7B%22duration%22%3A%227d%22%7D&searchModel=%7B%22filter%22%3A%22and%28eq%28is_root%2C+true%29%2C+and%28eq%28metadata_key%2C+%5C%22skipPrebuiltRulesMatching%5C%22%29%2C+eq%28metadata_value%2C+true%29%29%29%22%2C%22searchFilter%22%3A%22eq%28is_root%2C+true%29%22%7D&runtab=2)
https://github.com/user-attachments/assets/73c22157-f688-410d-852d-aff7be612771
### Changes to `/start` API
As can be seen below `connector_id` and new option
`skip_prebuilt_rules_matching` have been combined into a single
`settings` object.
#### Before
```ts
POST /start
{
"connector_id": boolean,
"retry": string,
"langsmith_options": {
"project_name": string,
"api_key": string
}
}
```
#### After
```ts
{
"settings": {
"connector_id": string,
"skip_prebuilt_rules_matching": boolean
},
"retry": string,
"langsmith_options": {
"project_name": string,
"api_key": string
}
}
```
### Changes to `rules/{migration_id}/stats` and `rules/stats` Endpoints
Now both `stats` and `stats_all` endpoints include migration's
last_execution details.
### Changes to Langsmith Graph
A new [run-time
config](https://v02.api.js.lang.chat/interfaces/_langchain_core.runnables.RunnableConfig.html#configurable)
called `skip_prebuilt_rules_matching` has been added to the graph which
does 2 things
- conditionally skips the `matchPrebuiltRule` node as can be seen by
graphs below
- Assigns a default `prebuilt_rule_id` of `null` in the
`translationResult` node.
### Re-processing `STOPPED` migrations
Previously we used to automatically reprocess `STOPPED` migrations with
the default `connector_id` selected by the user in `Siem Migrations`
Now, we first try to inherit the `last_execution` settings to re-start
the migration as can be seen
[here](https://github.com/elastic/kibana/pull/222542/files#diff-fa4ce089bfa7b6afec449c289c817f03eb074ae5ffcae828434255c800d9a9a2R287).
If not present, for example, for old migrations before this PR was
merged, then we use stored/default values.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] 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
- [ ] 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
- [ ] 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
Simplify `FunctionVisibility` to only two possible states: `internal`
and `all`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/223170
Closes https://github.com/elastic/kibana/issues/223168
PR does the following:
* Removes `injectReferences` from `loadDashboardState`
* `type` and `id` are populated from matching panelRef server side with
dashboard api transform.
* Dynamic action `inject` is run during embeddable bootstrapping as part
of `initializeEmbeddableDynamicActions`.
* Removes `extractReferences` from dashboard `getSerializedState`
* extracts panelRef in `layoutManager.serializeLayout`
* Dynamic action `extract` is run during `embeddable.serializeState`
* Updates embeddable implementations that use
`initializeEmbeddableDynamicActions` to serialize dynamic action state
with references in `serializeState`
* Removes `PersistableStateService` from `EmbeddableStart` contract
* Moves `embeddable.common` `PersistableStateService` code to
`embeddable.server`
The PR is all ready large, so the following TODOs will be addressed in
follow on work
* Move `embeddable_enhanced` plugin to package.
* Clean-up dashboard/common folder, moving
src/platform/plugins/shared/dashboard/common/dashboard_container/persistable_state/dashboard_container_references.ts
and
src/platform/plugins/shared/dashboard/common/dashboard_saved_object/persistable_state/dashboard_saved_object_references.ts
functionality to server folder. The plan will be to break these files
into `inject_references` and `extract_references`.
### Embeddable owner test instructions
* open dashboard with panel type and drilldown. Verify drilldown works
as expected
* Create new dashboard with panel type and drilldown. Save dashboard.
Open dashboard and verify drilldown works as expected.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Removes the tech preview designation from the session invalidation API.
Resolves https://github.com/elastic/kibana/issues/224070
## Release Note
The Session Invalidation API is now marked as Stable.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR guards changes to the streams state that go through
`State.attemptChanges` via the newly introduced lock manager.
If two requests are happening at the same time, one of them now fails
with a 409.
## Concerns
* Lock expiry is 30s for now - is this too little? Should be good enough
for now, maybe we need to reconsider once we introduce the bulk api
* This is only guarding changes that go through the `State` class - some
things like queries and dashboards do not, so they can still be subject
to race conditions. We could sprinkle more locks over the code base, but
I would like to solve this by moving them into `State` as well, that
seems like the cleaner approach, even though a bit more effort
* Biggest question - on this PR the concurrent request fails directly
with a 409. Is this OK or should it wait and retry a couple times? I'm
in favor of starting like this and seeing if this is actually a problem.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Kevin Lacabane <kevin.lacabane@elastic.co>
## Summary
Closes#221607
Improves naming of new tabs, so instead of determining number in tab
name as `tab count + 1` we now check the highest existing number on
default tab and add +1.
**Possible improvements:**
This logic is very similar to `onDuplicate` function, which lives in
`src/platform/packages/shared/kbn-unified-tabs/src/components/tabbed_content/tabbed_content.tsx`.
It may be worth to make it more DRY, I'm open for creating a new ticket
for this and handling it, if we agree on refactor. Or to handle it
within this PR.
My rough idea was to add a parameter to `createTabItem` which tells us
if we duplicate an item or not. If so, we should use a logic and regexes
similar to `onDuplicate` function, otherwise logic and regexes from this
PR. It adds `isDuplicate` parameter though in couple different places
causing prop drilling, so I hesitated with taking this decision on my
own.
**EDIT**
Created a new issue for extracting common parts [[OneDiscover][Tabs]
Extract common parts in creating and duplicating tabs
label](https://github.com/elastic/kibana/issues/223899#top)
### 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)
- [ ] 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
- [ ] 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.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
## Summary
Resolves https://github.com/elastic/streams-program/issues/292
This PR shows the streams description below its name using an InlineEdit
component.
I had to pass the refreshDefinition function in the tabs/dashboard and
use it whenever we update the list of dashboards since I had an issue
with using the outdated definition in case we updated the dashboards
list without fully refreshing the page.
https://github.com/user-attachments/assets/2e742263-a9d1-447a-9222-4b2c33d79958
---------
Co-authored-by: Joe Reuter <johannes.reuter@elastic.co>
Fixes https://github.com/elastic/kibana/issues/221820
Fixes https://github.com/elastic/kibana/issues/220879
## Summary
This PR reverts https://github.com/elastic/kibana/pull/204296 and
https://github.com/elastic/kibana/pull/218853 as these PRs caused issues
in the UI due to limitations in the Query Watches API. Therefore, we are
temporarily reverting back to fetching watches through the `.watches`
system index until we have better support from the Query Watches API.
**How to test:**
1. Start Es with `yarn es snapshot --license=trial` and Kibana with
`yarn start` (no need to test in serverless as Watcher is not available
there.
2. Navigate to Stack Management -> Watcher and create multiple watches
(the more, the better). Make sure you create watches of different types
(advanced/json or threshold), watches with or without names, etc. There
are different watches and use cases described in the
[documentation](https://www.elastic.co/docs/explore-analyze/alerts-cases/watcher).
Also, adding sample data sets is helpful so that you can get watches to
execute and have values under the "Condition last met" and "Last
checked" columns.
3. After creating various watches, open the table with watches and make
sure that all functionalities work correctly. For example:
- All watches are displayed, check with >10 watches and different page
sizes.
- Sorting works for all columns.
- Search bar works as expected and searching by partial id is supported.
- Deleting watches updates the table correctly.
https://github.com/user-attachments/assets/d0da9c24-7389-481d-8a16-a0d01bda0e80
## Release notes:
This update resolves multiple issues in Watcher UI that were introduced
in 8.18.0, 8.18.1, 9.0.0, and 9.1.0, including the table not displaying
more than 10 watches, an error banner appearing unexpectedly in certain
scenarios, and the search bar functionality not working as expected.
This PR removes the painless implementation of log document
normalization and switches to the Elasticsearch version which is meant
as the source of truth.
This shouldn't change behavior at all.
## Summary
### Test track
This is an entity that offers an easy way to distribute test loads to
run in parallel by assigning them to lanes. The main metric used to
determine on which lane of a test track a test load should go is
*estimated runtime*.
Other than load routing functions, the track itself doesn't hold any
logic that pertains to the distribution strategy. In the current
implementation, you can:
- add new lanes
- add a load to a new lane
- add a load to a lane based on it's current capacity
The test track also offers an easy way to serialise the specification,
which holds all relevant information that describes how the load is
distributed across lanes, along with some useful stats about the lanes
and the combined runtime.
Notes:
- A lane's capacity is represented by the difference between the current
estimated runtime and the target runtime
- If a lane's capacity has been reached or exceeded, the lane status
becomes `closed`
- If a lane's expected runtime exceeds the target runtime, the lane is
considered **congested**
### Test config stats
By querying Scout test event data collected from previous runs, we can
gather knowledge about each individual test config duration which is
crucial when deciding how we distribute the test loads to run in
parallel.
The following duration aggregations are recorded when test config stats
are collected: `avg`, `median`, `95th percentile`, `99th percentile`,
`max`.
The `95th percentile` value is what's currently used as the estimated
runtime.
### CLI: `scout update-test-config-stats`
Used to fetch the latest test config stats from Scout test events stored
in an Elasticsearch instance and store them locally under
`.scout/test_config_stats.json`.
This assumes that the test events used to calculate the stats have been
collected from Buildkite.
### CLI: `scout create-test-track`
Given a list of test config manifests, it distributes the enabled
configs on a test track and outputs the track specification to a file.
The estimated runtime for each config is determined from the test config
stats stored under `.scout/test_config_stats.json`.
The _target runtime_ of the track and _maximum lane count_ are
configurable to provide some flexibility depending on the use case.
If stats for a config are not available, the estimated runtime will
default to the target runtime of the track, effectively placing the
config on a separate lane, if the maximum lane count hasn't been already
reached.
#### Distribution strategy
- sort all test loads in descending order based on estimated runtime
- assign each load to the least loaded lane
- open a new lane no open lanes are available or adding it to an
existing lane would lead to congestion
This strategy is fairly basic, but it's pretty effective. It prioritises
maximum lane saturation and avoids lane congestion.
#### Example usage
Distribute stateful configs on a test track
```shell
node scripts/scout.js create-test-track \
--configManifest $(echo .buildkite/*_stateful_configs.yml | sed 's/ / --configManifest /g')
```
---------
Co-authored-by: Cesare de Cal <cesare.decal@elastic.co>
## Summary
- Forwards `startDate` correctly to the `CustomRecurringSchedule`
component. The missing prop caused the monthly custom frequency
sub-options to not show up.
- Fixes the `CustomRecurringSchedule` component type to correctly
reflect the required prop.
- Removes the `custom-recurring-form` data test subject from the
`<CustomRecurringSchedule>` JSX tag. The test subject wasn't forwarded
to any DOM element, but the only test with an assertion using that test
subject was passing because it was checking its absence
(`not.toBeInTheDocument()`).
## Verification steps
1. Open the Maintenance Window creation page
2. Toggle "Repeat" on
3. In the recurrence form, check that all the custom frequencies work,
showing the correct sub-options
## Summary
Improves the IF statement to ensure that we are dealing with an object
with loopable keys and remove the try-catch. If not loopable, we might
want to remove the user context entirely (or replace it with a known
object { id: '[INVALID]' }) since it might lead to APM traces being
discarded due to invalid user context.
closes https://github.com/elastic/kibana/issues/219095
## Summary
Closes https://github.com/elastic/kibana/issues/223007
### This PR fixes a couple of bugs in the visibility of the Alert Top
Nave menu item:
**1. When the user is in Classic space with <ins> no rule type
privileges </ins> the `Alert` top nav menu item should be hidden**
- Only `Discover` _**All**_ Feature Privilege
<img width="465" alt="Screenshot 2025-06-11 at 11 01 03"
src="https://github.com/user-attachments/assets/063a01b1-16a5-4ee1-b981-a2d4b93c08ac"
/></br></br>
**2. When a user has <ins> only `SLO` </ins> privilege the menu should
be shown with only SLO entry.**
- `Discover` & Observability `SLO` _**All**_ Feature Privilege
<img width="532" alt="Screenshot 2025-06-11 at 11 00 31"
src="https://github.com/user-attachments/assets/91f48791-28b0-48ce-b7fa-f1c8139556dd"
/></br></br>
**3. When the user has <ins> no `SLO` </ins> privilege, the `SLO` entry
should be hidden**
- `Discover` & Observability `Logs` _**All**_ Feature Privilege
<img width="518" alt="Screenshot 2025-06-11 at 11 01 34"
src="https://github.com/user-attachments/assets/c6df8a7d-c35b-43f0-be81-84ca3ef0b2e4"
/></br></br>
4. **When the user has access to <ins> only manage alerts </ins> without
specific rule type, the `Manage alerts` entry should be shown.**
- `Discover` & Security `Security` _**All**_ Feature Privilege in
**_Classic_** navigation
<img width="509" alt="Screenshot 2025-06-11 at 11 02 59"
src="https://github.com/user-attachments/assets/b5c370a6-f346-4bad-a8bd-d19fa6c95c76"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/220464
## Summary
As part of the EUI button style updates, I reviewed the RO files for any
CSS class overrides affecting `euiButton` and `euiFilter` components. I
found some custom CSS overrides and I was able to safely remove them.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
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
Fixes https://github.com/elastic/kibana/issues/221918
Currently search on the `Related dashboards` in the Rule configuration
works only client side. It searches only within the rendered dashboards,
thus returning no results, even if dashboard exists.
<img width="400" alt="Screenshot 2025-05-29 at 14 40 57"
src="https://github.com/user-attachments/assets/04cfdec1-f3e5-4b22-9fb1-8eaaf72dbb89"
/>
This PR enables server-side searching for the `Related dashboards` in
the Rule configuration by adding `onSearchChange` in the `EuiComboBox`
element. It also adds a `limit` on the query option, since `.search`
method returns only a small number of results by default.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Reverts elastic/kibana#223362
I accidentally merged the previous PR, I am so sorry. I am reverting and
open it again to get the presentation team approval
## Summary
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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This makes the existing 'logging_level' agent configuration setting
available to EDOT Node.js agents ('opentelemetry/nodejs/elastic').
Co-authored-by: Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com>
## Summary
This PR addresses https://github.com/elastic/kibana/issues/212424
Tests were added to the `ConnectorSelector` package
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Dependency: https://github.com/elastic/kibana/pull/223321 to be merged
first
This PR renamed `isPreview` to `isRulePreview` in the document details
code. A clearer distinction between `isPreview` and `isPreviewMode`
helps improve comprehensibility and avoid mixing them up.
In some UI components, rule preview is not part of any logic, they are
renamed to something more explicit.
- In `SuppressedAlerts`, `isPreview` is now `showInvestigateInTimeline`
- In `Assignee`, `isPreview` is now `showAssignees` (opposite check)
### Checklist
- [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)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
As a result of discussing a closer alignment between Product and
configuration naming, this change renames the observability `essentials`
tier to `logs_essentials`.
As a consequence, the specific configuration file loaded for this tier
is now named `serverless.oblt.logs_essentials.yml`.
Furthermore, this means that switching between the `complete` and
`logs_essentials` tier should now be done with
```yml
pricing.tiers.enabled: true
pricing.tiers.products:
- name: observability
tier: complete # Accepted values for this tier are: complete, logs_essentials
```
## Summary
Partially implements #219986
- Collect clicks / interactions with rules objects
- Determine the source of the clicks (rule details page vs table)
- How often users snooze, enable, disable, run rules
- This PR specifically enables the ability to determine how often these
actions occur by rule type
## Query Examples
```
properties.target: "data-test-subj=snoozeButton"
```
Will give you documents that will tell you that a user clicked on the
snooze button on any page
```
properties.target: "data-test-subj=snoozeButton" and "data-test-subj=collapsedActionPanel"
```
Will give you documents that will tell you that a user clicked on the
snooze button on the collapsed action panel on the table INSTEAD OF the
snooze button in the notify column or details page
```
properties.target: "data-test-subj=ruleType_slo.rules.burnRate" and properties.target: "data-test-subj=snoozeButton"
```
Will give you documents where SLO burn rate rules were snoozed
## Local Testing
Add the following to kibana.dev.yml
```
telemetry:
localShipper: true
```
Clicks will begin registering to the `ebt-kibana-browser` index with
target arrays that include the new test subject values.
Sample target array with the changes:
[example.txt](https://github.com/user-attachments/files/20630704/example.txt)
- Click location (page name)
- Rule type
- Button label
Closes https://github.com/elastic/observability-dev/issues/4432
## Summary
Auditing [log
levels](https://docs.elastic.dev/kibana-dev-docs/services/logging#log-level)
in the Synthetics plugin.
### Example
Throwing error when creating a new monitor:
<img
src="https://github.com/user-attachments/assets/7cead63b-c209-4174-a4f7-7dfad40aa34d"
width=500 />
#### Before
```
1.
[2025-04-23T12:29:37.594+02:00][ERROR][plugins.synthetics] Error: newMonitorPromise failed!
at /Users/maryam.saeidi/WebstormProjects/kibana-mary/x-pack/solutions/observability/plugins/synthetics/server/routes/monitor_cruds/add_monitor/add_monitor_api.ts:82:15
at async AddEditMonitorAPI.syncNewMonitor (/Users/maryam.saeidi/WebstormProjects/kibana-mary/x-pack/solutions/observability/plugins/synthetics/server/routes/monitor_cruds/add_monitor/add_monitor_api.ts:88:72)
at async handler (/Users/maryam.saeidi/WebstormProjects/kibana-mary/x-pack/solutions/observability/plugins/synthetics/server/routes/monitor_cruds/add_monitor.ts:123:11)
2.
[2025-04-23T12:29:37.595+02:00][ERROR][plugins.synthetics] Unable to create Synthetics monitor https://www.elastic.co/
3.
[2025-04-23T12:29:38.758+02:00][ERROR][plugins.synthetics] Error: newMonitorPromise failed!
at /Users/maryam.saeidi/WebstormProjects/kibana-mary/x-pack/solutions/observability/plugins/synthetics/server/routes/monitor_cruds/add_monitor/add_monitor_api.ts:82:15
at async AddEditMonitorAPI.syncNewMonitor (/Users/maryam.saeidi/WebstormProjects/kibana-mary/x-pack/solutions/observability/plugins/synthetics/server/routes/monitor_cruds/add_monitor/add_monitor_api.ts:88:72)
at async handler (/Users/maryam.saeidi/WebstormProjects/kibana-mary/x-pack/solutions/observability/plugins/synthetics/server/routes/monitor_cruds/add_monitor.ts:123:11)
4.
[2025-04-23T12:29:38.760+02:00][ERROR][plugins.synthetics] Unable to create synthetics monitor
```
#### After
```
[2025-05-12T16:06:23.160+02:00][ERROR][plugins.synthetics] Unable to create Synthetics monitor with name https://www.elastic.co/ Error: newMonitorPromise failed!
at /Users/maryam.saeidi/WebstormProjects/kibana-mary/x-pack/solutions/observability/plugins/synthetics/server/routes/monitor_cruds/add_monitor/add_monitor_api.ts:82:15
at async AddEditMonitorAPI.syncNewMonitor (/Users/maryam.saeidi/WebstormProjects/kibana-mary/x-pack/solutions/observability/plugins/synthetics/server/routes/monitor_cruds/add_monitor/add_monitor_api.ts:88:72)
at async handler (/Users/maryam.saeidi/WebstormProjects/kibana-mary/x-pack/solutions/observability/plugins/synthetics/server/routes/monitor_cruds/add_monitor.ts:123:11)
```
##### ⚠️ Note
After merging this [PR](https://github.com/elastic/kibana/pull/219940),
we will also have stacktrace locally.
### ❓ Questions
1. When calling `synthetics/params` API with wrong parameters, we get
`[2025-05-13T11:05:52.401+02:00][ERROR][http] 400 Bad Request`, which
path is responsible for this error? (Since it is from `http`, so it is
not logged in synthetics. I am wondering where the validation is
happening in this case)
**Answer**: It was here:
https://github.com/elastic/kibana/blob/main/src/core/packages/http/router-server-internal/src/route.ts#L124
## Summary
Prepares the registry for more extensions.
In the MVP we were immediately returning the recommended queries. This
PR changes the response to from an aray of queries to an object with
recommended queries as a property. This will allow us to add more
extensions points in the future (such as recommended fields)
**Note**: No changes have been introduced to the api
### 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
Closes https://github.com/elastic/kibana/issues/216758
## Summary
- added a filter that when a column (field) is removed from the alerts
table, any associated sort configuration is also removed. Specifically,
the sort entries that no longer correspond to a column in the visible
columns list are filtered out.
`embeddable_data_grid` tests discover session embeddable functionality.
This is owned by discover team and should not be part of dashboard test
suite. This PR consolidates the test cases from embeddable_data_grid to
_saved_search_embeddable.ts.
Simplifies API types for `ChatCompleteAPI` & parameter binding. The main
change is that `ChatCompleteCompositeResponse` no longer defaults to
`stream:false`, instead it will result in a union type (streaming and
non-streaming). This frees us up from having to define the generic
arguments in many places. I've also added type tests.
## Summary
Closes
https://github.com/elastic/kibana/issues/208707?issue=elastic%7Ckibana%7C217068
This PR adds the full-screen version of the waterfall preview shown in
the span and transaction flyouts in Discover.
https://github.com/user-attachments/assets/a042dcff-ee31-473d-8a9c-34f3fd00e1a1
**Here’s a summary of the main changes introduced:**
- Set up a custom full-screen waterfall component.
- There’s currently no unified way to do this, but there’s an [open
issue for sharedUX](https://github.com/elastic/kibana/issues/220610)
requesting it, I believe it could be useful across Kibana.
- Created a hook to retrieve span information for the flyout (since the
node click event only provides limited span details).
- Created a `SpanFlyout` component, which opens when clicking on a node
in the waterfall.
- All 3 tabs are the same ones as we have in Discove.
- Booleans were added in the Overview tab components to show/hide the
full-screen button, the waterfall preview, and the field actions.
- Added span and transaction ids to `useRootTransaction` to use them as
`entryTransactionId` for the waterfall. This isn’t fully OTel-compatible
yet, that will be handled in a [separate
issue](https://github.com/elastic/kibana/issues/221521), but I wanted to
get ahead by including both IDs now, using `span.id` as a fallback when
`transaction.id` isn’t available.
**Applied some updates to the waterfall component itself:**
- The `onNodeClick` event is now propagated so the flyout can be
triggered.
- Error markers in the embedded waterfall timeline have been temporarily
removed.
- Error markers depended on APM routing, which we’re avoiding in
embedded mode.
- They’re now disabled when embedded, and we’ll revisit this to improve
the experience.
- Added `scrollElement` to properly handle the virtual rendering of the
waterfall nodes
>[!WARNING]
The changes on the APM waterfall will be removed soon in favor of a [new
version](https://github.com/elastic/kibana/issues/214795) of it, there
is [a separate issue](https://github.com/elastic/kibana/issues/222590)
to handle the migration.
**Additional improvements that were out of the full-screen scope:**
- A short description was added for the "Destination" field in spans.
- Renamed `transactionIndexPattern` to `tracesIndexPattern` for
consistency.
---------
>[!NOTE]
> The error details feature will be handled in a [separate
issue](https://github.com/elastic/kibana/issues/219780). We’ll implement
[an intermediate
solution](https://github.com/elastic/kibana/issues/222591) before
tackling the final one.
>[!WARNING]
~This needs to be backported to 8.19, but before that, we need to merge
[this](https://github.com/elastic/kibana/pull/221950#issuecomment-2929778812)
other backport PR containing the whole feature.~ It has been merged.
## How to test
- Enable the discover profiles by adding this to the` kibana.yml `file:
```
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
- Make sure your space has Observability as Solution View.
- Open Discover and select or create a data view that includes any APM
traces index (`traces-*`), or query them using ES|QL.
- Open the flyout for a span or transaction document.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Carlos Crespo <crespocarlos@users.noreply.github.com>
Co-authored-by: Milosz Marcinkowski <38698566+miloszmarcinkowski@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/220850
## Summary
Add logic that handles the case of custom integrations that cannot be
installed in the remote because of error
` PackageNotFoundError: [pkgName] package not found in registry`
Currently, when the installation is attempted, we just log the error and
exit. I added some logic that creates an "empty" installation SO in
`epm-packages` with status `install_failed` and populates
the`latest_install_failed_attempts` field so we know what happened.
**NOTE**: we could add this logic in the regular install process as
well, it would be useful for debugging purpose
- I also added some logic to `compareSyncIntegrations` to make this
error a warning and because I also made the logic for the warning more
generic
### Testing
- Install a custom integration in the main cluster, let the
syncIntegrationsTask run and after a while check `GET
.kibana_ingest/_doc/epm-packages:PKGNAME`. You should see the error
saved under `latest_install_failed_attempts`:
<img width="1804" alt="Screenshot 2025-06-10 at 16 20 09"
src="https://github.com/user-attachments/assets/2cffbf01-15f2-4091-bcbd-660fbb390c56"
/>
- In the remote, query `GET
kbn:/api/fleet/remote_synced_integrations/status` and verify that it
returns a warning for the custom integration. Example:
```
"integrations": [
{
"package_name": "agentless_package_links",
"package_version": "0.0.2",
"install_status": {
"main": "installed",
"remote": "not_installed"
},
"updated_at": "2025-05-21T08:55:47.981Z",
"sync_status": "warning",
"warning": {
"title": "agentless_package_links can't be automatically synced",
"message": "This integration must be manually installed on the remote cluster. Automatic updates and remote installs are not supported."
}
},
...
```
- Test the UI - go to Fleet settings and verify that the custom
integration shows a warning:
![Uploading Screenshot 2025-06-11 at 16.26.47.png…]()
### 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
- [ ] [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
---------
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/222920
When adding CSPM integration to an agent policy, agentless selector
should be hidden.
To verify:
- Create an agent policy
- Go to Add integration flyout
- Select CSPM integration
- Verify that there is no setup technology selector
- Create the integration policy, verify that it is added to the correct
agent policy (not agentless)
## Summary
Currently, `yarn kbn clean` nor `yarn kbn reset` won't remove cached ES
snapshot builds. This might cause issues for developers when switching
between branches with major changes. (see:
https://elastic.slack.com/archives/C5UDAFZQU/p1749628993034289)
This PR adds a softer and a harder clean to `clean` and `reset`
respectively.
## Summary
Resolves https://github.com/elastic/kibana/issues/212801
Removes already linked dashboards from the list of suggested dashboards
Also has the side effect of returning the linked dashboards from the
related dashboards api, which can be used to render the linked
dashboards list along with the suggested dashboards, rather than calling
a separate API from the client.
---------
Co-authored-by: Justin Kambic <jk@elastic.co>
## Summary
Main ticket ([Internal
link](https://github.com/elastic/security-team/issues/12484))
With these changes we switch from temporarily (while behind the feature
flag) used data stream `.alerts-security.attack.discovery.alerts-ad-hoc`
to a one created and setup by Alerting Framework
`.adhoc.alerts-security.attack.discovery.alerts`. This index used to
store "ad-hoc" attack discovery alerts generated by user manually and
initially visible only to that user with the option to share those
alerts to other people in the same organization.
There should be no visual changes, only the underlying index changed for
the manually generated attack discovery alerts.
**To test**:
1. Generate attack discovery via "Generate" button on Attack Discovery
page
2. Check generated alerts within the
`.adhoc.alerts-security.attack.discovery.alerts*` index
```
GET .adhoc.alerts-security.attack.discovery.alerts*/_search
```
## NOTES
The feature is hidden behind the feature flag (in `kibana.dev.yml`):
```
feature_flags.overrides:
securitySolution.attackDiscoveryAlertsEnabled: true
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR fixes an issue with running our Security Assistant evals on CI
where the tests would finish and cleanup before the evaluations would
actually complete. There was no issue with actually running the
evaluations, they would finish without error, however since the tests
would complete beforehand, the required resources (alerts, kb docs,
elser, etc) would be cleaned up and the evaluations wouldn't pass.
The issue has been fixed by polling for evaluation completion before
letting the tests complete. This was accomplished by writing evaluation
results (`id`/`status`) to a new ephemeral index
`.kibana-elastic-ai-assistant-evaluations-default` with an ILM policy of
`1d`, and then updating the GET evaluation route to include a `results`
array that can be used to confirm the status of the evaluation.
Note: There is no impact to production deployments with these changes as
all evaluation routes are gated behind the evaluation feature flag,
which can be enabled by adding the below configuration to your
`kibana.dev.yml`:
```
xpack.securitySolution.enableExperimental:
- "assistantModelEvaluation"
```
---
## Results
[Successful
Build](https://buildkite.com/elastic/kibana-pull-request/builds/306787/summary/annotations?jid=019756d8-e32f-4366-be5c-0f766a7c2934)
with `33m16s` runtime
[ES|QL Generation
Regression](261dcc59-fbe7-4397-a662-ff94042f666c/compare?selectedSessions=3303dbd1-4b29-4e36-900e-fc17ccfc923b,0acddaab-badb-4830-b731-170a3c122fcb,b8c300dc-3947-4c47-96d0-e3224be44d59,ce88d37d-6083-41ed-bcc7-989a2efc9c33&baseline=3303dbd1-4b29-4e36-900e-fc17ccfc923b)
<p align="center">
<img width="800"
src="https://github.com/user-attachments/assets/45750385-56c1-424d-bdc7-19ef1e378416"
/>
</p>
[Alerts RAG Regression (Episodes
1-8)](bd5bba1d-97aa-4512-bce7-b09aa943c651/compare?selectedSessions=f99b3bc7-bebf-4338-8cc5-96cff42015ab,776083c7-733b-476f-9a2e-ab90f62ba95b,f2036996-be11-45af-ab48-ee407b417679,7c02109b-ff7e-4b7c-8273-937a269f8924&baseline=f99b3bc7-bebf-4338-8cc5-96cff42015ab)
> [!NOTE]
> Need to either update dataset's referenced output to match the more
verbose outputs of the tests, or to tune the evaluator prompt to be more
lax as this is incorrectly the impacting correctness value. Examples
needing updated:
>
> Example: #9e6e
> Example: #d33b
> Example: #e4c6
<p align="center">
<img width="800"
src="https://github.com/user-attachments/assets/61b8711a-f9bc-4b0b-93ce-cb9436864857"
/>
</p>
[Assistant Eval: Custom
Knowledge](2d5f7c18-4bf4-4cdb-97a1-16e39a865cab/compare?selectedSessions=589cbefa-893d-411e-86ea-cf2fe01d352e,4f0e797e-b6fa-4aa6-b707-3fd952d9eccb,75a78e49-0ae4-4edd-b6c5-35a1ea2cafa8,3b7bef1e-69e7-4692-b156-acf30992383d&baseline=589cbefa-893d-411e-86ea-cf2fe01d352e)
> [!NOTE]
> Quite a few failures here which seem to be stemming from either
mis-matches in anonymization values when referencing specific host names
(differing from example alerts used in tests vs data set generation), or
the [KBRetrival tool not even being
called](https://smith.langchain.com/public/d76c989e-f467-43a6-b606-c601e986d382/r).
<p align="center">
<img width="800"
src="https://github.com/user-attachments/assets/1a57efbc-8615-4209-9483-7aee69f2a622"
/>
</p>
[Eval AD: All
Scenarios](4690ee16-9df5-416c-8bf0-b62bc2f2aba9/compare?selectedSessions=2ca55bc8-7b26-4f4a-909d-5e86ceddc53d,3694531a-32e0-4216-b91b-9136e7523bbb,6daa7be3-6b9b-44d3-bac3-6ba6980accfd,ad741ca8-07bf-4bfe-ba85-6b271e9c3e34&baseline=2ca55bc8-7b26-4f4a-909d-5e86ceddc53d&textDisplayMode=compact&compare-experiment-tab=0)
<p align="center">
<img width="800"
src="https://github.com/user-attachments/assets/7e946207-290d-450f-a6ad-e679c8b60f0b"
/>
</p>
## Next Steps
* Need to improve the `Alerts RAG Regression (Episodes 1-8)` and
`Assistant Eval: Custom Knowledge` suites as correctness is being
impacted by a few factors: more verbose output from some models,
evaluator prompt, example alerts/anonymization mis-matching, or missed
tool calls
* Add telemetry for writing execution times and single correctness score
per model per suite
* Optionally write as console output/test artifact when running tests
* Output link to LangSmith results in console output
Closes https://github.com/elastic/observability-dev/issues/4445
EBT implementation: https://github.com/elastic/ebt/pull/57
## Summary
In this PR, we are adding `getTraceContext` to the `createAnalytics` in
order to include `trace.id` in the EBT events.
### ⚠️ Note
Some events might not have a `trace.id` due to not having an active
transaction at the moment of reporting the event. For those, we can
implement more sophisticated logic to keep track of transactions and use
the `trace.id` of the last one for the event (in a follow-up ticket, if
necessary).
### How to test
- Add `telemetry.localShipper: true` to the kibana config and create a
data view for `ebt-kibana-browser` index
- Check the `trace.id` in the events that are passed
---------
Co-authored-by: Alejandro Fernández Haro <alejandro.haro@elastic.co>
## Summary
Main ticket ([Internal
link](https://github.com/elastic/security-team/issues/10142))
With these changes we add a attack discovery alert details url. Same as
detection alerts it will be stored within the `kibana.alert.url` field.
The url uses the `server.publicBaseUrl` configuration from `kibana.yml`
file and if that config is not set the url will be `undefined`. This
config is set internally (in the
https://github.com/elastic/project-controller/tree/main) for
**serverless** projects ([internal
discussion](https://elastic.slack.com/archives/C054M7BU84Q/p1748539899308869)).
Also, to allow users to access the details link in case of the `for each
alert` action frequency from within the connector we added a new message
variable: `context.attack.detailsUrl`.
**To test**:
1. Set `server.publicBaseUrl` in `kibana.yml`
2. Generate attack discovery via schedule
3. Check generated alerts within the
`.alerts-security.attack.discovery.alerts*` index (specifically
`kibana.alert.url` field)
## NOTES
The feature is hidden behind the feature flag (in `kibana.dev.yml`):
```
feature_flags.overrides:
securitySolution.assistantAttackDiscoverySchedulingEnabled: true
```
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| @​types/base64-js | devDependencies | minor | [`^1.2.5` ->
`^1.5.0`](https://renovatebot.com/diffs/npm/@types%2fbase64-js/1.2.5/1.5.0)
|
| [base64-js](https://redirect.github.com/beatgammit/base64-js) |
dependencies | patch | [`^1.3.1` ->
`^1.5.1`](https://renovatebot.com/diffs/npm/base64-js/1.5.1/1.5.1) |
---
### 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.
👻 **Immortal**: This PR will be recreated if closed unmerged. Get
[config
help](https://redirect.github.com/renovatebot/renovate/discussions) if
that's undesired.
---
- [ ] <!-- 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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOlNoYXJlZFVYIiwiYmFja3BvcnQ6YWxsLW9wZW4iLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Tim Sullivan <tsullivan@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| @​types/lz-string | devDependencies | minor | [`^1.3.34` ->
`^1.5.0`](https://renovatebot.com/diffs/npm/@types%2flz-string/1.3.34/1.5.0)
|
| [lz-string](http://pieroxy.net/blog/pages/lz-string/index.html)
([source](https://redirect.github.com/pieroxy/lz-string)) | dependencies
| patch | [`^1.4.4` ->
`^1.5.0`](https://renovatebot.com/diffs/npm/lz-string/1.5.0/1.5.0) |
---
### 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 these
updates 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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOlNoYXJlZFVYIiwiYmFja3BvcnQ6YWxsLW9wZW4iLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Jeramy Soucy <jeramy.soucy@elastic.co>
Co-authored-by: Tim Sullivan <tsullivan@users.noreply.github.com>
## 📓 Summary
When starting Kibana with CLI config overrides, the ones that looked up
for the tier and loaded the appropriate configuration file were not
wired, resulting in the override being ineffective.
This change fixes the behaviour, giving precedence to unknown CLI args
that might override the `pricing` configuration and correctly configure
Kibana.
## Summary
This PR introduces the **1chat MCP server** in Kibana, exposed at the
experimental `/api/mcp` endpoint behind a feature flag. It allows
external MCP clients (e.g. Claude Desktop, Cursor, OpenAI Agents) to
connect and use tools registered in the 1chat registry.
### MCP server
- Implements a **stateless** MCP server following the MCP spec
(Streamable HTTP transport).
- Supports **API key** and **basic auth** for authentication.
- Works with clients via:
- **Streamable HTTP** with auth header
- **STDIO** transport using `mcp-remote` proxy
- Endpoint under a feature flag `xpack.onechat.mcpServer.enabled`
- 1chat tools are scoped to the caller’s permissions, as determined by
the auth header.
### Other changes
- Implemented `KibanaMcpHttpTransport` (mcp http transport layer adapted
to Kibana Core primitives) + tests
### Local testing
Set ui setting: `onechat:mcpServer:enabled` to true
E.g. add this to Claude Desktop:
```
{
"mcpServers": {
"elastic": {
"command": "npx",
"args": [
"mcp-remote",
"https://{kbn}/api/mcp",
"--header",
"Authorization: ApiKey ${API_KEY}"
],
"env": {
"API_KEY": "..."
}
},
}
}
```
### Enable feature via API
```
POST kbn:/internal/kibana/settings/onechat:mcpServer:enabled
{"value": true}
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Updates policy protection notes to be space aware. Access to policy
protection notes is based on the agent policy's spaces.
Agent policy with access to spaces `default`, `foo`, and `bar`:
Note accessible from `foo` space:
Note accessible from `bar` space:
Note not accessible from `moo` space:
To test:
1) enable feature flags:
```
xpack.securitySolution.enableExperimental:
- endpointManagementSpaceAwarenessEnabled
xpack.fleet.enableExperimental:
- useSpaceAwareness
```
2) turn on fleet space awareness: `POST
/internal/fleet/enable_space_awareness`
3) Add at least 3 spaces (e.g., a, b, c)
4) Create an agent policy that is available in 2 of the 3 spaces (e.g.,
a, b) from step 3
5) Add Elastic Defend using the agent policy from step 4
6) Switch to one of the spaces that the agent policy is available in
from step 4 (e.g., a)
7) Add a policy protection note
8) Switch to the other space that the agent policy is available in from
step 4 (e.g., b)
9) Confirm that you can read the policy protection note from step 7
10) Switch to a space that the agent policy is not available in (e.g.,
c)
11) Confirm that you cannot access the policy protection note
(technically, you can't access the policy at all)
### Checklist
- [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
Resolves https://github.com/elastic/kibana/issues/223008
### Summary
This PR enhances the good vs bad charts by filtering the clicked events
when redirecting to discover. When clicking on View Events, we keep the
default behaviour of showing the total events
For example, if the user clicks on the good events (resp. bad events)
bar, we will select the "good events" (resp. bad events) filter on
discover.
### Manual testing
- Run data forge
- Create some SLOs with and without groups
- Verify the good events bar redirects to discover with good events
filter enabled
- Verify the bad events bar redirects to discover with bad events filter
enabled
- Verify the "View Events" link redirects to discover with total events
filter enabled
## Summary
Part of https://github.com/elastic/kibana/issues/207852
II tested printed styles via exporting PDF and comparing.
I prioritized classes over overly complex emotion props.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Small fix on the way we are concatenating the 2 sources (local and ccs).
Previously if one of the sources was empty such as
```
{
indices: [],
data_streams: [],
aliases: []
}
```
would return wrongly empty extensions.
This PR updates the console definitions to match the latest ones from
the @elastic/elasticsearch-specification repo.
---------
Co-authored-by: Sonia Sanz Vivas <sonia.sanzvivas@elastic.co>
Because Data Set quality page does not currently work with CCS, logs
coming from remote cluster have dataset quality link hidden in the
flyout.
The fix would hide a Data Set Quality link for documents that are coming
from remote clusters
Fixes#211602
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Re-submit of https://github.com/elastic/kibana/pull/216352 as it has
merge conflicts and we don't have write permissions for Sandra's remote.
To test, add the following to your kibana.yml:
```
uiSettings:
overrides:
"observability:aiAssistantAnonymizationRules":
- id: "ner"
type: "ner"
enabled: true
- id: "beach"
type: "regex"
enabled: true
pattern: "sandy"
```
---------
Co-authored-by: Sandra Gonzales <sandra.gonzales@elastic.co>
Co-authored-by: Sandra G <neptunian@users.noreply.github.com>
## Summary
This PR fixes the wrong position of the Lens user messages caused by the
absolute positioning of their container within a `static` positioned
parent.
>An element with `position: absolute` is positioned relative to its
nearest positioned ancestor. A "positioned" ancestor has a position
value other than static (the default).
If no such ancestor exists, the element will be positioned relative to
the initial containing block, which is usually the <html> element.
The `LensEmbeddableComponent` root div was with a `position:static` by
default, causing the absolute positioned badge/user message icon to be
positioned in the nearest positioned ancestor.
Fix https://github.com/elastic/kibana/issues/189344
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[@types/moment-duration-format](https://redirect.github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/moment-duration-format)
([source](https://redirect.github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/moment-duration-format))
| devDependencies | patch | [`^2.2.3` ->
`^2.2.6`](https://renovatebot.com/diffs/npm/@types%2fmoment-duration-format/2.2.3/2.2.6)
|
---
### 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.
---
- [x] <!-- 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>
## Summary
It closes#222658
This PR add changes to the Asset Inventory Empty State component:
- Removed the integrations card grid
- Having an "Add integration" link that will go to the **Asset
Discovery** integration when it's available. (When the integration is
not available it redirects to the all "Integrations" page.
**Test Refactoring:**
- Updated `no_data_found.test.tsx` and `initializing.test.tsx` to use
the new mockUseAddIntegrationPath utility and type-safe mocking with
jest.Mock.
- Improved assertions for the "Add integration" link/button, checking
both href and disabled state for more accurate UI validation.
### Screenshot
**Before:**
<img width="1441" alt="image"
src="https://github.com/user-attachments/assets/a2e1bd86-2d67-4a5e-b191-d3d30205cff1"
/>
**After:**
<img width="1508" alt="image"
src="https://github.com/user-attachments/assets/99b312a3-59c7-47f8-9791-aea7334fff0f"
/>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [blurhash](https://blurha.sh/)
([source](https://redirect.github.com/woltapp/blurhash/tree/HEAD/TypeScript))
| dependencies | patch | [`^2.0.1` ->
`^2.0.5`](https://renovatebot.com/diffs/npm/blurhash/2.0.1/2.0.5) |
---
### Release Notes
<details>
<summary>woltapp/blurhash (blurhash)</summary>
###
[`v2.0.4`](4dc3378847...7179af6173)
[Compare
Source](4dc3378847...7179af6173)
###
[`v2.0.3`](483859d3ba...4dc3378847)
[Compare
Source](483859d3ba...4dc3378847)
###
[`v2.0.2`](b93ee19c66...483859d3ba)
[Compare
Source](b93ee19c66...483859d3ba)
</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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOlNoYXJlZFVYIiwiYmFja3BvcnQ6YWxsLW9wZW4iLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Co-authored-by: Jeramy Soucy <jeramy.soucy@elastic.co>
Co-authored-by: Tim Sullivan <tsullivan@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[@types/deep-freeze-strict](https://redirect.github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/deep-freeze-strict)
([source](https://redirect.github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/deep-freeze-strict))
| devDependencies | patch | [`^1.1.0` ->
`^1.1.2`](https://renovatebot.com/diffs/npm/@types%2fdeep-freeze-strict/1.1.0/1.1.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:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOlNoYXJlZFVYIiwiYmFja3BvcnQ6YWxsLW9wZW4iLCJyZWxlYXNlX25vdGU6c2tpcCJdfQ==-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
Enhances the performance metrics documentation by explaining how
to use the `meta.description` field for contextualizing render time
events and how to track subsequent page or section loads using
`onPageRefreshStart`.
- Added a section describing the default meaning of render time and how
to provide a custom `description` in the `meta` field of `onPageReady`
for more precise event context.
- Documented the use of `onPageRefreshStart` to distinguish between
initial loads and subsequent refreshes, clarifying that
`meta.isInitialLoad` is set to `false` for refreshes and `true` by
default.
- Included code examples and sample indexed event structures for both
features.
## Summary
This pull request introduces changes to map test directories and plugins
according new SKA
### Test Directory Organization:
*
[`.buildkite/pull_requests.json`](diffhunk://#diff-f6a29d74dea38fb756d38e158cbd1c306158a61f66da3d0633bb64af3000e5cfR44-R45):
Added regex patterns to include directories under `x-pack/platform/test`
and `x-pack/solutions/(search|observability|security)/test` for build
reuse.
[[1]](diffhunk://#diff-f6a29d74dea38fb756d38e158cbd1c306158a61f66da3d0633bb64af3000e5cfR44-R45)
[[2]](diffhunk://#diff-f6a29d74dea38fb756d38e158cbd1c306158a61f66da3d0633bb64af3000e5cfR72-R73)
[[3]](diffhunk://#diff-f6a29d74dea38fb756d38e158cbd1c306158a61f66da3d0633bb64af3000e5cfR99-R100)
*
[`src/platform/packages/shared/kbn-test/src/functional_test_runner/cli/code_owners.ts`](diffhunk://#diff-be6c88de4eca4b556f8b3d63174abc86830a2fc76502ccc318de3753fcf69e42L16-R25):
Expanded `TEST_DIRECTORIES` to include new test paths for `platform` and
`solutions` groups.
### Module Grouping Logic:
*
[`packages/kbn-repo-source-classifier/src/group.ts`](diffhunk://#diff-ca1d6e73c75bc70f1f99a19fdc6cca66ca79dc290de32f222595aa7d0b5099b9R49-R52):
Updated `MODULE_GROUPING_BY_PATH` to include `x-pack/platform/test` and
`x-pack/solutions/*/test` directories under their respective groups with
appropriate visibility settings.
[[1]](diffhunk://#diff-ca1d6e73c75bc70f1f99a19fdc6cca66ca79dc290de32f222595aa7d0b5099b9R49-R52)
[[2]](diffhunk://#diff-ca1d6e73c75bc70f1f99a19fdc6cca66ca79dc290de32f222595aa7d0b5099b9R61-R64)
### Plugin Metadata Updates:
* Various plugin `kibana.jsonc` files under `x-pack/platform/test`:
Added `group` and `visibility` fields to ensure plugins are categorized
under the `platform` group with `private` visibility.
[[1]](diffhunk://#diff-9a5f9434970ecdc05e4e011ea6a677d5df9daff80173d30e871bee57f291dc61R5-R6)
[[2]](diffhunk://#diff-4c6f1ed3260dd9413db2e7ac107bec1c68db883fed9fe5adb4416494bf2ad770R5-R6)
[[3]](diffhunk://#diff-54d92cdb9f449d9787cc79650f65fca02d3c28698d16bcb3a2195e638a0ef3b0R5-R6)
[[4]](diffhunk://#diff-821b5bb2cb432c7817e3bc2be254be13f9ae721f9b6ec48d604df1f5f35a065dR5-R6)
[[5]](diffhunk://#diff-32ee7ae7e104765e023fbb7cc98f770056c51f61e9c33f1530367b04cabe0e68R5-R6)
[[6]](diffhunk://#diff-8f976d082851d9e761a5bb0d8b044aeae7069ab013312e7fed2616932c3fd013R5-R6)
These changes collectively improve the organization and maintainability
of test-related files and plugins within the repository.
## Summary
Transfer ownership of transform-based logic/schema to
@elastic/entity-store team
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Manual version of https://github.com/elastic/kibana/pull/206182 due to
breaking type changes in papaparse
---------
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
Enable the new tabular experience for managing installed integrations,
including support for bulk integration updates.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR marks 429 errors as user errors for every connector using the
subactions framework. It also marks 429 errors of an API call of the
OpenAI connector that does not use the `request` function provided by
the framework.
### 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
## Summary
This PR makes the following fields available as advanced policy options
in Elastic Defend.
* `windows.advanced.events.file.disable_origin_info_collection`
* `windows.advanced.events.process.disable_origin_info_collection`
* `windows.advanced.events.image_load.disable_origin_info_collection`
This advanced policy will allow the following fields in File, Process,
and ImageLoad events to be excluded whenever needed.
* `{ file | process| dll }.origin_url`
* `{ file | process| dll }.origin_referrer_url`
* `{ file | process| dll }.Ext.windows.zone_identifier`
These fields store file origin information. For example, the source from
which a file / process’s PE/DLL was downloaded.
## Release note
{elastic-defend} Adds advanced policy options that let users exclude
origin information from file, process, and image load events when
needed.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [x] 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)
- [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: Gabriel Landau <42078554+gabriellandau@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR lays some ground work for the alert only data view
(https://github.com/elastic/security-team/issues/12589). Main changes
are replacing all the data view creation in AI4SOC and Attack discovery
with one hook. This simplifies the current DV creation as well as making
it easy to switch when we have the alert only data view. No changes to
UI.
- Renamed `useDataview` in attack discovery to `useCreateDataview`
- Relocated it under `sucurity_solutions/public/common/hooks` since it
is now used by AI4SOC as well
- Replaced data view creation logic in AI4SOC pages with this hook
- Used the data view from new data view manager in AI4SOC when feature
flag `newDataViewPickerEnabled` is on.
### Checklist
- [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)
The `useTimefilter` hook that's used throughout the streams UI is
retaining the last resolution of date math to absolute time ranges. This
is helpful to keep the time range stable when switching pages within the
app or making changes on a single page (like testing different grok
patterns) without completely using the current context.
However, it's confusing to move from another app like Discover to the
Streams app because the last resolution might be outdated quite a bit:
* Start in streams with a time range of last 15 mins
* Go to Discover and trigger new searches for 5 mins without changing
the time range - Discover updates the time range on each request (always
resolving "last 15mins")
* Go back to Streams - "last 15mins" still resolves to the last state
from 5 mins ago - if the user has seen a doc in discover, it probably
won't show in the streams UI without the user hitting refresh
This PR improves this user flow by resetting the resolved time range
when loading the streams app - it's kept stable while navigating around
within streams to stay consistent in there but updates once moving away
from the streams UI.
This is not fully solving the issue but it tries to balance the
advantages of the different approaches without too much effort in the
near term. This change does not affect the behavior of Discover or other
apps at all.
---------
Co-authored-by: Thom Heymann <190132+thomheymann@users.noreply.github.com>
This PR updates the function definitions and inline docs based on the
latest metadata from Elasticsearch.
---------
Co-authored-by: Stratoula <efstratia.kalafateli@elastic.co>
## Summary
Closes https://github.com/elastic/kibana/issues/218358
- Cleanups the operators hardcoded signatures. There were cases that I
could not avoid to add some extra signatures but there are been added to
the ones coming from ES so it is ok
- Organizes this script file and makes it more cleaner and reasable. It
has become impossible to navigate so I hope this change improves things
### 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
Fixes https://github.com/elastic/kibana/issues/221224
## Summary
This PR fixes the forward-compatibility test for index mode, which
failed because the index mode was added to Get Data Streams API in 8.19
and 9.1 (see https://github.com/elastic/elasticsearch/pull/122486), so
if Kibana 8.19 is run with Es 9.0, the index mode is always displayed as
"Standard" because Es doesn't return an index mode field.
In this PR, we separate all index mode-related tests into a separate
file, and only run it for Es versions 8.19 or 9.1+.
Closes
[#233](https://github.com/elastic/obs-ai-assistant-team/issues/233)
## Summary
Update `retrieve_elastic_doc` prompt to generate the query always in
English, as the documentation is available only in English.
Co-authored-by: Viduni Wickramarachchi <viduni.wickramarachchi@elastic.co>
Co-authored-by: Søren Louv-Jansen <soren.louv@elastic.co>
**Resolves: #181808**
## Summary
I am fixing the issue of the Rules and Alerts tabs in Security, as well
as the Fleet tab in Management, that gets stalled in air-gapped
environment. I am doing so by enforcing the request to be sent to the
API even when offline.
### Historical context:
During investigation of the original issue #181808 I proved that Kibana
doesn't try to reach to EPR in the air-gapped environment (that is, with
the `xpack.fleet.isAirGapped: true` flag, and WIFI being turned ON). I
commented this
[here](https://github.com/elastic/kibana/issues/181808#issuecomment-2829911511)
and we closed the issue. However, @111andre111 reached out to us saying
that this wasn't enough, as the real issue remains, that is, Kibana
doesn't behave properly when:
- `xpack.fleet.isAirGapped` flag is set to `true`
- there is no Internet connection (WIFI off or cable physically
disconnected)
That's why we reopened the ticket and I restarted the investigation.
My first observation was that when I turn off the WIFI, I cannot see
requests to the API being sent in the Network tab in Dev Tools, most
importantly to the `_bootstrap` endpoint at the first entrance to the
Solution app, and other endpoints later. I searched that the browser
discovers being offline and suppresses such calls. When WIFI is back ON,
then the browser sends these requests. That was exactly what I saw in
the Network tab.
I searched and found an option to force browser to always send the
request, regardless of what it thinks about connectivity. Such option,
`networkMode: 'always'`, can be added to TanStackQuery client.
I started working on adding this option to occurences of `useQuery` and
`useMutation`, and immediately sounded success, as the behavior was
correct. However, @xcrzx rigthfully pointed out, that it would be much
better to only add it to one place, that is the configuration of the
QueryClient. I did it, and to my surprise, the problem returned.
I noticed that adding this option to the QueryClient in Fleet solved the
problem in the Fleet tab immediately, but adding this option to the
`SecuritySolutionQueryClient` does nothing, like it was completely
ignored.
I searched different options and spent two more days debugging the
problem, but then, when paired up again with Dmitrii, he found that the
`SecuritySolutionQueryClient` is overshadowed by some other QueryClient
present in the stack of components much below, the `CasesContext`. That
discovery enabled me to add this new setting to the other QueryClient,
and this fixes the issue. However, we think that it will be worth
investigating why we need this second context, as the situation when one
QueryClient overshadows another one, smells badly and may be a source of
other issues as well (I will reach out to the team responsible for the
CasesContext and ask if we can unify this somehow).
## BEFORE
https://github.com/user-attachments/assets/662dab73-b1bd-4d6b-9d15-c35efab679c6
## AFTER
https://github.com/user-attachments/assets/b905bde0-150d-478d-9734-9003fb5bcf66
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] [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
- [ ] 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>
## Bulk operations support `gap_range`
[issue](https://github.com/elastic/kibana/issues/220772)
### Bug
If a user has 100 rules in total and 20 of them have gaps:
- They click "Show only with gaps" — the UI shows just those 20.
- They hit "Select all" — it says 20 rules are selected.
- But when they perform a bulk action, it ends up applying to **all 100
rules**, not just the 20 with gaps.
This happens because the bulk action uses a query that doesn't include
gap info, so it ends up targeting everything.
### Fix
We now support passing `gaps_range_start` and `gaps_range_end` along
with the bulk action.
On the API side:
- If a query is sent, we use the gap range to find the actual list of
rule IDs with gaps.
- Then we apply the bulk action only to those rules.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR aims to improve `failed_logs` scenario.
In the new format we will have dataStreams with Failure store enabled
and some with failureStore disabled, also it introduces different types
of errors in the failed documents which will give us a more complete
test scenario for our UI.
## Summary
Moves the recurring schedule (rrule) form from the Maintenance Windows
form to a dedicated package.
## Implementation details
~~Because of the tight time constraints we have for this epic, I tried
to change the recurring schedule form as little as possible, keeping the
existing form-lib-based implementation and adding an intermediate layer
to embed the editing UI in larger forms (i.e. MW form). While this is
not particularly elegant, it allows us to build on top of an existing,
tested codebase and to leverage form-lib's validation and state
management capabilities.~~
~~In the context of the MW form, the recurring schedule editor is
treated as a single field. Value and error updates are synced through
form-lib's field hook API:~~
acd6a4823e/x-pack/platform/plugins/shared/alerting/public/pages/maintenance_windows/components/recurring_schedule_field.tsx (L21-L34)
~~Errors are handled internally by the schedule editor, but must still
be surfaced up to the parent form in order to have a consistent validity
state (otherwise submits are not prevented even if errors are shown in
the UI).~~
The recurring schedule form schema and form fields are exported to be
reused in larger form-lib forms.
## References
Closes#219454
### Checklist
- [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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 📓 Summary
Similarly to how it occurred in the Dataset Quality page, the Streams
list page was breaking due to a "HTTP line is larger than 4096 bytes"
error.
https://github.com/user-attachments/assets/ab5af63d-7cb1-4b3d-ab33-3d7acd9359ee
To fix it, this work applies the same chunking strategy to resolve
multiple requests for data streams in parallel to avoid hitting the line
length limit.
I moved the utility into an existing shared package to avoid duplication
and making it available for all the consuming places.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR updates the ES|QL grammars (lexer and parser) to match the
latest version in Elasticsearch.
---------
Co-authored-by: Stratoula <efstratia.kalafateli@elastic.co>
Add a `prompt` API to the Inference plugin. This API allow consumers to
create model-specific prompts without having to implement the logic of
fetching the connector and selecting the right prompt.
Some other changes in this PR:
- the `InferenceClient` was moved to `@kbn/inference-common` to allow
for client-side usage
- Tracing for prompts was added
- A bug with the Vertex adapter and tool call errors was fixed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Resolves#212242.
This resolves an accessibility failure in the `MetricItem` component
where Elastic Charts renders an svg with `role="img"` but no `alt`.
The svg renders an `aria-labelledby` attribute that is generated from
the supplied chart ID. This PR will create an ID for each chart and pass
it as a prop, and then reverse-engineer the expected ID to apply to the
wrapper div, which also contains a label that specifies some of the data
we are passing to `MetricItem`. This will allow screen reader users to
have an idea of the information displayed for a given `MetricItem` if
they choose to zero in on any of the charts on the page.
_NOTE:_ we cannot merge this until Kibana bumps its dependency of
Elastic Charts to
[v70.0.1](https://github.com/elastic/elastic-charts/releases/tag/v70.0.1),
because I had to make an upstream contribution to fix a bug with the
generated `aria-labelledby` ID.
Needs to be tested once https://github.com/elastic/kibana/pull/210579 is
merged.
## Summary
Adds a few key things to check when adding autocomplete support for a
new command.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Replace Enzyme with React Testing Library in the only test that our team
owns and still relied on Enzyme.
### Motivation
On June 4th, it was officially announced that **Enzyme is deprecated in
Kibana**.
As @Dosant put it in the email:
> Move all tests to RTL before we adopt React 19 (realistically a year+
from now). Otherwise, we would need to run Enzyme tests on an older
version of React, making them even less reliable.
### How to verify we have no more Enzyme tests
After checking the `CODEOWNERS` file, these are the folders our team
owns:
<details><summary>Files</summary>
- x-pack/platform/packages/shared/kbn-cloud-security-posture/common
- x-pack/solutions/security/packages/distribution-bar
- x-pack/solutions/security/packages/kbn-cloud-security-posture/graph
- x-pack/solutions/security/packages/kbn-cloud-security-posture/public
- x-pack/solutions/security/plugins/cloud_security_posture
- x-pack/solutions/security/plugins/session_view
-
x-pack/test_serverless/functional/test_suites/security/index.mki_only.ts
-
x-pack/solutions/security/plugins/security_solution/public/asset_inventory
- x-pack/packages/kbn-cloud-security-posture
- x-pack/plugins/cloud_security_posture
- x-pack/plugins/kubernetes_security
-
x-pack/solutions/security/plugins/security_solution/public/common/components/sessions_viewer
-
x-pack/solutions/security/plugins/security_solution/public/cloud_security_posture
- x-pack/solutions/security/plugins/security_solution/public/kubernetes
-
x-pack/solutions/security/plugins/security_solution/server/lib/asset_inventory
-
x-pack/solutions/security/plugins/security_solution/public/flyout/entity_details/universal_right
-
x-pack/solutions/security/plugins/security_solution/public/flyout/csp_details
-
x-pack/platform/plugins/shared/fleet/public/components/cloud_security_posture
-
x-pack/platform/plugins/shared/fleet/public/applications/fleet/sections/agent_policy/create_package_policy_page/single_page_layout/components/cloud_security_posture
-
x-pack/platform/plugins/shared/fleet/public/applications/fleet/sections/agent_policy/create_package_policy_page/single_page_layout/hooks/setup_technology.*
-
x-pack/platform/plugins/shared/fleet/public/applications/integrations/sections/epm/screens/detail/components/cloud_posture_third_party_support_callout.*
- x-pack/test/functional/es_archives/kubernetes_security
- x-pack/test/kubernetes_security
- x-pack/test/functional/es_archives/session_view
- x-pack/test/session_view
- x-pack/test/api_integration/apis/cloud_security_posture/
- x-pack/test/cloud_security_posture_functional/
- x-pack/test/cloud_security_posture_api/
-
x-pack/test_serverless/functional/test_suites/security/config.cloud_security_posture.*
-
x-pack/test_serverless/functional/test_suites/security/ftr/cloud_security_posture/
-
x-pack/test_serverless/api_integration/test_suites/security/cloud_security_posture/
-
x-pack/test/security_solution_cypress/cypress/e2e/cloud_security_posture/misconfiguration_contextual_flyout.cy.ts
-
x-pack/test/security_solution_cypress/cypress/e2e/cloud_security_posture/vulnerabilities_contextual_flyout.cy.ts
- x-pack/test/security_solution_cypress/cypress/e2e/asset_inventory
</details>
To verify we have no more tests relying on Enzyme, simply search in your
editor for the term "enzyme" and paste the following line in _files to
include_:
```
x-pack/platform/packages/shared/kbn-cloud-security-posture/common,x-pack/solutions/security/packages/distribution-bar,x-pack/solutions/security/packages/kbn-cloud-security-posture/graph,x-pack/solutions/security/packages/kbn-cloud-security-posture/public,x-pack/solutions/security/plugins/cloud_security_posture,x-pack/solutions/security/plugins/session_view,x-pack/test_serverless/functional/test_suites/security/index.mki_only.ts,x-pack/solutions/security/plugins/security_solution/public/asset_inventory,x-pack/packages/kbn-cloud-security-posture,x-pack/plugins/cloud_security_posture,x-pack/plugins/kubernetes_security,x-pack/solutions/security/plugins/security_solution/public/common/components/sessions_viewer,x-pack/solutions/security/plugins/security_solution/public/cloud_security_posture,x-pack/solutions/security/plugins/security_solution/public/kubernetes,x-pack/solutions/security/plugins/security_solution/server/lib/asset_inventory,x-pack/solutions/security/plugins/security_solution/public/flyout/entity_details/universal_right,x-pack/solutions/security/plugins/security_solution/public/flyout/csp_details,x-pack/platform/plugins/shared/fleet/public/components/cloud_security_posture,x-pack/platform/plugins/shared/fleet/public/applications/fleet/sections/agent_policy/create_package_policy_page/single_page_layout/components/cloud_security_posture,x-pack/platform/plugins/shared/fleet/public/applications/fleet/sections/agent_policy/create_package_policy_page/single_page_layout/hooks/setup_technology.*,x-pack/platform/plugins/shared/fleet/public/applications/integrations/sections/epm/screens/detail/components/cloud_posture_third_party_support_callout.*,x-pack/test/functional/es_archives/kubernetes_security,x-pack/test/kubernetes_security,x-pack/test/functional/es_archives/session_view,x-pack/test/session_view,x-pack/test/api_integration/apis/cloud_security_posture/,x-pack/test/cloud_security_posture_functional/,x-pack/test/cloud_security_posture_api/,x-pack/test_serverless/functional/test_suites/security/config.cloud_security_posture.*,x-pack/test_serverless/functional/test_suites/security/ftr/cloud_security_posture/,x-pack/test_serverless/api_integration/test_suites/security/cloud_security_posture/,x-pack/test/security_solution_cypress/cypress/e2e/cloud_security_posture/misconfiguration_contextual_flyout.cy.ts,x-pack/test/security_solution_cypress/cypress/e2e/cloud_security_posture/vulnerabilities_contextual_flyout.cy.ts,x-pack/test/security_solution_cypress/cypress/e2e/asset_inventory
```
So your editor should look like this:
<img width="775" alt="Screenshot 2025-06-06 at 12 41 21"
src="https://github.com/user-attachments/assets/231b93d7-c9c6-4bd6-a1bb-422f1f7161a2"
/>
### 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)
### Identify risks
No risks at all.
Co-authored-by: Paulo Silva <paulo.henrique@elastic.co>
## Summary
Introduces a new config in the security serverless plugin to hide other
plugins' UI (making them inaccessible).
It uses the `core.application.registerAppUpdater` API.
@elastic/kibana-visualizations I did some cleanup around the custom
global search's `registerResultProvider`, which seems to be a workaround
from times before `visibleIn` functionalities. This way, the search
result depends on the plugin being accessible. My change introduces a
small text update in the search result, though. To me, now it looks more
consistent with the rest of the analytics applications. Let me know if
you think that's an issue.
| Prev | New |
|------|-----|
|
|
|
### Goal
This is needed by the `AI4DSOC` team to hide some applications outside
the Security Solution:
```yaml
xpack.securitySolutionServerless.inaccessibleApps:
- dashboards
- visualize
- maps
- lens
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Tomasz Ciecierski <tomasz.ciecierski@elastic.co>
Resolves https://github.com/elastic/kibana/issues/219974
## Summary
Adds kibana config `xpack.alerting.enabledRuleTypes: string[]`, which
can be used to "enable" specific rule types. If config is not set, all
rule types will be registered (as long as they are not disabled). If
config is set, only rule types explicitly allow-listed will be
registered.
If a rule type is both in the disabled and enabled allow-list, it will
not be registered and a warning will be logged.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
When checking to see if a Lens visualization is suitable for creating an
anomaly detection job, we should check to see if it is using ES|QL much
earlier on in the process.
This PR adds the `isOfAggregateQueryType` into the `isCompatible`
function in the action.
Also moves some of the imports around to be more efficient.
## Summary
- Add the `tools.registerProvider` API to allow registering dynamic tool
providers to onechat
- Change the tool and agent serialized id format to both use
`{providerId}::{toolId/agentId}`
- Fix a bug causing tools to have an invalid name when passed down to
the LLM from the chat agent
- remove `tool.name`, as it was misleading and tool.id should be
sufficient for now
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
2025-06-07 19:37:47 +01:00
11025 changed files with 334653 additions and 217934 deletions
/x-pack/test/api_integration/services/infraops_source_configuration.ts @elastic/obs-ux-infra_services-team @elastic/obs-ux-logs-team # Assigned per https://github.com/elastic/kibana/pull/34916
/x-pack/test/api_integration/services/infraops_source_configuration.ts @elastic/obs-ux-infra_services-team @elastic/obs-ux-logs-team # Assigned per https://github.com/elastic/kibana/pull/34916
/x-pack/solutions/observability/plugins/observability/public/pages/overview @elastic/obs-ux-infra_services-team # Assigned to this team since it mostly uses infra/APM components
/x-pack/solutions/observability/plugins/observability/public/pages/overview @elastic/obs-ux-infra_services-team # Assigned to this team since it mostly uses infra/APM components
/x-pack/test/ftr_apis/common/fixtures/es_archiver/base_data/space_1.json @elastic/kibana-security # Assigned per only use: https://github.com/elastic/kibana/blob/main/x-pack/test/ftr_apis/security_and_spaces/apis/test_utils.ts#L33
/x-pack/platform/test/ftr_apis/common/fixtures/es_archiver/base_data/space_1.json @elastic/kibana-security # Assigned per only use: https://github.com/elastic/kibana/blob/main/x-pack/platform/test/ftr_apis/security_and_spaces/apis/test_utils.ts#L33
/x-pack/test/ftr_apis/common/fixtures/es_archiver/base_data/default_space.json @elastic/kibana-security # Assigned per only use: https://github.com/elastic/kibana/blob/main/x-pack/test/ftr_apis/security_and_spaces/apis/test_utils.ts#L33
/x-pack/platform/test/ftr_apis/common/fixtures/es_archiver/base_data/default_space.json @elastic/kibana-security # Assigned per only use: https://github.com/elastic/kibana/blob/main/x-pack/platform/test/ftr_apis/security_and_spaces/apis/test_utils.ts#L33
/x-pack/platform/test/api_integration/apis/cloud @elastic/kibana-security # Assigned per https://github.com/elastic/kibana/pull/198444
/x-pack/platform/test/api_integration/apis/cloud @elastic/kibana-security # Assigned per https://github.com/elastic/kibana/pull/198444
/src/platform/test/plugin_functional/snapshots/baseline/hardening @elastic/kibana-security # Assigned per https://github.com/elastic/kibana/pull/190716
/src/platform/test/plugin_functional/snapshots/baseline/hardening @elastic/kibana-security # Assigned per https://github.com/elastic/kibana/pull/190716
/x-pack/solutions/security/plugins/security_solution/common/search_strategy/security_solution/hosts @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/solutions/security/plugins/security_solution/common/search_strategy/security_solution/network @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/solutions/security/plugins/security_solution/common/search_strategy/security_solution/user @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/solutions/security/plugins/security_solution/public/explore @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/solutions/security/plugins/security_solution/server/search_strategy/security_solution/factory/hosts @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/solutions/security/plugins/security_solution/server/search_strategy/security_solution/factory/network @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/solutions/security/plugins/security_solution/server/search_strategy/security_solution/factory/users @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/test/security_solution_cypress/cypress/e2e/explore @elastic/security-threat-hunting-investigations # soon partially transfer to @elastic/security-entity-analytics
/x-pack/test/security_solution_cypress/cypress/screens/hosts @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/test/security_solution_cypress/cypress/screens/network @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/test/security_solution_cypress/cypress/screens/users @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/test/security_solution_cypress/cypress/tasks/hosts @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/test/security_solution_cypress/cypress/tasks/network @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/test/security_solution_cypress/cypress/tasks/users @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/test/functional/es_archives/auditbeat/hosts @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
/x-pack/test/functional/es_archives/auditbeat/users @elastic/security-threat-hunting-investigations # soon transfer to @elastic/security-entity-analytics
x-pack/test/security_solution_api_integration/test_suites/explore @elastic/security-threat-hunting-investigations # soon partially transfer to @elastic/security-entity-analytics
@ -16,6 +16,7 @@ Reviewers should verify this PR satisfies this list as well.
- [ ] 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.
- [ ] 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
- [ ] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed
- [ ] 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)
- [ ] 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)
- [ ] Review the [backport guidelines](https://docs.google.com/document/d/1VyN5k91e5OVumlc0Gb9RPa3h1ewuPE705nRtioPiTvY/edit?usp=sharing) and apply applicable `backport:*` labels.
"\nOptional flag to indicate that these alerts should not be space aware. When set\nto true, alerts for this rule type will be created with the `*` space id."
"\nIndicates that the rule type is managed internally by a Kibana plugin.\nAlerts of internally managed rule types are not returned by the APIs and thus not shown in the alerts table."
"\nThis version key was used to store Kibana version information from versions 7.3.0 -> 8.11.0.\nAs of version 8.11.0, the versioning information is now per-embeddable-type and is stored on the\nembeddable's input. This key is needed for BWC, but its value will be removed on Dashboard save."
