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
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 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
```
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>
- Closes https://github.com/elastic/kibana/issues/216549
- Closes https://github.com/elastic/kibana/issues/216071
## Summary
This PR allows to restore the following state for the previously opened
tabs:
- the selected data view
- classic or ES|QL mode
- query and filters
- time range and refresh interval
- and other properties of the app state
bcba741abc/src/platform/plugins/shared/discover/public/application/main/state_management/discover_app_state_container.ts (L92)
## Changes
- [x] Sync selected tab id to URL => after refresh the initial tab would
be the last selected one
- [x] Restore tabs after refresh
- [x] Restore appState and globalState after reopening closed tabs
- [x] Clear tabs if Discover was opened from another Kibana app
- [x] Store tabs in LocalStorage
- [x] Fix "New" action and clear all tabs
- [x] Populate "Recently closed tabs" with data from LocalStorage
- [x] If selected tab id changes in URL externally => update the state
- [x] Reset the stored state when userId or space Id changes
- [x] Fix all tests
### Testing
- Test that the existing functionality is not affected
- Enable tabs feature in
bcba741abc/src/platform/plugins/shared/discover/public/constants.ts (L15)
and test that tabs are being persisted and can be restored manually too.
### 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: Davis McPhee <davismcphee@hotmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/216096
## Summary
This PR accomplishes two main things:
1. It flattens out how grid elements are rendered, which means that
embeddables no longer re-mount when dragged between sections and
2. It allows panels and sections to be "intermixed" on a **single**
level (i.e. you can only drop a section header between panels if they
are **not** in a section)
Since this was a **major** rewrite of the grid layout logic, I also took
some time to clean up the code - this includes removing
`proposedGridLayout$` (since this added two sources of truth, which was
causing issues with the DOM becoming out-of-sync with the layout object;
however, this also caused
https://github.com/elastic/kibana/issues/220309) and unifying on the use
of "section" rather than "row" (since it was confusing that we were
using "row" for both the grid row number and the section ID).
https://github.com/user-attachments/assets/c5d9aa97-5b14-4f4c-aacf-74055c7d9c33
> [!NOTE]
> Reminder that, since collapsible sections aren't available in
Dashboard yet, you must test this PR in the `grid` example app (by
running Kibana with `yarn start --run-examples`).
### 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)
---------
Co-authored-by: mbondyra <marta.bondyra@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Marta Bondyra <4283304+mbondyra@users.noreply.github.com>
Initially there was no success message for any type in the library and
there was no scrolling to added panel.
This change sets displaySuccessMessage to true for each plugin
registered in the Add from Library flyout.
It ensures that:
- users see a success toast after adding a panel,
- the newly added panel is automatically scrolled into view.
Closes: #188775
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
`useBatchedOptionalPublishingSubjects` should only be used when `api` is
not available until after rendering. This PR replaces usages of
`useBatchedOptionalPublishingSubjects` with
`useBatchedPublishingSubjects` where possible.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@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
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.
DefaultPresentationPanelApi should define parentApi as unknown.
`ReactEmbeddableRenderer` renders panels with `PresentationPanel`.
`PresentationPanel` takes `api: DefaultPresentationPanelApi` as a prop
and `DefaultPresentationPanelApi` should not define ParentApi type more
precisely then its defined in `ReactEmbeddableRenderer`.
`ReactEmbeddableRenderer` defines parent as `ParentApi extends
HasSerializedChildState<SerializedState> =
HasSerializedChildState<SerializedState>`.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/217923
Investigations in https://github.com/elastic/kibana/issues/217368 showed
that there was basically no performance impact to passing the AST across
a thread boundary. But we also didn't detect a pressing reason to remove
the worker.
Since then, however, we noticed another cost associated with the worker:
it's a hefty Javascript file, even in production builds. In addition, we
are doing parsing on the main thread _and_ the worker, so the
`kbn-esql-ast` package is actually being loaded and parsed twice by the
browser, once for the main thread and once for the worker.
This PR removes our worker. Our parsing associated with validation and
autocomplete will still be done asynchronously, but on the main thread.
I do not see any regression in perceived performance.
---------
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
This PR fixes the existing usage of the chart themes by using the
provided `useElasticChartsTheme` hook that is color mode aware and theme
adaptive (borealis/amsterdam)
Some charts where using just the Light theme version or the legacy (aka
amsterdam theme), and I've applied the hook to pick up the correct
theme.
TO REVIEWERS: Please pull down the PR and check if the actual changed
charts looks correct with the new theme configuration.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Anton Dosov <anton.dosov@elastic.co>
## Summary
- This PR introduces source selector (aka "component") parsing `FROM
index::<selector>`
- It also improves source cluster and index parsing `FROM
<cluster>:<index>`
- Previous cluster and index would be parsed as `string` now they are
parsed as `ESQLStringLiteral` instead. This is more correct as any of
those can take three forms, and `ESQLStringLiteral` handles all three
forms:
1. unquoted string: `cluster:index`
2. single-double quoted string: `"cluster":"index"`
3. triple-double quote string: `"""cluster""":"""index""`
- The `ESQLStringLiteral` now also supports *"unquoted strings"* in
addition to single `"str"` and triple `"""str"""` quoted strings.
### 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
In this PR, I'm changing the CODEOWNERS for reporting related modules.
While reviewing, ensure I haven't missed anything or moved a module that
should remain part of sharedux team.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Tim Sullivan <tsullivan@users.noreply.github.com>
Co-authored-by: Timothy Sullivan <tsullivan@elastic.co>
Related to https://github.com/elastic/kibana/pull/216399
PR
* updates `useStateFromPublishingSubject` to require `subject`, thus,
removing complexities of setting up subscription when `subject` is
optionally provided.
* Updates `useStateFromPublishingSubject` to setup subscription with
`useMemo` to avoid timing issues.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Adds keyboard navigation for drag-and-drop interactions
Fixes https://github.com/elastic/kibana/issues/211925
Fixes https://github.com/elastic/kibana/issues/190448
### Supported features
1. Resize panels
https://github.com/user-attachments/assets/ba7add16-a0c6-4f15-9f3b-0f8ef7caf8ac
2. Drag panels within the same section (dragging between sections is
pending)
https://github.com/user-attachments/assets/a1fd80af-63ca-4fa2-bded-3db9968a8366
3. Move rows up/down
https://github.com/user-attachments/assets/8d7e8d7d-b1bf-4abe-9cc2-28eeea9b43f8
### Interaction Flow
1. Start interaction with `Space` or `Enter`
2. Move using arrow keys
3. Finish by confirming (`Enter`/`Space`) or canceling (`Escape`)
(blurring also confirms the changes)
### Scrolling Behavior:
* Default browser scrolling is disabled in interaction mode to avoid
unexpected behavior and edge cases that would overcomplicate this simple
implementation.
* Scrolling occurs when the user reaches the edge of the screen while
resizing or dragging, allowing them to continue the interaction
smoothly.
* When the operation is confirmed, we also scroll to the element to make
sure it's in view.
### Missing (planned for another PR):
* A11y announcements
* Dragging between sections
* This feature is not well unit-tested, but it's very difficult to do it
without mocking the crucial pieces of functionality. I'd vote to leave
it for now and add a few functional tests once we decide a strategy for
it, since drag and drop interactions are anyway quite difficult to
unit-test reliably anyway.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adjusts the approach introduced in #214861 to ensure state
updates work consistently across tabs, even after switching tabs during
async operations. The `currentTabId` prop has been removed from the
central state since it can't be relied on in actions, and instead tab
IDs are injected using a `CurrentTabProvider`. This allows selectors to
work the same as they did before, and tab specific actions have been
updated to use a standard `TabAction` interface that accepts a tab ID
and prevents leaking state changes.
This approach is safer but adds some complexity, so for actions
dispatched from React components, a `useCurrentTabAction` hook has been
added to handle injecting the current tab ID. We also still need to
access tab state within `DiscoverStateContainer` for now, so two utility
methods (`injectCurrentTab` and `getCurrentTab`) have been added to make
this easier. Since `DiscoverStateContainer` is scoped to a single tab,
this should be safe, and ideally temporary until we get rid of it
completely.
Resolves#215398.
### Checklist
- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
`100.0.0` ⏩ `101.0.1`
[Questions? Please see our Kibana upgrade
FAQ.](https://github.com/elastic/eui/blob/main/wiki/eui-team-processes/upgrading-kibana.md#faq-for-kibana-teams)
## Package updates
### `@elastic/eui`
[`v101.0.1`](https://github.com/elastic/eui/releases/v101.0.1)
- Updated `EuiProvider` and `EuiThemeProvider` with a new
`highContrastMode` ([#8444](https://github.com/elastic/eui/pull/8444))
- This prop allows toggling a higher contrast visual style that
primarily affects borders and shadows
- On `EuiProvider`, if the `highContrastMode` prop is not passed, this
setting will inherit from the user's OS/system settings
- If the user is using a forced colors mode (e.g. Windows' high contrast
themes), this system setting will take precedence over any
`highContrastMode` or `colorMode` props passed
- Added `highContrastModeStyles` and `preventForcedColors` styling utils
([#8444](https://github.com/elastic/eui/pull/8444))
- Updated `EuiRangeTooltip` to be easier to see in dark mode
([#8444](https://github.com/elastic/eui/pull/8444))
- Updated some deprecated color token usages that have direct
substitutes ([#8444](https://github.com/elastic/eui/pull/8444))
- `text` -> `textParagraph`
- `title` -> `textHeading`
- `subduedText` -> `textSubdued`
- `disabledText` -> `textDisabled`
- `accentText` -> `textAccent`
- `dangerText` -> `textDanger`
- `warningText` -> `textWarning`
- `useEuiShadow()` now accepts a second `options` argument
([#8234](https://github.com/elastic/eui/pull/8234))
- `useEuiShadowFlat()` now accepts an `options` object instead of only a
color ([#8234](https://github.com/elastic/eui/pull/8234))
- Updated `EuiPopover` and `EuiToolTip` to be easier to see in dark
mode. ([#8174](https://github.com/elastic/eui/pull/8174))
**Bug fixes**
- Fixed a visual bug where a transparent border would create visible
empty space (`LIGHT` mode only) for the components:
([#8427](https://github.com/elastic/eui/pull/8427))
- `EuiPanel`
- `EuiPopover`
- `EuiToolTip`
- `EuiToast`
- `EuiTour`
---
### `@elastic/eui-theme-common`
[`v0.1.0`](https://github.com/elastic/eui/releases/v0.1.0)
- Removed type `EuiShadowCustomColor`
([#8444](https://github.com/elastic/eui/pull/8444))
- Added types: ([#8444](https://github.com/elastic/eui/pull/8444))
- `EuiShadowOptions`
- `EuiThemeHighContrastModeProp`
- `EuiThemeHighContrastMode`
- Updated shadow utils to accepts a second `options` argument and return
borders in high contrast mode:
([#8444](https://github.com/elastic/eui/pull/8444))
- `euiShadow`
- `euiShadowXSmall`
- `euiShadowSmall`
- `euiShadowMedium`
- `euiShadowLarge`
- `euiSlightShadowHover`
- `euiShadowFlat`
---
### `@elastic/eui-theme-borealis`
[`v0.1.0`](https://github.com/elastic/eui/releases/v0.1.0)
- Added new component level tokens:
([#8444](https://github.com/elastic/eui/pull/8444))
- `buttonGroupBackgroundDisabledSelected`
- `overlayMaskBackground`
- `overlayMaskBackgroundHighContrast`
- `skeletonBackgroundSkeletonMiddleHighContrast`
## Additional changes
The latest `@elastic/eui` package introduces high contrast mode support.
This PR sets all usages of `EuiProvider` to use
`highContrastMode={false}` to introduce it in disabled state (this
reflects the current functionality in Kibana). This is because the UI
for the high contrast mode functionality (and style adjustments) need to
first be implemented on Kibana side (by shared-ux).
## QA
Adding high contrast mode in disabled state should result in no visual
changes in Kibana. Please ensure your product view remain unchanged.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR makes `security` a required field for route registration. To
incorporate the new required filed, changes has been made:
1. **Test file updates**. A lot of the updates made in this PR were made
in tests.
2. **Versioned route security configuration**. For the versioned route
`security` config has been lifted up to the top-level definition:
Before
```ts
router.versioned
.get({
path: '/api/path',
options: { ... },
...
}, handler)
.addVersion({
version: 1,
validate: false,
security: {
authz: {
requiredPrivileges: ['privilege'],
},
},
});
```
After
```ts
router.versioned
.get({
path: '/api/path',
options: { ... },
security: {
authz: {
requiredPrivileges: ['privilege'],
},
},
...
}, handler)
.addVersion({
version: 1,
validate: false,
});
```
3. **Type adjustments for route wrappers**. Type changes has been made
in:
-
`x-pack/solutions/observability/plugins/infra/server/lib/adapters/framework/adapter_types.ts`
-
`x-pack/solutions/observability/plugins/metrics_data_access/server/lib/adapters/framework/adapter_types.ts`
-
`x-pack/solutions/observability/plugins/synthetics/server/routes/types.ts`
-
`x-pack/solutions/observability/plugins/uptime/server/legacy_uptime/routes/types.ts`
Security was made an optional field for the wrappers defined in those
files, since the default security is provided in the wrapper itself and
then passed down to the core router.
### 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)
__Closes: https://github.com/elastic/kibana/issues/215331__
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
- Closes https://github.com/elastic/kibana/issues/214554
## Summary
This PR:
- adds TabPreview component, which is visible when you hover over a
particular tab
- adds tests for TabPreview component
About TabPreview component
- EUI doesn't have a component, which would suit for our needs, hence a
custom component activated on hover
- TabPreview should activate (with 500ms of delay) after hovering over a
whole tab
- It should hide when we click action button in the tab or we open
editing name mode
- It shouldn't appear on hover when we have tab context menu open or
we're editing a title
- For now the data inside is mocked (besides of title), so you can see
random queries and statuses each time you hover over the tab
- Preview should not overflow the screen if there are a lot of tabs and
they're "touching" right side of the screen
https://github.com/user-attachments/assets/da0a47dd-b594-4c20-b76c-49e6889f3814
## Testing
Two options are possible:
1. start Storybook with `yarn storybook unified_tabs` and navigate to
`http://localhost:9001`.
2. start Kibana with `yarn start --run-examples`. Then navigate to the
Unified Tabs example plugin
`http://localhost:5601/app/unifiedTabsExamples`.
### 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: Julia Rechkunova <julia.rechkunova@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/190381
## Summary
This PR adds the ability to drag and drop rows by their headers in order
to reorder them:
It can be a bit confusing dragging section headers around when other
sections are expanded - it is easy to lose track of them, especially
when the expanded sections are very large. I experimented with
auto-collapsing all sections on drag, but this felt extremely
disorienting because you instantly lost all of your context - so, to
improve the UI here, I added a "scroll to" effect on drop like so:
https://github.com/user-attachments/assets/0b519783-a4f5-4590-9a1c-580df66a2f66
Reminder that, to test this feature, you need to run Kibana with
examples via `yarn start --run-examples` and navigate to the grid
examples app via `Analytics > Developer examples > Grid Example`.
### 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
Collapsible sections are not available on Dashboard yet and so there is
no user-facing risk to this PR.
## Summary
Resolves#212919
We noticed that setting the header `'Content-Type':
'text/event-stream',` didn't work as the browser's native EventSource
implementation.
```JS
return res.ok({
headers: {
'Content-Type': 'text/event-stream',
'Cache-Control': 'no-cache',
},
body: observableIntoEventSourceStream(events$ as unknown as Observable<ServerSentEvent>, {
signal: abortController.signal,
logger,
}),
});
```
The reason, apparently, is that we need to flush the compressor's buffer
negotiated in the HTTP request.
### How to test it:
Run Kibana with examples `yarn start --no-base-path --run-examples
--http2` and open the SSE example app in Kibana. You should see a clock
updating every second in the UI (the clock is coming from the server).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Embeddable ViewMode is part of legacy embeddable architecture. This PR
removes Embeddable ViewMode and replaces its usage with
presentation-publishing ViewMode. presentation-publishing ViewMode is a
string literal type so an enum is no longer needed.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/212605
Here we are removing the clear button from the ES|QL control as clearing
will result in wrong charts. I also considered the reset but when there
is no changes should be hidden or disabled. This seems to me as a
smaller change and taken under consideration that dashboard already
allows resetting I think it is ok to remove it.
We can always reconsider if any user complains.
Although by removing the clearSelections from the control config removes
the button the `DefaultControlApi ` was marking it as required. So I had
to tweak a bit the types.
## Summary
Removes the mSearch method from Dashboard content management.
The `mSearch` content management method was designed to be a temporary
implementation of search that allowed searching multiple saved object
types ([see more
[internal]](https://docs.google.com/document/d/1ssYmqSEUPrsuCR4iz8DohkEWekoYrm2yL4QR_fVxXLg/edit?tab=t.0#heading=h.6sj4n6bjcgp5)).
However, the mSearch implementation in the Dashboard Storage class lacks
extensibility as it requires a synchronous `toItemResult` function. As
we start migrating reference handling to the server, we will likely need
transforms that return Promises (ex. `savedObjectToItem`), such as
[retrieving tag saved objects from the SavedObjectTagging
client](https://github.com/elastic/kibana/issues/210619).
The Dashboard `mSearch` method was only used by the dashboard_picker and
this PR replaces its usage with the `search` method.
### Identify risks
There is a slight risk in serverless environments where a browser may
have already loaded the dashboard_picker module but lags behind the
server. In this case, the dashboard picker may fail to retrieve a list
of dashboards due to it calling the now non-existent `mSearch` method
provided by the server. In this case, the user simply needs to refresh
their browser to retrieve the latest UI modules.
Update search control example with buttons to programmatically interact
with controls
<img width="800" alt="Screenshot 2025-02-27 at 8 41 05 AM"
src="https://github.com/user-attachments/assets/e936cdeb-ce51-4fca-a8bc-ec5d983e3155"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Updating the ES client to 9.0.
Resolves#116102
## What changes?
**Breaking change**: `body` has been removed.
Most of the changes are about bringing all the content inside the body
as a root attribute to the API params:
```diff
const response = await client.search({
index: 'test',
- body: {
query: {
match_all: {}
}
- }
})
```
For this reason, enabling the "Hide whitespace changes" option when
reviewing is recommended.
Some exceptions to this rule:
* Bulk APIs replace the `body` array with `operations` array (direct
replacement)
* Index Put Settings API replace `body` array with `settings` (direct
replacement)
* Msearch replaces the `body` array with `searches` array (direct
replacement)
* Document Index API replaces `body` with `document` (direct
replacement)
* Create Repository replaces `body` with `repository` (direct
replacement)
Because of a known issue in the client
(https://github.com/elastic/elasticsearch-js/issues/2584), there's still
an escape hatch to send data in the body in case the specific use case
requires it via `// @ts-expect-error elasticsearch@9.0.0
https://github.com/elastic/elasticsearch-js/issues/2584`, but it
shouldn't be abused because we lose types. In this PR we've used it in
those scenarios where we reuse the response of a GET as the body of a
PUT/POST.
### Other changes
* `estypes` can be imported from the root of the library as `import type
{ estypes } from '@elastic/elasticsearch';`
* `estypesWithBody` have been removed
* `requestTimeout`'s 30s default has been removed in the client. This PR
explicitly adds the setting in all client usages.
### Identify risks
- [x] The client places unknown properties as querystring, risking body
params leaking there, and causing 400 errors from ES => Solved by
forcing `body` usage there via `// @ts-expect-error elasticsearch@9.0.0
https://github.com/elastic/elasticsearch-js/issues/2584`. The next
version of the client will address this.
- [x] We need to run the MKI tests to make sure that we're not breaking
anything there =>
https://elastic.slack.com/archives/C04HT4P1YS3/p1739528112482629?thread_ts=1739480136.231439&cid=C04HT4P1YS3
---------
Co-authored-by: Gloria Hornero <gloria.hornero@elastic.co>
### Summary
- Closes#89741
This PR contains the resulting work of a massive effort that ports our
on top bundler abstraction (called @kbn/optimizer) from Webpack v4 into
Webpack v5. It's essential in terms of long term maintenance since v4
was not receiving updates any longer but will also unblock some new
features that could be beneficial for our future DevEx endeavours.
Next you can find a small list of all the accomplished tasks on this
journey.
### Completed Tasks
- [x] Upgrade dependencies to match the ones on webpack v5
- [x] Fix null-loader usages
- [x] Fix raw-loader usages
- [x] Fix file-loader usages
- [x] Fix url-loader usages
- [x] Fix `@kbn/optimizer-webpack-helpers` to support webpack v5
- [x] Adopt previous webpack v4 polyfill-all strategy with
node-polyfill-webpack-plugin
- [x] Fix theme-loader on @kbn/optimizer
- [x] Migrate configurations and ad-hoc loader options on all webpack
configs from v4 to v5
- [x] Fix @kbn/test jest resolver for file-loader cases
- [x] Migrate public-path loader on UiSharedDeps
- [x] Fix all usages of webpack-merge
- [x] Migrate BundleRemoteModule
- [x] Migrate BundleRemotesPlugin
- [x] Correctly migrate PopulateBundleCachePlugin
- [x] Correctly migrate BundleMetricsPlugin
- [x] Check if the profiling plugins still work (--profile flag)
- [x] Recover if possible the previous webpack v4 cacheGroup chunks
rename to something like `data.plugin.chunk.0.js`
- [x] Run `/ci` and make sure we get our first green CI, otherwise work
on the errors until we do
- [x] Profile and solve bottlenecks until we get a cold build
performance similar to the one we had on webpack v4 (`node
scripts/build_kibana_platform_plugins --no-cache`).
- [x] OpenSSL Legacy Warnings: try to remove `--openssl-legacy-provider
` flags
- [x] Add Webpack to Renovate config
- [x] Explore removing `NodePolyfillPlugin`
([here](https://www.npmjs.com/package/node-polyfill-webpack-plugin)) and
add each polyfill needed individually per each webpack config to check
if we get smaller bundles. If we do it's better to go with the case by
case need approach instead of deploying a bunch of polyfills with
NodePolyfillPlugin. As another alternative, create a custom smaller
plugin with only the union of all needed polyfills.
- [x] Evaluate if we want to touch the resolutions on mainFields and
conditionNames
- [x] Understand why `@import 'src/core/public/mixins'` does not work
anymore (not a problem, we should use relative paths anyway but we want
to track why it changed from v4 to v5)
- [x] BUG: Child compilers are having errors hidden and/or changed from
error to warning
- [x] Fix license check for
[Artistic-2.0](https://spdx.org/licenses/Artistic-2.0.html) is the
license for
[domain-browser](https://github.com/bevry/domain-browser?tab=License-1-ov-file).
This package is a dependency of
[NodePolyfillPlugin](https://www.npmjs.com/package/node-polyfill-webpack-plugin).
Artistic 2.0 license is [classified as
yellow](https://github.com/elastic/open-source/blob/main/elastic-product-policy.md#yellow-list)
and should only be used for dev dependencies.
- [x] Make sure `resourceQuery: { not: /raw/ }` is not necessary on
other webpack configs like storybook one
- [x] Find what is being wrongly removed by usedExports optimization;
hint: I believe it is identifying a lot of exports inside the sync entry
of plugins as unused exports and removing them. Then `__kbnBootstrap__`
can't be found
- [x] Rebalance @kbn/optimizer pickMaxWorkerCount
- [x] Re-open the issue to fix sass-warnings
[#190345](https://github.com/elastic/kibana/issues/190345) or downgrade
sass-loader to v10
- [x] Remove previous esm no parse rules
- [x] Confirm esm support is working
- [x] Confirm console override is needed
- [x] Confirm react prod builds on ui shared deps for distributable
- [x] Remove customization for
[xyflow](https://github.com/xyflow/xyflow) from webpack configs
- [x] Clean all the code
- [x] Make sure collected metrics from stats are still aligned with what
we were collecting before; also verify if the modules used for optimizer
caches etc are well generated (@kbn/node-libs-browser)
- [x] Fix watch performance
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Brad White <brad.white@elastic.co>
This PR **might** resolve
https://github.com/elastic/kibana/issues/207011 but we will need time
for the telemetry metrics to settle before we know for sure.
## Summary
This PR removes the conditional rendering of the default drag handle in
`kbn-grid-layout`, which has two benefits:
1. It removes the double render of `GridPanel` that was caused by
relying on the `dragHandleCount` to be updated in order to determine
whether the default drag handle should be rendered
2. The default drag handle no longer "flashes" when Dashboards are
loading and waiting for `dragHandleCount` to update
- **Before:**
https://github.com/user-attachments/assets/30a032fc-4df3-42ce-9494-dd7f69637c03
- **After:**
https://github.com/user-attachments/assets/db447911-cbe2-40dd-9a07-405d1e35a75d
Instead, the consumer of `kbn-grid-layout` is responsible for setting
the `useCustomDragHandle` prop to `true` when they want to use a drag
handle other than the default one.
When adding the `useCustomDragHandle` prop, I got annoyed that I had to
pass this prop all the way down to `grid_panel` - so I decided to swap
to using React context in this PR, as well. The API for the grid layout
component will most likely continue to grow, so this should make it
easier to manage the props.
### 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)
## Summary
This PR migrates the last routes with `access:<privilege>` tags used in
route definitions to new security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before Migration:**
Access control tags were defined in the `options` object of the route:
```ts
router.get({
path: '/api/path',
options: {
tags: ['access:<privilege_1>', 'access:<privilege_2>'],
},
...
}, handler);
```
### **After Migration:**
Tags have been replaced with the more robust
`security.authz.requiredPrivileges` field under `security`:
```ts
router.get({
path: '/api/path',
security: {
authz: {
requiredPrivileges: ['<privilege_1>', '<privilege_2>'],
},
},
...
}, handler);
```
### 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
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/180057
The following items needed to be replaced with add panel actions
* vega - visType
* markdown - visType
* lens - visTypeAlias
* maps - visTypeAlias
As an added benefit, now these actions are displayed in embeddable
examples that uses ADD_PANEL_TRIGGER
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR reworks saved query privileges to rely solely on a single global
`savedQueryManagement` privilege, and eliminates app-specific overrides.
This change simplifies the security model for users, fixes bugginess in
the saved query management UI, and reduces code complexity associated
with maintaining two separate security mechanisms (app-specific
overrides and global saved query management privileges).
### Background
Saved queries allow users to store a combination of KQL or Lucene
queries, filters, and time filters to use across various applications in
Kibana. Access to saved query saved objects are currently granted by the
following feature privileges:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_savedQueryManagement.all",
"feature_maps.all",
"feature_savedObjectsManagement.all",
"feature_visualize.all"
]
```
There is also a saved query management UI within the Unified Search bar
shared by applications across Kibana:
<img
src="https://github.com/user-attachments/assets/e4a7539b-3dd4-4d47-9ff8-205281ef50e3"
width="500" />
The way access to this UI is managed in Kibana is currently confusing
and buggy:
- If a user has `feature_discover.all` and `feature_dashboard.all` they
will be able to load and save queries in Discover and Dashboard.
- If a user has `feature_discover.all` and `feature_dashboard.read` they
will be able to load queries in both Discover and Dashboard, but only
save queries in Discover (even though they have write access to the SO,
and API access). Instead they have to navigate to Discover to save a
query before navigating back to Dashboard to load it, making for a
confusing and frustrating UX.
- Access to the UI is even more confusing in apps not listed in the
above feature privileges (e.g. alerting, SLOs). Some of them chose to
check one of the above feature privileges, meaning users who otherwise
should have saved query access won't see the management UI if they don't
also have the exact feature privilege being checked. Other apps just
always show the management UI, leading to bugs and failures when users
without one of the above feature privileges attempt to save queries.
### Existing improvements
In v8.11.0, we introduced a new ["Saved Query
Management"](https://github.com/elastic/kibana/pull/166937) privilege,
allowing users to access saved queries across all of Kibana with a
single global privilege:
<img
src="https://github.com/user-attachments/assets/ccbe79a4-bd0b-4ed6-89c9-117cc1f99ee2"
width="600" />
When this privilege is added to a role, it solves the
`feature_discover.all` and `feature_dashboard.read` issue mentioned
above. However, it does not fix any of the mentioned issues for roles
without the new privilege. We have so far postponed further improvements
to avoid a breaking change.
### Approach
To fully resolve these issues and migrate to a single global privilege,
these changes have been made:
- Remove saved query SO access from all application feature privileges
and instead only allow access through the global saved query management
privilege.
- Stop relying on application feature privileges for toggling the saved
query management UI, and instead rely on the global privilege.
To implement this with minimal breaking changes, we've used the Kibana
privilege migration framework. This allows us to seamlessly migrate
existing roles containing feature privileges that currently provide
access to saved queries, ensuring they are assigned the global saved
query management privilege on upgrade.
As a result, we had to deprecate the following feature privileges,
replacing them with V2 privileges without saved query SO access:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_maps.all",
"feature_visualize.all"
]
```
Each area of code that currently relies on any of these feature
privileges had to be updated to instead access `feature_X_V2` instead
(as well as future code).
This PR still introduces a minor breaking change, since users who have
`feature_discover.all` and `feature_dashboard.read` are now able to save
queries in Dashboard after upgrade, but we believe this is a better UX
(and likely the expected one) and worth a small breaking change.
### Testing
- All existing privileges should continue to work as they do now,
including deprecated V1 feature privileges and customized serverless
privileges. There should be no changes for existing user roles apart
from the minor breaking change outlined above.
- Check that code changes in your area don't introduce breaking changes
to existing behaviour. Many of the changes are just updating client UI
capabilities code from `feature.privilege` to `feature_v2.privilege`,
which is backward compatible.
- The `savedQueryManagement` feature should now globally control access
to saved query management in Unified Search for all new user roles.
Regardless of privileges for Discover, Dashboard, Maps, or Visualize,
new user roles should follow this behaviour:
- If `savedQueryManagement` is `none`, the user cannot see or access the
saved query management UI or APIs.
- If `savedQueryManagement` is `read`, the user can load queries from
the UI and access read APIs, but cannot save queries from the UI or make
changes to queries through APIs.
- If `savedQueryManagement` is `all`, the user can both load and save
queries from the UI and through APIs.
### 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/packages/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
- [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
This PR risks introducing unintended breaking changes to user privileges
related to saved queries if the deprecated features have not been
properly migrated, and users could gain or lose access to saved query
management on upgrade. This would be bad if it happened, but not overly
severe since it wouldn't grant them access to any ES data they couldn't
previously access (only query saved objects). We have automated testing
in place to help ensure features have been migrated correctly, but the
scope of these changes are broad and touch many places in the codebase.
Additionally, the UI capabilities types are not very strict, and are
referenced with string paths in many places, which makes changing them
riskier than changing strictly typed code. A combination of regex
searches and temporarily modifying the `Capabilities` type to cause type
errors for deprecated privileges was used to identify references in
code. Reviewers should consider if there are any other ways that UI
capabilities can be referenced which were not addressed in this PR.
Our automated tests already help mitigate the risk, but it's important
that code owners thoroughly review the changes in their area and
consider if they could have unintended consequences. The Platform
Security team should also review this PR thoroughly, especially since
some changes were made to platform code around privilege handling. The
Data Discovery team will also manually test the behaviour when upgrading
existing user roles with deprecated feature privileges as part of 9.0
upgrade testing.
---------
Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
Co-authored-by: Matthias Wilhelm <ankertal@gmail.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
## Summary
Part of https://github.com/elastic/kibana-team/issues/1417
This PR converts a batch of SCSS to Emotion in the SharedUX domain.
* `KibanaSolutionAvatar`
* `FilePicker`
* `SolutionNav`
* `SolutionNavCollapseButton`
* `KbnTopNav`
All of the changes, except for `KbnTopNav`, can be tested in Storybook
by running `yarn storybook shared_ux`
### 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)
### 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.
- [x] The risk of inexact conversion: verifying this PR requires manual
checks to ensure that the conversion has not created any regressions in
the style.
