## 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
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.
## 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
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
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
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>
## 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
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
## 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
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.
This reverts commit 11247fe50b.
We started seeing consistent failures of tests in MKI and the failure
logs are indicating a problem with the recent monaco editor update. I've
checked this revert commit with the MKI pipeline and these failures
didn't occur anymore.
## Summary
A few files were missed in this previous
[PR](https://github.com/elastic/kibana/pull/221867) and are now moved to
their correct folders:
- most of them were moved to
`detection_engine/rule_management_ui/components`
- a couple of files were moved under `common/components` as they are
used both within the `detection_engine` folder and the `exceptions`
folder
_**No code changes are implemented whatsoever!**_
**_If there are any folders or files that you feel should live in a
specific folder, let me know. I'm happy to move things around some
more!_**
### 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 Saved Object mapping for Monitoring Entity
Source Configurations to support Privileged User Monitoring.
### ✅ Implemented
* Saved object mapping schema aligned with the [current
spec](https://docs.google.com/document/d/1-c6A82p2CCjYz8Mb6tL6R7BXXemQ4mpWZliKqki0SWo/edit?tab=t.0#heading=h.4axxr154e1lc)
* DescriptorClient to handle saved object methods
* OpenAPI schema and generated types
* Implemented Data Client - SO operations exposed via GET and POST API
* Created route and registered with privmonRoutes
* Data Client Unit Testing
* Rename typename of "monitoring_entity_source-sync" ->
"entity-analytics-monitoring-entity-source"
[Figma
](https://www.figma.com/board/yBr1pBDGu4JqNxb5ZrULtk/MonEntitySourceSyncTask?node-id=0-1&p=f&t=4hQaGsdvOpghi4QS-0)-
currently working in the pink box
## Testing Steps:
1. privilegeMonitoringEnabled: true - set this flag
2. From Dev tools - create a saved object via POST (below) and view this
saved object via GET (also below):
```
POST kbn:/api/entity_analytics/monitoring/entity_source
{
"type": "some-type-here",
"name": "name-here",
"managed": false,
"indexPattern": "logs-*",
"enabled": true,
"integrationName": "Okta",
"matchers": [
{
"fields": ["user.role"],
"values": ["admin"]
}
],
"filter": {}
}
```
**Expected output:**
```
{
"type": "some-type-here",
"name": "name-here",
"managed": false,
"indexPattern": "logs-*",
"enabled": true,
"integrationName": "Okta",
"matchers": [
{
"fields": [
"user.role"
],
"values": [
"admin"
]
}
],
"filter": {}
}
```
GET Example
```
GET kbn:/api/entity_analytics/monitoring/entity_source
```
Output for get, expected to be the same as that for POST.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
## Summary
This PR is a follow up of [this previous
one](https://github.com/elastic/kibana/pull/220590) that removed the
advanced setting allowing users to switch between the Session View
component rendered in the expandable flyout and as an overlay to the
alerts table.
After removing related to the [Session View displayed as
overlay](https://github.com/elastic/kibana/pull/220596), this PR removes
all code related to the Analyzer Graph component when displayed as an
overlay. This is applied to the Alerts page alerts table and to
Timeline.
**_As [this previous PR](https://github.com/elastic/kibana/pull/220590)
had removed the ability to switch back to this overlay mode, this PR
does not introduces any changes visible in the UI. If anything looks
different or behaves differently, then there is an issue and this PR
should not be merged._**
Analyzer Graph in expandable flyout remains unchanged:
https://github.com/user-attachments/assets/eb110ecc-d857-475a-a9e3-1bd0ff4fa5ef
### Notes
The timeline adds a `graphEventId` parameter to the url. This was used
to reopen the timeline to the Analyzer tab. This functionality was
broken a few months back when we enabled the advanced settings by
default. This functionality is completely removed in this PR, as we now
do not have the `graphEvenId` url parameter anymore. This was run by the
team or product and we're ok with it.
### 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 was originally addressing some dark-mode issues in the timeline.
Those issues has been already fixed upstream but there are still
valuable contributions in this PR that should be considered anyways:
1. unit test has been refactor to use `react-testing-library` instead of
`enzyme`
2. the styling for the timeline has been moved from `styled-components`
to `emotion`
3. the color tokens have been updated according to #199715
> [!important]
>
> #199715 also suggests to move away from the `success` tokens. However,
in the drag-and-drop use-case the EUI team has confirmed that for now we
should prefer the `success` tokens until proper drag-and-drop tokens
will be produced
## Screenshots
> [!important]
>
> Light mode was not visually impacted by these changes, therefore no
screenshots have been provided
### Empty query builder
- The background of the query builder matches the general background now
- The dashed border is a little bit lighter than before
**Before**
<img width="1205" alt="dark-1-before"
src="https://github.com/user-attachments/assets/2008ddd3-f801-4646-8407-045de4dc3ebd"
/>
**After**
<img width="1206" alt="dark-1-after"
src="https://github.com/user-attachments/assets/a93e4b7e-6666-4805-91d1-ab9b4c3f5b82"
/>
### Drag-and-drop query builder
- The border color is a bit washed up compared to the original one
- The background green is darker and less teal
**Before**
<img width="1203" alt="dark-2-before"
src="https://github.com/user-attachments/assets/b3d85b9e-3821-44c5-adaa-99719ca3aef6"
/>
**After**
<img width="1074" alt="Screenshot 2025-06-04 at 18 45 16"
src="https://github.com/user-attachments/assets/41b4cbca-4654-4571-a59c-4976ca0930a5"
/>
## Code overview
- `[...]/timelines/components/timeline/data_providers/index.tsx`
- Replace `styled-components` with `emotion`
- `styled-components` have an issue where the theme is always set to
`LIGHT` in this component
- after a bit of debugging the issue seems to come from eui, but the
investigation was interrupted because
- `styled-components` are deprecated anyways
- `[...]/timelines/components/timeline/data_providers/index.test.tsx`
- Refactor unit test from using `enzyme` to `react-testing-library`
## Credits
Huge thanks to @kapral18 for working on this with me.
### Checklist
<details>
<summary>Expand</summary>
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)
- [ ] ...
</details>
---------
Co-authored-by: Karen Grigoryan <karen.grigoryan@elastic.co>
## Summary
This is the first PR related to
https://github.com/elastic/kibana/issues/212570. (more up-to-date
information in the [design
doc](https://docs.google.com/document/d/1DZKTPl7UryYjpjVMNhIYbE82OADVOg93-d02f0ZQtUI/edit?tab=t.0))
It only introduces the `incremental_id` field to the cases object and
introduces the new "id incrementer" saved object. Tests and migrations
have been changed accordingly and the `incremental_id` field is removed
from cases import/export.
The motivation behind releasing these changes first is so that
serverless deployments will know about the new field and SO once the
other changes are coming.
### 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>
Closes https://github.com/elastic/kibana/issues/221683
PR does the following
* Consolidates `SharedDashboardState` and `DashboardLocatorParams` types
into a single type `DashboardLocatorParams`.
* Combine URL parsing and locator parsing into single function,
`extractDashboardState`. Previously this was done in 2 seperate code
paths: `loadDashboardHistoryLocationState` for locator state and
`loadAndRemoveDashboardState` for URL state.
* `extractDashboardState` takes `unknown` instead of
`DashboardLocatorParams`. Input value could contain legacy versions of
`DashboardLocatorParams` or really anything since its provided in the
URL by users. `unknown` better reflects that the input could be a lot of
different things.
* `extractDashboardState` uses duck typing to try its best to convert
from legacy versions of `DashboardLocatorParams` to current
`DashboardState` type
* Replaced `bwc_shared_urls` functional test with unit tests
* Added function test `bwc_short_urls` functional tests to ensure stored
URLs continue to work. Added tests for 8.14, 8.18, and 8.19 URL state.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Devon Thomson <devon.thomson@elastic.co>
# Summary
This PR merges Threat Intelligence plugin with security solution, in
order to remove duplicated and unnecessary code introduced as a bridge
between the TI plugin and Security Solution + to simpify maintenance. No
new functionality is implemented here, other than changing imports and
some dependendies to use security solution code directly, without weird
bridges or hacks / indirections.
## Testing
Navigate to threat intelligence plugin / indicators and try clicking
around. It is hard to list every feature we have there
but in general it should work without errors.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR is a follow up of [this previous
one](https://github.com/elastic/kibana/pull/220590) that removed the
advanced setting allowing users to switch between the Session View
component rendered in the expandable flyout and as an overlay to the
alerts table.
This PR focuses on removing all code related to the Session View
component when displayed as an overlay of the Alerts page alerts table
and in Timeline.
**_As the previous PR had removed the ability to switch back to this
overlay mode, this PR does not introduces any visible changes in the UI.
If anything looks different or behaves differently, then there is an
issue and this PR should not be merged._**
Session View in expandable flyout remains unchanged:
https://github.com/user-attachments/assets/54107185-ff9b-4090-ac0d-7c4f3f1a421f
### 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 is only moving files and update file paths. No code changes are
implemented whatsoever.
The PR focuses on moving a bunch of folders and files that lived under
the `detections` folder but were actually only used within the
`detection_engine` folder.
- if the files/folders were used within a single `detection_engine`
folder (like for example `rule_actions_overflow` is only used within
`rule_details_ui`) then things were moved closest to where it was used)
- if the files/folders were used within multiple `detection_engine`
folders, then things were moved into a `components` folder under the
existing `common` folder at the root of `detection_engine`
**_If there are any folders or files that you feel should live in a
specific folder, let me know. I'm happy to move things around some
more!_**
### 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/1547
Closes https://github.com/elastic/kibana/issues/190342
Closes https://github.com/elastic/kibana/issues/197716
## Summary
This PR adds the ability for collapsible sections to be created and
managed on Dashboards.
https://github.com/user-attachments/assets/c5c046d0-58f1-45e1-88b3-33421f3ec002
> [!NOTE]
> Most of the work for developing collapsible sections occurred in PRs
contained to the `kbn-grid-layout` package (see [this meta
issue](https://github.com/elastic/kibana/issues/190342) to track this
work) - this PR simply makes them available on Dashboards by adding them
as a widget that can be added through the "Add panel" menu. As a result
of this, most work is contained in the Dashboard plugin - changes made
to the `kbn-grid-layout` package only include adding IDs for additional
tests that were added for the Dashboard integration.
### Technical Details
#### Content Management Schema
The content management schema allows for panels and sections to be mixed
within the single `panels` key for a dashboard **without** worrying
about section IDs; for example:
```
{
"panels": [
{
// this is a simplified panel
"gridData": {
"x": 0,
"y": 0,
"w": 12,
"h": 8,
},
"panelConfig": { ... },
},
{
// this is a section
"gridData": {
"y": 9,
},
"collapsed": false,
"title": "Section title",
"panels": [
{
// this is a simplified panel
"gridData": {
"x": 0,
"y": 0,
"w": 24,
"h": 16,
},
"panelConfig": { ... },
},
],
},
]
}
```
#### Saved Object Schema
The dashboard saved object schema, on the other hand, separates out
sections and panels under different keys - this is because, while we are
stuck with panels being stored as `panelJSON`, I didn't want to add much
to this. So, under grid data for each panel, they have an optional
`sectionId` which then links to a section in the `sections` array in the
saved object:
```
{
"panelsJSON": "<...> \"gridData\":{\"i\":\"panelId\",\"y\":0,\"x\":0,\"w\":12,\"h\":8,\"sectionId\":\"someSectionId\"} <...>"
"sections": [
{
"collapsed": false,
"title": "Section title",
"gridData": {
"i": "someSectionId",
"y": 8.
}
}
],
}
```
This allows sections to be serialized **without** being stringified.
This storage also matches how we store this data in runtime using
`layout`.
### 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] 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)
## Release note
Adds collapsible sections to Dashboard, which allow panels to grouped
into sections that will not load their contents when their assigned
section is collapsed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/217683
## Summary
Follow up of https://github.com/elastic/kibana/pull/217144
Handle errors occurring when `sync_uninstalled_integrations` is enabled
on remote outputs; these errors are now saved under
`latest_uninstall_failed_attempts` and will be reported by
`api/fleet/remote_synced_integrations/<output_id>/remote_status` and
`api/fleet/remote_synced_integrations/remote_status`.
- I added a new field in the response of these apis that allows to
understand at a glance the install status of an integration on both
cluster:
```
install_status: {
main: 'installed',
remote: 'not_installed',
}
```
- Added a new "warning" state for synced integrations
- Handled the case when an integration was successfully uninstalled from
both clusters (marked as complete)
- Removed the "throw error" for the case of `outputId` in favour of a
regular error in the response
### Testing
- Follow steps in https://github.com/elastic/kibana/pull/217144
- Check that the errors reported in `latest_uninstall_failed_attempts`
are now visible when querying
`api/fleet/remote_synced_integrations/<output_id>/remote_status` under
the new "warning" field. This can be done also from the UI, checking the
network tab
-
<img width="2111" alt="Screenshot 2025-05-20 at 11 17 13"
src="https://github.com/user-attachments/assets/80a077e7-8b1b-4d04-abe9-0ef0cc44def8"
/>
Response for the failed uninstalled integration:
```
{
"package_name": "akamai",
"package_version": "2.28.0",
"install_status": {
"main": "not_installed",
"remote": "installed"
},
"updated_at": "2025-05-21T09:34:34.492Z",
"sync_status": "warning",
"warning": "Unable to remove package akamai:2.28.0 with existing package policy(s) in use by agent(s) at Fri, 23 May 2025 07:54:41 GMT"
},
```
### UI changes
The integrations uninstalled from the main cluster are now shown with a
greyed out text and the warning is shown on screen as well:
<img width="703" alt="Screenshot 2025-05-23 at 10 37 57"
src="https://github.com/user-attachments/assets/a6900e0b-96cc-4bcc-8f16-db0001f55de3"
/>
### Checklist
- [ ]
[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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR simplifies the weekly EUI upgrade and backport process by
conditionally aliasing `@elastic/eui` in shared deps webpack
configurations.
# Backstory
The EUI team (@elastic/eui-team) is responsible for keeping EUI up to
date in Kibana. Historically, this has been a relatively straightforward
(yet time-consuming) process, however, due to `8.x` backport
complexities caused by it using a different theme, it has become way
more demanding on everybody involved.
EUI is released on weekly basis. Each week, we release official EUI
versions tagged `latest` in npmjs and get a PR open that updates the
package in kibana `main`.
Our upgrade PRs tend to require anywhere between 2 and 25 codeowner
reviews due to the number of snapshots we need to update while working
on the EUI upgrade PRs. These snapshot changes are 99% of the time
harmless, yet it still takes 2+ full workdays to ping teams and get all
reviews necessary to get the PR merged. Generally speaking, we aim to
have the upgrade PR open on Monday and merged by Friday.
## The issue with `8.x` backports
Kibana 8.x uses the Amsterdam theme instead of Borealis, which is used
in Kibana 9.0 and up. To keep 8.x up to date, for each official EUI
release we prepare another special Kibana 8.x only release of EUI (e.g.,
`101.2.0-amsterdam.0`). These special releases have the theme hardcoded
to Amsterdam at compile-time to avoid any initial theme errors Kibana
could otherwise experience. This is done primarily because some areas in
Kibana read EUI theme values outside of React components, and we have no
stable way to determine what the active theme is since there's no
context information. This is where we need to fall back to Amsterdam in
8.x and Borealis in 9.x.
**Since there are two different EUI versions - one for Kibana `main` and
9.0, and another for 8.x branches, we cannot use the automated backports
feature**. Instead, we open two separate PRs and configure backport
labels accordingly. Having two PRs is far from ideal since codeowners
need to review our changes twice, and we're more likely to make
mistakes.
# Our proposal
Following the recently introduced React version switching logic, we want
to conditionally switch between two `@elastic/eui` releases depending on
the kibana branch/version while keeping automated backports possible.
To achieve that, I added a dependency alias `@elastic/eui-amsterdam`
that points to the Amsterdam EUI release and configured `resolve.alias`
in shared deps to resolve the correct dependency based on the optional
`EUI_AMSTERDAM` environment variable. When this change is merged to
`main` and backported to `9.0` and `8.19`, I'll open a follow-up PR to
the `8.19` branch updating the default value of `EUI_AMSTERDAM` to
`"true"`. This should result in no conflicts and be easy to follow.
Since 8.19 [uses the Amsterdam release of
`@elastic/eui`](https://github.com/elastic/kibana/blob/8.19/package.json#L126)
(e.g., `101.2.0-amsterdam.0`), there's no risk backporting this PR as-is
without `EUI_AMSTERDAM` configured beforehand.
## What does it change?
With this setup, we'll be able to update versions of `@elastic/eui` and
`@elastic/eui-amsterdam` at the same time in a single PR and make use of
automated kibana backports. There will be only one set of changes to
review by codeowners, and if there are any failing tests when
backporting to `8.19` due to, for example, changed color values, we can
follow the regular kibana procedures and fix them right in the created
backport PR. It'll simplify our workflow quite drastically while keeping
the same level of quality.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Implements the onechat tool registry RFC.
Fix https://github.com/elastic/search-team/issues/9938
Fix https://github.com/elastic/search-team/issues/10019
This PR introduces the following artifacts:
**plugins:**
- `onechat`
**packages:**
- `@kbn/onechat-common`
- `@kbn/onechat-server`
- `@kbn/onechat-browser`
## Tool APIs overview
### Registering a tool
```ts
class MyPlugin {
setup(core: CoreSetup, { onechat }: { onechat: OnechatPluginSetup }) {
onechat.tools.register({
id: 'my_tool',
name: 'My Tool',
description: 'My very first tool',
meta: {
tags: ['foo', 'bar'],
},
schema: z.object({
someNumber: z.number().describe('Some random number'),
}),
handler: ({ someNumber }, context) => {
return 42 + someNumber;
},
});
}
}
```
### Executing a tool
Using the `execute` API:
```ts
const { result } = await onechat.tools.execute({
toolId: 'my_tool',
toolParams: { someNumber: 9000 },
request,
});
```
Using a tool descriptor:
```ts
const tool = await onechat.tools.registry.get({ toolId: 'my_tool', request });
const { result } = await tool.execute({ toolParams: { someNumber: 9000 } });
```
With error handling:
```ts
import { isToolNotFoundError } from '@kbn/onechat-common';
try {
const { result } = await onechat.tools.execute({
toolId: 'my_tool',
toolParams: { someNumber: 9000 },
request,
});
} catch (e) {
if (isToolNotFoundError(e)) {
throw new Error(`run ${e.meta.runId} failed because tool was not found`);
}
}
```
### Listing tools
```ts
const tools = await onechat.tools.registry.list({ request });
```
*More details and example in the plugin's readme.*
### What is **not** included in this PR:
- tool access control / authorization - we have a dedicated RFC
- dynamic tool registration / permissions checks part/of depends on the
authorization RFC
- feature / capabilities - will come with browser-side and HTTP APIs
- fully defining tool meta - hard to do now
- filter parameters for the tool list API - depends on the meta being
defined
*Those will be follow-ups*. Everything else from the RFC should be
there.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR aims to answer questions about the implementation details for
https://github.com/elastic/kibana-team/issues/1328
We'd like to trigger an intercept dialog to users at specific time
intervals that vary and depend on different parameters, see the PRD
linked in the aforementioned issue.
This MVP takes an approach such that the constraints listed below are
resolved;
- Have the intercept be specific to a single user
- Define a strategy to configure triggers that can vary for the
intercept that's not dependent on the client
How does this work?
- A generic plugin has been created which when declared as dependency
can be used to register and schedule an intercept that should be
presented to the user, this plugin is what's been used for the product
intercept dialog.
- To handle rendering the UI component that gets displayed to the users,
in this PR we hook into core's existing notification system, through the
notification coordinator system that's been created so that we don't
have a situation where an intercept is being displayed whilst a user
might have a toast being rendered to them, if there's an intercept to be
displayed said intercept would not be displayed till the user is
completely done interacting with the toast. [See it's implementation
details
here](src/core/packages/notifications/browser-internal/src/notification_coordinator.ts)
and
[here](x-pack/platform/plugins/private/intercepts/public/prompter/service/intercept_dialog_service.tsx)
for how it's integrated.
- The plugin provides some bootstrap data through an endpoint that every
user calls on page load, ideally this would need to happen just the once
on page load, we then compute when a user should see a trigger
leveraging the bootstrap data provided for the particular registered
trigger in question, the returned data returns the following data as
seen below;
<img width="476" alt="Screenshot 2025-03-27 at 18 01 12"
src="https://github.com/user-attachments/assets/c747b6c8-70d0-4305-b555-ec9998b180c1"
/>
Given we have this data we might then have a flow for triggering the
intercept on the client based of the bootstrap data like so;
```mermaid
flowchart TD
A[State Bootstrap] --> B{Has data?}
B -->|No| C(Do Nothing)
B -->|Yes| D{Does computed runs since trigger registration match stored
user trigger run feedback value?}
D -->|No| E[setup timer to display an intercept in that time]
E -->|on completion| G[setup interval to display intercept in the
future]
D -->|Yes| G
G -->|repeat| G
```
reloading the page restarts the entire process.
## Telemetry
The intercept component provided by defaults records telemetry for
intercept registration, acknowledgement (differentiated into dismissal
and completion), alongside registration overload.
## Visuals
<!--
https://github.com/user-attachments/assets/b39a506c-a119-40e8-9152-258d78691f28
-->
<!--
https://github.com/user-attachments/assets/f564b4bc-9ad9-4e19-8158-6e154ef52fc2
-->
<img width="738" alt="Screenshot 2025-05-07 at 19 41 23"
src="https://github.com/user-attachments/assets/902c6d0b-9299-44bd-8808-4ad97227d0da"
/>
## Testing this PR
- Pull this branch to your machine
- Add the following to your `kibana.dev.yml`, to enable the intercept to
run and be visible
```yml
xpack.intercepts.enabled: true
xpack.product_intercept.enabled: true
xpack.product_intercept.interval: '30s'
```
<!--
### 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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Recently, we discovered that a `DELETE` request to one of our ML
endpoints does not work correctly in Safari.
After further investigation, it turns out that `DELETE` requests without
a body fail in Safari.
The issue occurs only within the Kibana Dev server, so there is no
impact on end users.
This is most likely due to a header set in the
`packages/kbn-cli-dev-mode/src/base_path_proxy/http1.ts` file. The issue
mentioned in the comment has already been resolved, and everything
appears to work correctly without this outdated workaround.
To reproduce the error:
1. Start Kibana locally and open it with Safari.
2. Find an endpoint that uses the `DELETE` method and does not have a
body specified.
3. ^ For example, go to Observability -> Cases and create a new case.
4. Go back to the cases list and try to delete the case
Related: https://github.com/elastic/kibana/pull/216397
This fixes a bug in the Lock Manager where an expired lock can be
acquired, but the token and metadata is not updated. This means that the
lock cannot be released. Instead it is automatically released when the
TTL expires.
## Summary
Part of https://github.com/elastic/kibana-team/issues/1503
This PR is mostly about moving tests from `x-pack/test` to
`x-pack/platform/test`
Before:
```
x-pack/test/
| - api_integration/apis/management/
| - api_integration/apis/monitoring/
| - api_integration/apis/osquery/
| - automatic_import_api_integration
| - monitoring_api_integration/
| - saved_object_api_integration/
```
After:
```
x-pack/platform/test/
| - api_integration/apis/management/
| - api_integration/apis/monitoring/
| - api_integration/apis/osquery/
| - automatic_import_api_integration
| - monitoring_api_integration/
| - saved_object_api_integration/
```
Additional:
- `x-pack/test/api_integration/apis/osquery/config.ts` was move to
platform stateful manifest to match `osquery` plugin (shared, platform)
- `automatic_import_api_integration` config files were moved to platform
stateful manifest to match `automatic_import` plugin (shared, platform)
- `x-pack/test/common/lib/test_data_loader.ts` is required by SO api
tests and was copied to `x-pack/platform/test/common`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/205531Closes#219877.
Closes https://github.com/elastic/kibana/issues/213153
Closes https://github.com/elastic/kibana/issues/150920
Closes https://github.com/elastic/kibana/issues/203130
### Overview
The embeddable framework has two types of state: `SerializedState` and
`RuntimeState`.
`SerializedState` is the form of the state when saved into a Dashboard
saved object. I.e. the References are extracted, and state saved
externally (by reference) is removed. In contrast `RuntimeState` is an
exact snapshot of the state used by the embeddable to render.
<b>Exposing SerializedState and RuntimeState was a mistake</b> that
caused numerous regressions and architectural complexities.
This PR simplifies the embeddable framework by only exposing
`SerializedState`. `RuntimeState` stays localized to the embeddable
implementation and is never leaked to the embeddable framework.
### Whats changed
* `ReactEmbeddableFactory<SerializedState, RuntimeState, Api>` =>
`EmbeddableFactory<SerializedState, Api>`
* `deserializeState` removed from embeddable factory. Instead,
`SerializedState` is passed directly into `buildEmbeddable`.
* `buildEmbeddable` parameter `buildApi` replaced with `finalizeApi`.
`buildApi({ api, comparators })` => `finalizeApi(api)`.
* The embeddable framework previously used its knowledge of
`RuntimeState` to setup and monitor unsaved changes. Now, unsaved
changes setup is pushed down to the embeddable implementation since the
embeddable framework no longer has knowledge of embeddable RuntimeState.
### Reviewer instructions
<b>Please prioritize reviews.</b> This is a large effort from our team
and is blocking many other initiatives. Getting this merged is a top
priority.
This is a large change that would best be reviewed by manually testing
the changes
* adding/editing your embeddable types
* Ensuring dashboard shows unsaved changes as expected
* Ensuring dashboard resets unsaved changes as expected
* Ensuring dashboard does not show unsaved changes after save and reset
* Returning to a dashboard with unsaved changes renders embeddables with
those unsaved changes
---------
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
Co-authored-by: Nathan Reese <reese.nathan@elastic.co>
Co-authored-by: Nick Peihl <nick.peihl@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Catherine Liu <catherine.liu@elastic.co>
Co-authored-by: Ola Pawlus <98127445+olapawlus@users.noreply.github.com>
## Summary
Refactors color mapping logic to store raw values in save objects.
Main changes:
- Instead assignments having a single rule with many values, we now have
assignments with multiple rules of varying types with a single value.
- As per the previous change, there is no more explicit `auto` rule,
this is now implicit when there are no rules in the assignment.
- Raw values can now be raw and in cases such as `RangeKey`s and
`MultiValueKey`s can be instance values. This is not ok for storing in
redux nor the SO so be have added a `serialize` methods to facilitate
this value storage. Code changes attempt to identify which value is used
based on variable/param names and type aliases as both are `unknown`.
- For values that are non-string or non-number types, we no longer allow
creating custom matching options.
- Values are now correctly formatted.
- Add runtime migration for `xy`, `partition`, `tagcloud` and
`datatable` viz. Requires `formBased` `datasourceState` to determine
best string-to-raw value convertion.
Closes#193080Fixes#187519
### 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]
[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
<!-- Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging -->
- [x] Migration from previous stored types.
## Release note
This PR fixes an issue
([#193080](https://github.com/elastic/kibana/issues/193080)) where
custom ranges and multi-field values were not correctly colored based on
selected color mapping configurations.
This change includes a runtime migration to convert old mappings as
strings to their raw value equivalent. This conversion is done at
runtime when the vis is rendered and only updated when the visualization
is saved. Thus this conversion does not dirty the state of the
visualization such as when first opening to edit.
This _should_ have no affect to the user apart from improved value
formatting in the color mapping assignment selection UI. In rare cases,
some assignments may not be correctly converted exactly to the new raw
value but are still preserved to use as string value matches. The only
know case where we are not be able to fully convert the value is when
using labels on custom ranges, the label will not show in the color
mapping assignment UI unless the value is removed as added back.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Marco Liberati <dej611@users.noreply.github.com>
Co-authored-by: Marco Vettorello <marco.vettorello@elastic.co>
- Adds a small helper method for handling errors of type
`LockAcquisitionError`.
- Flips retry logic for `populateMissingSemanticTextFieldWithLock ` so
we retry all errors except `LockAcquisitionError`
## Summary
This PR implements support for Lens chart fetches across Discover tabs,
and restoring chart state when returning to a tab.
The Lens embeddable does not currently support continuing data fetching
after it's been unmounted, or fully support restoring chart state using
previously fetched data. The Vis team is aware of this request, but in
the meantime we're using an alternative approach that keeps Lens charts
rendered in memory for each tab that's been visited at least once. This
allows fetches to run in the background and displays the resulting chart
when switching back to tabs. Doing this involved some refactoring to
both Discover and Unified Histogram:
- Create a `ChartPortalsRenderer` wrapper component in Discover to lift
chart rendering high up in the React tree and render charts into
[reverse portals](https://github.com/httptoolkit/react-reverse-portal),
ensuring charts are not remounted when switching tabs and continue to be
rendered after switching away from a tab.
- Refactor Unified Histogram from a single "container" component into
three pieces: a `UnifiedHistogramLayout` component, a
`UnifiedHistogramChart` component, and a `useUnifiedHistogram` hook to
tie things together. This approach allows us to render the chart and
hook separately (in a reverse portal) from the layout, making it
possible to separate the lifecycle of both components without keeping
the rest of Discover's components in memory after switching tabs.
- **Important note:** This change had the side effect of bloating the
Unified Histogram page load bundle since we're now exporting a static
hook that isn't dynamically imported. We could have worked around this
by getting creative with dynamic imports, but doing that seemed hacky.
Instead I decided now was a good time to split Unified Histogram out
into a package in order to support tree shaking, which also has the
added benefits of one fewer plugins to load on startup, and simplifying
the Discover async bundles.
There is one flaw with this approach: the `useDiscoverHistogram` hook
currently depends on global services for retrieving the current query
and filters (including global filters) through the `useQuerySubscriber`
hook. This means the values can become out of sync in inactive tabs when
the user modifies them in the current tab. In practice this doesn't seem
to have an effect in most cases since we don't trigger new fetches in
inactive tabs, and sync the the current tab values to the global
services when switching back to a tab. However, we should still fix this
for the MVP with an approach that doesn't leak state since the current
approach is brittle. I avoided doing that in this PR since it would
likely cause more conflicts with #217706, and that PR may introduce a
solution to the issue anyway (syncing global state to the redux store,
which we can rely on in the hook instead).
Resolves#216475.
### 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
- [ ] 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>
## Summary
Related to #213024.
This adds the necessary backend schema changes for the investigation
guide.
Note this PR depends on #216292 and should not be merged before it.
---------
Co-authored-by: Panagiota Mitsopoulou <giota85@gmail.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Panagiota Mitsopoulou <panagiota.mitsopoulou@elastic.co>
Co-authored-by: Christos Nasikas <xristosnasikas@gmail.com>
Closes https://github.com/elastic/kibana-operations/issues/267
This PR is a follow up from the webpack v5 upgrade which makes sure we
stop using the old non maintained webpack v4 polyfills library and use
instead a new supported library called `node-stdlib-browser`.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Expose LockManager as package to make it easier to consume from other
plugins
cc @nchaulet
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Viduni Wickramarachchi <viduni.ushanka@gmail.com>
## Summary
This PR creates CRUD endpoints for search playgrounds. This will enable
us to make new pages for saved playgrounds that are shared in a space.
## Notes
Usages of `ALL_SAVED_OBJECT_INDICES` had to be updated to include
`ignore_unavailable` since a new index was added for search solution
saved objects, but these are not always registered when search plugins
are disabled. Because of this refresh and other calls using
`ALL_SAVED_OBJECT_INDICES` were failing when the new
`.kibana_search_solution` index did not exist.
### 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] [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: Gerard Soldevila <gerard.soldevila@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Similar to #217034, #217202 and #217467 this time applied to
`react-use`.
This is a slightly different approach than #217034 as we're caching here
only the most common/frequently used methods from the `react-use`
library and leaving the rest to be loaded within the specific plugin
chunks.
What this PR does it fundamentally:
* adds `7.x kb` to the shared bundle
* overall the startup bundle size shrinks about `3.5 kb`
* the async bundle size shrinks of about `350 kb` (mainly due to 3
imports which were targeting `react-use/lib`).
An alternative approach would be to just fix the async import strings in
there, but I thought to it was worth it to make the long step here.
Feedback appreciated.
