## Summary
**Reviewers: Please test the code paths affected by this PR. See the
"Risks" section below.**
Part of work for enabling "high contrast mode" in Kibana. See
https://github.com/elastic/kibana/issues/176219.
**Background:**
Kibana will soon have a user profile setting to allow users to enable
"high contrast mode." This setting will activate a flag with
`<EuiProvider>` that causes EUI components to render with higher
contrast visual elements. Consumer plugins and packages need to be
updated selected places where `<EuiProvider>` is wrapped, to pass the
`UserProfileService` service dependency from the CoreStart contract.
**NOTE:** **EUI currently does not yet support the high-contrast mode
flag**, but support for that is expected to come in around 2 weeks.
These first PRs are simply preparing the code by wiring up the
`UserProvideService`.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [X] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [X] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### 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.
- [ ] [medium/high] The implementor of this change did not manually test
the affected code paths and relied on type-checking and functional tests
to drive the changes. Code owners for this PR need to manually test the
affected code paths.
- [ ] [medium] The `UserProfileService` dependency comes from the
CoreStart contract. If acquiring the service causes synchronous code to
become asynchronous, check for race conditions or errors in rendering
React components. Code owners for this PR need to manually test the
affected code paths.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/190379
## Summary
This PR switches the example grid layout app to render embeddables as
panels rather than the simplified mock panel we were using previously.
In doing so, I had to add the ability for custom panels to add a custom
drag handle via the `renderPanelContents` callback - this required
adding a `setDragHandles` callback to the `ReactEmbeddableRenderer` that
could be passed down to the `PresentationPanel` component.
https://github.com/user-attachments/assets/9e2c68f9-34af-4360-a978-9113701a5ea2
#### New scroll behaviour
In https://github.com/elastic/kibana/pull/201867, I introduced a small
"ease" to the auto-scroll effect that happens when you drag a panel to
the top or bottom of the window. However, in that PR, I was using the
`smooth` scrolling behaviour, which unfortunately became **very**
jittery once I switched to embeddables rather than simple panels
(specifically in Chrome - it worked fine in Firefox).
The only way to prevent this jittery scroll was to switch to the default
scroll behaviour, but this lead to a very **abrupt** stop when the
scrollbar reached the top and/or bottom of the page - so, to give the
same "gentle" stop that the `smooth` scroll had, I decided to recreate
this effect by adding a slow down "ease" when close to the top or bottom
of the page:
https://github.com/user-attachments/assets/cb7bf03f-4a9e-4446-be4f-8f54c0bc88ac
This effect is accomplished via the parabola formula `y = a(x-h)2 + k`
and can be roughly visualized with the following, which shows that the
"speed up" ease happens at a much slower pace than the "slow down" ease:
#### Notes about parent changes
As I investigated improving the efficiency of the grid layout with
embeddables, one of the main things I noticed was that the grid panel
was **always** remounted when moving a panel from one collapsible
section to another. This lead me (and @ThomThomson) down a rabbit hole
of React-reparenting, and we explored a few different options to see if
we could change the parent of a component **without** having it remount.
In summary, after various experiments and a whole bunch of research, we
determined that, due to the reconciliation of the React tree, this is
unfortunately impossible. So our priorities will instead have to move to
making the remount of `ReactEmbeddableRenderer` **as efficient as
possible** via caching, since the remount is inevitable.
### 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)
### Identify risks
There are no risks to this PR, since the most significant work is
contained in the `examples` plugin. Some changes were made to the
presentation panel to allow for custom drag handles, but this isn't
actually used in Dashboard - so for now, this code is only called in the
example plugin, as well.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/201627
This is a short term fix for serverless and 8.x branches (long term fix
is an architectural change that will only be merged into 9.0 and 8.18
branches).
Fix prevents users from reseting a panel edited via embeddable transfer
service. This prevents panel from getting into an invalid state.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR aims at relocating some of the Kibana modules (plugins and
packages) into a new folder structure, according to the _Sustainable
Kibana Architecture_ initiative.
> [!IMPORTANT]
> * We kindly ask you to:
> * Manually fix the errors in the error section below (if there are
any).
> * Search for the `packages[\/\\]` and `plugins[\/\\]` patterns in the
source code (Babel and Eslint config files), and update them
appropriately.
> * Manually review
`.buildkite/scripts/pipelines/pull_request/pipeline.ts` to ensure that
any CI pipeline customizations continue to be correctly applied after
the changed path names
> * Review all of the updated files, specially the `.ts` and `.js` files
listed in the sections below, as some of them contain relative paths
that have been updated.
> * Think of potential impact of the move, including tooling and
configuration files that can be pointing to the relocated modules. E.g.:
> * customised eslint rules
> * docs pointing to source code
> [!NOTE]
> This PR has been auto-generated.
> Do not attempt to push any changes unless you know what you are doing.
> Please use
[#sustainable_kibana_architecture](https://elastic.slack.com/archives/C07TCKTA22E)
Slack channel for feedback.
#### 2 plugin(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/esql` | `src/platform/plugins/shared/esql` |
| `@kbn/esql-datagrid` | `src/platform/plugins/shared/esql_datagrid` |
#### 5 package(s) are going to be relocated:
| Id | Target folder |
| -- | ------------- |
| `@kbn/esql-ast` | `src/platform/packages/shared/kbn-esql-ast` |
| `@kbn/esql-editor` | `src/platform/packages/private/kbn-esql-editor` |
| `@kbn/esql-utils` | `src/platform/packages/shared/kbn-esql-utils` |
| `@kbn/esql-validation-autocomplete` |
`src/platform/packages/shared/kbn-esql-validation-autocomplete` |
| `@kbn/language-documentation` |
`src/platform/packages/private/kbn-language-documentation` |
<details>
<summary>Updated references</summary>
```
./.buildkite/scripts/steps/esql_generate_function_metadata.sh
./.buildkite/scripts/steps/esql_grammar_sync.sh
./.eslintignore
./.eslintrc.js
./.i18nrc.json
./docs/developer/plugin-list.asciidoc
./examples/esql_ast_inspector/public/plugin.ts
./examples/esql_validation_example/public/plugin.ts
./package.json
./packages/kbn-esql-validation-autocomplete/src/validation/validation.test.ts
./packages/kbn-monaco/BUILD.bazel
./packages/kbn-repo-packages/package-map.json
./packages/kbn-ts-projects/config-paths.json
./packages/kbn-ui-shared-deps-src/BUILD.bazel
./src/dev/storybook/aliases.ts
./src/platform/packages/private/kbn-esql-editor/jest.config.js
./src/platform/packages/private/kbn-language-documentation/jest.config.js
./src/platform/packages/private/kbn-language-documentation/package.json
./src/platform/packages/shared/kbn-esql-ast/jest.config.js
./src/platform/packages/shared/kbn-esql-utils/jest.config.js
./src/platform/packages/shared/kbn-esql-validation-autocomplete/README.md
./src/platform/packages/shared/kbn-esql-validation-autocomplete/jest.config.js
./src/platform/packages/shared/kbn-esql-validation-autocomplete/jest.integration.config.js
./src/platform/packages/shared/kbn-esql-validation-autocomplete/package.json
./src/platform/packages/shared/kbn-esql-validation-autocomplete/src/autocomplete/helper.ts
./src/platform/plugins/shared/esql/jest.config.js
./src/platform/plugins/shared/esql_datagrid/jest.config.js
./tsconfig.base.json
./yarn.lock
```
</details>
<details>
<summary>Updated relative paths</summary>
```
src/platform/packages/private/kbn-esql-editor/jest.config.js:12
src/platform/packages/private/kbn-esql-editor/tsconfig.json:2
src/platform/packages/private/kbn-language-documentation/jest.config.js:12
src/platform/packages/private/kbn-language-documentation/package.json:12
src/platform/packages/private/kbn-language-documentation/tsconfig.json:2
src/platform/packages/shared/kbn-esql-ast/jest.config.js:12
src/platform/packages/shared/kbn-esql-ast/tsconfig.json:2
src/platform/packages/shared/kbn-esql-utils/jest.config.js:12
src/platform/packages/shared/kbn-esql-utils/tsconfig.json:2
src/platform/packages/shared/kbn-esql-validation-autocomplete/jest.config.js:12
src/platform/packages/shared/kbn-esql-validation-autocomplete/jest.integration.config.js:12
src/platform/packages/shared/kbn-esql-validation-autocomplete/package.json:10
src/platform/packages/shared/kbn-esql-validation-autocomplete/package.json:11
src/platform/packages/shared/kbn-esql-validation-autocomplete/scripts/generate_function_definitions.ts:389
src/platform/packages/shared/kbn-esql-validation-autocomplete/tsconfig.json:2
src/platform/plugins/shared/esql/jest.config.js:12
src/platform/plugins/shared/esql/tsconfig.json:2
src/platform/plugins/shared/esql/tsconfig.json:7
src/platform/plugins/shared/esql_datagrid/jest.config.js:12
src/platform/plugins/shared/esql_datagrid/tsconfig.json:2
src/platform/plugins/shared/esql_datagrid/tsconfig.json:7
```
</details>
<details>
<summary>Script errors</summary>
```
```
</details>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Rudolf Meijering <skaapgif@gmail.com>
Part of https://github.com/elastic/kibana/issues/180059
PR removes legacy embeddable factory support from Canvas and Dashboard
`Add from library` flyout
PR also does the following clean-ups
1) Renames folder, files, and component from `add_panel_flyout` to
`add_from_library_flyout`. When component was originally created,
dashboard `Add panel` button did not exist, and `Add from library`
button was called `Add panel`. Now that dashboard contains `Add panel`
and `Add from library` buttons, the old naming convention is super
confusing and not longer lines up with the current UI.
2) moves registry to `add_from_library` folder so that the registry is
in closer proximity to its usage.
2) Renames `registerReactEmbeddableSavedObject` to
`registerAddFromLibraryType` because
`registerReactEmbeddableSavedObject` does not clearly specifying what
the registry enables.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
**Reviewers: Please test the code paths affected by this PR. See the
"Risks" section below.**
Part of work for enabling "high contrast mode" in Kibana. See
https://github.com/elastic/kibana/issues/176219.
**Background:**
Kibana will soon have a user profile setting to allow users to enable
"high contrast mode." This setting will activate a flag with
`<EuiProvider>` that causes EUI components to render with higher
contrast visual elements. Consumer plugins and packages need to be
updated selected places where `<EuiProvider>` is wrapped, to pass the
`UserProfileService` service dependency from the CoreStart contract.
**NOTE:** **EUI currently does not yet support the high-contrast mode
flag**, but support for that is expected to come in around 2 weeks.
These first PRs are simply preparing the code by wiring up the
`UserProvideService`.
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [X] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [X] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### 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.
- [ ] [medium/high] The implementor of this change did not manually test
the affected code paths and relied on type-checking and functional tests
to drive the changes. Code owners for this PR need to manually test the
affected code paths.
- [ ] [medium] The `UserProfileService` dependency comes from the
CoreStart contract. If acquiring the service causes synchronous code to
become asynchronous, check for race conditions or errors in rendering
React components. Code owners for this PR need to manually test the
affected code paths.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fixes https://github.com/elastic/kibana/issues/197714
### Key Features
#### Responsiveness
1. Adds a responsive view controlled by the `accessMode` prop.
2. For the responsive version (in the `VIEW` mode), panels retain height
and are arranged based on screen order (left-to-right, top-to-bottom).
3. Interactivity (drag/resize) is disabled in `view` mode.
<img width="514" alt="Screenshot 2024-11-25 at 17 34 56"
src="https://github.com/user-attachments/assets/6a5a97aa-de9b-495a-b1de-301bc935a5ab">
#### Maximization
1. Supports expanded panel view using the `expandedPanelId` prop.
2. Interactivity (drag/resize) is disabled when a panel is expanded.
<img width="1254" alt="Screenshot 2024-11-25 at 17 35 05"
src="https://github.com/user-attachments/assets/c83014f6-18ad-435b-a59d-1d3ba3f80d84">
#### Considerations
1. CSS elements naming convention: Main component uses `kbnGrid` class,
with modifiers like `kbnGrid--nonInteractive`. For the drag handle of
`GridPanel` I used `kbnGridPanel__dragHandle` classname.
2. Classes vs. Inline Styles: I opted for using
`kbnGrid--nonInteractive` instead of adding one more subscription to
`GridPanel` to modify the styles inline. It's the first time in this
package that I used classes instead of inline styles for no-initial
styles setting.
3. Naming Convention: I opted for using the `expanded` word to describe
an expanded panel. Another one could be `maximized` as it's more used in
UI, but less in the legacy code.
4. Interactivity (drag/resize) is disabled in responsive mode but we
could consider to limit this to small viewports only (<768px).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR is part of the Kibana Sustainable Architecture effort.
The goal is to start categorising Kibana packages into _generic
platform_ (`group: "platform"`) vs _solution-specific_.
```
group?: 'search' | 'security' | 'observability' | 'platform'
visibility?: 'private' | 'shared'
```
Uncategorised modules are considered to be `group: 'common', visibility:
'shared'` by default.
We want to prevent code from solution A to depend on code from solution
B.
Thus, the rules are pretty simple:
* Modules can only depend on:
* Modules in the same group
* OR modules with 'shared' visibility
* Modules in `'observability', 'security', 'search'` groups are
mandatorily `visibility: "private"`.
Long term, the goal is to re-organise packages into dedicated folders,
e.g.:
```
x-pack/platform/plugins/private
x-pack/observability/packages
```
For this first wave, we have categorised packages that seem
"straightforward":
* Any packages that have:
* at least one dependant module
* all dependants belong to the same group
* Categorise all Core packages:
* `@kbn/core-...-internal` => _platform/private_
* everything else => _platform/shared_
* Categorise as _platform/shared_ those packages that:
* Have at least one dependant in the _platform_ group.
* Don't have any `devOnly: true` dependants.
### What we ask from you, as CODEOWNERS of the _package manifests_, is
that you confirm that the categorisation is correct:
* `group: "platform", visibility: "private"` if it's a package that
should only be used from platform code, not from any solution code. It
will be loaded systematically in all serverless flavors, but solution
plugins and packages won't be able to `import` from it.
* `group: "platform", visibility: "shared"` if it's a package that can
be consumed by both platform and solutions code. It will be loaded
systematically in all serverless flavors, and anybody can import / use
code from it.
* `group: "observability" | "security" | "search", visibility:
"private"` if it's a package that is intented to be used exclusively
from a given solution. It won't be accessible nor loaded from other
solutions nor platform code.
Please refer to
[#kibana-sustainable-architecture](https://elastic.slack.com/archives/C07TCKTA22E)
for any related questions.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/200090
## Summary
This PR migrates the `GridLayout` component a more traditional React
design using **props** rather than providing an API. This change serves
two purposes:
1. It makes the eventual Dashboard migration easier, since it is more
similar to `react-grid-layout`'s implementation
3. It makes the `GridLayout` component less opinionated by moving the
logic for panel management (i.e. panel placement, etc) to the parent
component.
I tried to keep efficiency in mind for this comparison, and ensured that
we are still keeping the number of rerenders **o a minimum**. This PR
should not introduce **any** extra renders in comparison to the API
version.
### 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)
### Identify risks
There are no risks to this PR, since all work is contained in the
`examples` plugin.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
> In https://github.com/elastic/kibana/issues/117241 we're surfacing
usage of APIs marked as `deprecated: true` in the Upgrade Assistant to
help users prepare for a major upgrade. While internal APIs aren't
really deprecated in the same sense we are making a breaking change by
blocking external integrations with these APIs. Since this could be
equally disruptive to users depending on these APIs it would help our
users to surface such usage in the UA too.
The `api` deprecations now have two sub types:
1. routes deprecations `options.deprecated: { … }`
2. access deprecations `options.access: 'internal'`
This PR adds the second `api` deprecation subtype. The reason i kept one
`api` deprecation type and i didnt create a new type is that they have
exactly the same registration process but are triggered by different
attributes. The `api` deprecation is fully managed by the core team
internal services and are configured by the user through the route
interface so it makes sense to keep them as one type. I also can see us
adding more subtypes to this and just piggybacking on the current flow
instead of duplicating it everytime.
**Checklist**
- [x] Create deprecation subtype
- [x] Example plugin
- [x] Surface the deprecation in UA
- [x] Api access deprecation copy (@florent-leborgne )
- [x] Update README and code annotations
- [x] Unit tests
- [x] Integration tests
Closes https://github.com/elastic/kibana/issues/194675
### Design decisions:
If the API has both route deprecation (`options.deprecated: { … }` ) AND
is an internal api `options.access: 'internal'`
The current behavior i went for in my PR:
I show this API once in the UA under the internal access deprecation.
While showing the route deprecation details if defined. This seems to
make the most sense since users should stop using this API altogether.
### Copy decisions:
@florent-leborgne wrote the copy for this deprecation subtype.
<img width="1319" alt="image"
src="https://github.com/user-attachments/assets/9a32f6d1-686a-4405-aec6-786ac5e10130">
<img width="713" alt="image"
src="https://github.com/user-attachments/assets/1304c98d-4c64-468e-a7d6-19c1193bf678">
## Testing
Run kibana locally with the test example plugin that has deprecated
routes
```
yarn start --plugin-path=examples/routing_example --plugin-path=examples/developer_examples
```
The following comprehensive deprecated routes examples are registered
inside the folder:
`examples/routing_example/server/routes/deprecated_routes`
Run them in the dev console to trigger the deprecation condition so they
show up in the UA:
```
GET kbn:/api/routing_example/d/internal_deprecated_route?elasticInternalOrigin=false
GET kbn:/internal/routing_example/d/internal_only_route?elasticInternalOrigin=false
GET kbn:/internal/routing_example/d/internal_versioned_route?apiVersion=1&elasticInternalOrigin=false
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
- [x] Add `deprecate` Type to the API Deprecations reasons.
- [x] Add a `message` optional field that is surfaced in the UA
- [x] Add IDE documentation in the autocomplete for all deprecation
fields.
- [x] Updated README and example plugin for the `deprecate` type
- [x] Update copy for `deprecate`.
Closes https://github.com/elastic/kibana/issues/197721
## Testing
Run kibana locally with the test example plugin that has deprecated
routes
```
yarn start --plugin-path=examples/routing_example --plugin-path=examples/developer_examples
```
The following comprehensive deprecated routes examples are registered
inside the folder:
`examples/routing_example/server/routes/deprecated_routes`
Run them in the dev console to trigger the deprecation condition so they
show up in the UA:
```
GET kbn:/api/routing_example/d/deprecated_route
```
<img width="628" alt="image"
src="https://github.com/user-attachments/assets/3c0e1829-9a07-49bd-94a3-398514f448e2">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: florent-leborgne <florent.leborgne@elastic.co>
## Summary
This PR fixes a missing `EuiProvider` within the guided onboarding
example. Currently the app is barely usable as it throws hundreds or
even thousands of errors which make the page extremely slow.
#### Before fix
https://github.com/user-attachments/assets/87b8252a-82ac-4094-8adf-3cd4c12236ef
#### After fix
https://github.com/user-attachments/assets/0382192b-94b7-4d4b-bada-2d438a750b14
### Notes
**_This PR does NOT fix all the console errors, that's why you see a
couple of errors in the console still on the second video above. It just
fixes the bare minimum to make the app at least usable._**
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/190445
## Summary
This PR adds the first steps of a panel management API to the
`GridLayout` component:
- A method to delete a panel
- A method to replace a panel
- A method to add a panel with a given size and placement technique
(`'placeAtTop' | 'findTopLeftMostOpenSpace'`)
- Currently, we only support adding a panel to the first row, since this
is all that is necessary for parity with the current Dashboard layout
engine - we can revisit this decision as part of the [row
API](https://github.com/elastic/kibana/issues/195807).
- A method to get panel count
- This might not be necessary for the dashboard (we'll see), but I
needed it for the example plugin to be able to generate suggested panel
IDs. It's possible this will get removed 🤷
- The ability to serialize the grid layout state
I only included the bare minimum here that I know will be necessary for
a dashboard integration, but it's possible I missed some things and so
this API will most likely expand in the future.
https://github.com/user-attachments/assets/28df844c-5c12-40fd-b4f4-8fbd1a8abc20
### Serialization
With respect to serialization, there are still some open questions about
how we want to handle it from the Dashboard side - therefore, in this
PR, I opted to keep the serialization as simple as possible (i.e. both
the input and serialized output take identical forms for the
`GridLayout` component).
Our goal is to keep `kbn-grid-layout` as **generic** as possible so,
while I considered making the serialize method return the form that the
Dashboard expects, I ultimately decided against that; instead, I think
Dashboard should be responsible for taking the grid layout's serialized
form and turning it into a dashboard-specific serialization of a grid
layout and vice-versa for deserializing and sending the initial layout
to the `GridLayout` component.
The dashboard grid layout serialization will be tackled as part of
https://github.com/elastic/kibana/issues/190446, where it's possible my
opinion might change :) This is just a first draft of the
`kbn-grid-layout` API, after all.
### Example Grid Layout
In the grid layout example plugin, I integrated the API by adding some
pretty bare-bones buttons to each panel in order to ensure the API works
as expected - that being said, I didn't worry too much about the design
of these things and so it looks pretty ugly 😆 My next step is
https://github.com/elastic/kibana/issues/190379, where I will have to
integrate the grid layout API with the embeddable actions, at which
point the design will be improved - so this is a very temporary state
🙇
### 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] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](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
Partially addresses https://github.com/elastic/kibana/issues/191812
- Adds traversal and manipulation APIs for `SORT` command.
- `commands.sort.listCommands()`
- `commands.sort.getCommand()`
- `commands.sort.list()`
- `commands.sort.findByPredicate()`
- `commands.sort.find()`
- `commands.sort.remove()`
- `commands.sort.insertIntoCommand()`
- `commands.sort.insertExpression()`
- `commands.sort.insertCommand()`
- Refactors "generic" AST manipulation routines into (1) `commands`, (2)
`commands.args`, (3) `commands.options`.
- `generic.commands.*`
- `generic.commands.args.*`
- `generic.commands.options.*`
### Checklist
Delete any items that are not applicable to this PR.
- [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
### For maintainers
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#_add_your_labels)
---------
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
# Summary
Adds a new API deprecations feature inside core.
This feature enabled plugin developers to mark their versioned and
unversioned public routes as deprecated.
These deprecations will be surfaced to the users through UA to help them
understand the deprecation and address it before upgrading. This PR also
surfaces these deprecations to UA.
Closes https://github.com/elastic/kibana/issues/117241
1. Core service to flag deprecated routes
2. UA code to surface and resolve deprecated routes
## Flagging a deprecated Route
### The route deprecation option
We have three types of route deprecations:
- `type: bump`: A version bump deprecation means the API has a new
version and the current version will be removed in the future in favor
of the newer version.
- `type: remove`: This API will be completely removed. You will no
longer be able to use it in the future.
- `type: migrate`: This API will be migrated to a different API and will
be removed in the future in favor of the other API.
All route deprecations expect a documentation link to help users
navigate. We might add a generic documentation link and drop this
requirement in the future but for now this is required.
### Deprecated Route Example
Full examples can be found in the `routing_example` example plugin
located in this directory:
`examples/routing_example/server/routes/deprecated_routes`
```ts
router[versioned?].get(
{
path: '/',
options: {
deprecated: {
documentationUrl: 'https://google.com',
severity: 'warning',
reason: {
type: 'bump',
newApiVersion: '2024-10-13',
},
},
},
},
async (context, req, res) => {
...
```
## Surfaced API deprecations in UA
The list of deprecated APIs will be listed inside Kibana deprecations
along with the already supported config deprecations.
<img width="1728" alt="image"
src="https://github.com/user-attachments/assets/5bece704-b80b-4397-8ba2-6235f8995e4a">
Users can click on the list item to learn more about each deprecation
and mark it as resolved
<img width="1476" alt="image"
src="https://github.com/user-attachments/assets/91c9207b-b246-482d-a5e4-21d0c61582a8">
### Marking as resolved
Users can click on mark as resolved button in the UA to hide the
deprecation from the Kiban deprecations list.
We keep track on when this button was clicked and how many times the API
has been called. If the API is called again the deprecation will
re-appear inside the list. We might add a feature in the future to
permenantly supress the API deprecation from showing in the list through
a configuration (https://github.com/elastic/kibana/issues/196089)
If the API has been marked as resolved before we show this in the flyout
message:
> The API GET /api/deprecations/ has been called 25 times. The last time
the API was called was on Monday, October 14, 2024 1:08 PM +03:00.
> The api has been called 2 times since the last time it was marked as
resolved on Monday, October 14, 2024 1:08 PM +03:00
Once marked as resolved the flyout exists and we show this to the user
until they refresh the page
<img width="1453" alt="image"
src="https://github.com/user-attachments/assets/8bb5bc8b-d1a3-478f-9489-23cfa7db6350">
## Telemetry:
We keep track of 2 new things for telemetry purposes:
1. The number of times the deprecated API has been called
2. The number of times the deprecated API has been resolved (how many
times the mark as resolved button in UA was clicked)
## Code review
- [x] Core team is expected to review the whole PR
- [ ] Docs team to review the copy and update the UA displayed texts
(title, description, and manual steps)
- [x] kibana-management team is expected to review the UA code changes
and UI
- [ ] A few teams are only required to approve this PR and update their
`deprecated: true` route param to the new deprecationInfo object we now
expect. There is an issue tracker to address those in separate PRs later
on: https://github.com/elastic/kibana/issues/196095
## Testing
Run kibana locally with the test example plugin that has deprecated
routes
```
yarn start --plugin-path=examples/routing_example --plugin-path=examples/developer_examples
```
The following comprehensive deprecated routes examples are registered
inside the folder:
`examples/routing_example/server/routes/deprecated_routes`
Run them in the console to trigger the deprecation condition so they
show up in the UA:
```
# Versioned routes: Version 1 is deprecated
GET kbn:/api/routing_example/d/versioned?apiVersion=1
GET kbn:/api/routing_example/d/versioned?apiVersion=2
# Non-versioned routes
GET kbn:/api/routing_example/d/removed_route
POST kbn:/api/routing_example/d/migrated_route
{}
```
1. You can also mark as deprecated in the UA to remove the deprecation
from the list.
2. Check the telemetry response to see the reported data about the
deprecated route.
3. Calling version 2 of the API does not do anything since it is not
deprecated unlike version `1` (`GET
kbn:/api/routing_example/d/versioned?apiVersion=2`)
4. Internally you can see the deprecations counters from the dev console
by running the following:
```
GET .kibana_usage_counters/_search
{
"query": {
"bool": {
"should": [
{"match": { "usage-counter.counterType": "deprecated_api_call:total"}},
{"match": { "usage-counter.counterType": "deprecated_api_call:resolved"}},
{"match": { "usage-counter.counterType": "deprecated_api_call:marked_as_resolved"}}
]
}
}
}
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: florent-leborgne <florent.leborgne@elastic.co>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/191673
Closes https://github.com/elastic/kibana/issues/183566
Fixes the ability for the POST URL used to automate generation of
reports by adding a `generateExportUrl` function to the ShareMenuItemV2
interface. This function returns a dynamic export URL for PDF generation
by using the selected layout option.
Other changes: provides more strictness in type definitions by:
* splitting the types that define `ShareMenuProvider`:
* `ShareMenuProviderV2` provides the `getShareMenuItems` function
* `ShareMenuProviderLegacy` provides the `getShareMenuItemsLegacy`
function
### Release note
Fixed an issue with the export options for PNG/PDF reports in a
dashboard.
### Checklist
Delete any items that are not applicable to this PR.
- [x] Use the `generateExportUrl` function inputs to return a POST URL
that is aware of the layout mode (`print` or `preserve_layout`) and
screen dimensions
- [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://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6986
PR decouples `DashboardCreationOptions` type from `DashboardContainer`
and moves `DashboardCreationOptions` type into dashboard_api folder.
`useControlGroupIntegration` removed from `DashboardCreationOptions`
type since its no longer used.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
TL;DR
- Adds ability to parse out comments from source to AST.
- Adds ability for every AST node to have *decoration*—comments,
which can be attached from left, top, and right from the node.
- Implements routine which attached comments to AST nodes.
- In `BasicPrettyPrinter` adds support only for *left* and *right*
comment printing, as the basic printer prints only on one line.
- In `WrappingPrettyPrinter` adds support for all comment printing for
all AST nodes.
- Introduces a `Query` object and `query` AST node, which represent
thole query—the root node, list of commands.
- The ES|QL AST example plugin now displays the pretty-printed text
version.
### Comments
This PR introduced an optional `formatting` field for all AST nodes. In
the `formatting` field one can specify comment decorations from
different sides of a node.
When parsing, once can now specify the `{ withComments: true }` option,
which will collect all comments from the source while parsing using the
`collectDecorations` routine. It will then also call the
`attachDecorations`, which walks the AST and assigns each comment to
some AST node.
Further, traversal and pretty-print API have been updated to work with
comments:
- The `Walker` has been updated to be able to walk all comments from the
AST.
- The `BasicPrettyPrinter` adds support only for *left* and *right*
inline comment printing, as the basic printer prints only on one line.
- The `WrappingPrettyPrinter` adds support for all comment printing for
all AST nodes. It switches to line-break printing mode if it detects
there are comments with line breaks (those could be multi-line comments,
or single line comments—single line comments are always followed
by a line break). It also correctly inserts punctuation, when an AST
node is surrounded by comments.
### Parsing utils
All parsing utils have been moved to the `/parser` sub-folder.
Files in the `/parser` folder have been renamed as per Kibana convention
to reflect what is inside the file. For example, the `EsqlErrorListener`
class is in a file named `esql_error_listener.ts`.
A `Query` class and `ESQLAstQueryExpression` AST nodes have been
introduced. They represent the result of a full query parse. (Before
that, the AST root was just an array of command nodes, now the AST root
is represented by the `ESQLAstQueryExpression` node.)
### Builder
I have started the implementation of the `Builder` static class in the
`/builder` folder. It is simply a collection of stateless AST node
factories—functions which construct AST nodes.
Some of the `Builder` methods are already used by the parser, more will
follow. We will also use the `Builder` in upcoming [*Mutation
API*](https://github.com/elastic/kibana/issues/191812).
### ES|QL Example Plugin
This PR sets up Storybook and implements few Storybook stories for the
ES|QL AST example plugin, run it with:
```
yarn storybook esql_ast_inspector
```
This PR updates the *ES|QL AST Explorer* example plugin. Start Kibana
with example plugins enabled:
```
yarn start --run-examples
```
And navigate to
[`/app/esql_ast_inspector`](http://localhost:5601/app/esql_ast_inspector)
to see the new example plugin UI.
### 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
### For maintainers
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
## Summary
This is a follow up to EUI's Emotion conversion of
**EuiFormControlLayout/Delimited** (see
https://github.com/elastic/kibana/pull/190752,
https://github.com/elastic/eui/pull/7954, and
https://github.com/elastic/eui/pull/7957).
> [!note]
> Please manually QA your team's affected form control(s) to confirm
they still look and behave as expected and are non-broken. The EUI team
is not familiar enough with each plugin's setups to pull down and QA
this PR ourselves.
While QA testing the upgrade, I noticed a few incorrect usages of
**EuiFormControlLayout** but wanted to wait until after the upgrade to
push out fixes (to prevent delaying the PR further). In general, here is
EUI's [recommended usage of the
component](https://eui.elastic.co/#/forms/form-controls#form-control-layout):
- Where possible, **simply don't use it**. Almost all form controls are
**already** automatically wrapped in any EuiFormControlLayout by
default, and should accept a large majority of the props that the layout
accepts.
- If you **must** use it, set the `controlOnly` prop on the child
input/control to avoid buggy styling (e.g. duplicate borders).
- If you can't do either of the above for any reason (e.g. missing prop
support), reach out to the EUI team to ask for your UX as a feature
request!
### Checklist
Delete any items that are not applicable to this PR.
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
Consolidate to only exposing `DashboardApi` by removing
`DashboardExternallyAccessibleApi` and
`DashboardPluginInternalFunctions` types.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Changes
1. expose DashboardRenderer as lazy loaded component to reduce static
page load size
2. Use `onApiAvailable` prop to pass DashboardApi to parent instead of
`forwardRef`
3. Decouple DashboardApi from legacy embeddable system. This changed
functions such as `updateInput` and using redux `select` to access
state.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Part of https://github.com/elastic/kibana/issues/192005
Closes https://github.com/elastic/kibana/issues/176533
## Summary
This PR represents the first major cleanup task for the control group
embeddable refactor. The tasks included in this PR can be loosely
summarized as follows:
1. This PR removes the old, non-React version of controls
- Note that the new controls are still included under the
`react_controls` folder - I will address this in a follow up PR.
2. This PR removes **all** types associated with the old embeddable
system; i.e. any `*input*` or `*output*` types.
- As part of cleaning up these types, some of the types included in the
`public/react_controls` folder had to be moved to `common` to make them
available to server-side code.
- This resulted in an... unfortunate number of import changes 🫠 Hence
the rather large file change count. I took this opportunity to organize
the imports, too - so a significant chunk of these files are simply
import changes.
3. This PR removes the controls Storybook and all related mocks
- Since the controls storybooks have been broken for awhile, and since
we had plans to remove them but never got around to it, I just decided
to delete them as part of this PR and close
https://github.com/elastic/kibana/issues/176533 rather than spending
time to fix the types for non-operational stories
### 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] [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
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](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
Kibana needs to more tightly control the set of visible features within
a space, in order to support the new solution-based navigation.
Added `scope` field to the features configuration. This enhancement is
intended to prevent new features from appearing in Space Visibility
Toggles.
### 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
__Fixes: https://github.com/elastic/kibana/issues/191299__
## Release Note
Added `scope` field to the features configuration. This enhancement is
intended to prevent new features from appearing in Space Visibility
Toggles.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Extend embeddable examples with a state management example. PR also
refactors embeddable examples to use side nav instead of tabs.
<img width="800" alt="Screenshot 2024-09-11 at 8 38 28 AM"
src="https://github.com/user-attachments/assets/ac46600f-2c45-4f9e-b4f8-a5c03f4eef2f">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/138222
in @types/react@18 types
https://github.com/DefinitelyTyped/DefinitelyTyped/pull/56210. This PR
addresses a bunch of remaining fixes **(hopefully the last mass ping PR
like this)** The most common are:
### 1 Objects are no longer considered a valid ReactNode
In types@17 the ReactNode typing was too soft, it allowed objects and
functions being passed as ReactNode, e.g.
```
let obj: React.ReactNode = {};
let func: React.ReactNode = () => {};
```
This was by mistake, and this PR mutes most of such cases by simply
casting to a `string` or `ReactNode`.
In some cases, it is worth to follow up and address the raised issues in
a better way (see in comments)
```diff
function MyComponent() {
const error: string | Error = 'Error'
return (
<div>
- {error}
+ {error as string}
</div>
)
}
```
Most common problems are related to rendering errors, where it could be
`string | Error` object rendered directly as a ReactNode. Most often it
is related to alerting framework:
```
export interface RuleFormParamsErrors {
[key: string]: string | string[] | RuleFormParamsErrors;
}
```
Not sure if there is a better fix then casting, surely not short-term.
### 2 More `useCallback` implicit any fixes
Follow up to https://github.com/elastic/kibana/pull/191659
### 3 `EuiSelect` doesn't have a placeholder prop
In a couple of places, the `placeholder` prop was removed. This is
because react types were updated and `placeholder` was removed from the
base HTML element, so it highlighted places where `placeholder` prop was
redundant
## Summary
In visualize, renames the new `react_embeddable` folder to just
`embeddable`, and moves the previous `embeddable` folder to
`legacy/embeddable`.
Keeps a few constants and interfaces that are reused in the new
embeddable in the `embeddable` folder, and imports them into
`legacy/embeddable` where needed.
---------
Co-authored-by: Marco Liberati <dej611@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/189820
### Summary
This PR converts the `ControlGroupRenderer` to use the new control group
embeddable, which is built on the new React embeddable framework. With
this conversion, there should not be **any** changes in user-facing
behaviour - therefore, testing of this PR should be focused on ensuring
that no behaviour is changed and/or broken with this refactor.
**Notes to Solution Reviewers:**
- There should be minimal changes to your uses of `ControlGroupRenderer`
- our goal here was to keep the exposed API more-or-less consistent with
this refactor. Therefore, most changes are simply renames + changes of
imports.
- That being said, `updateInput` and `getInput$` are **very much** tied
to the old embeddable infrastructure - so while they will continue to
work for now, they have been deprecated in favour of adding
setters/getters for the parts of the control group state that you need
to update / respond to.
**Notes to Presentation Reviewer:**
- The bundle size was originally being increased by this PR, so I
decided to remove a bunch of the public exports that are no longer
necessary as a final cleanup - this resulted in changes to imports in a
few files, but it was worth doing in this PR IMO so that we didn't have
to increase the Controls bundle limit. Now, this PR shrinks the bundle
size 🎉
- I fixed a small bug with the default value of `showApplySelections` in
this PR - since it was a one-line change, if felt like overkill to
separate it out. See
https://github.com/elastic/kibana/pull/190561/files#r1733253015
### 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
### For maintainers
- [ ] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
PR replaces legacy embeddable control group implementation with react
control group implementation in DashboardContainer.
#### background
Work originally done in https://github.com/elastic/kibana/pull/190273.
https://github.com/elastic/kibana/pull/190273 was reverted by
https://github.com/elastic/kibana/pull/191993 because of dashboard
performance degradation. It was determined that degradation was because
new react embeddable controls fixed a regression where dashboard panels
are loading before control filters are created. This regression was
introduced by https://github.com/elastic/kibana/pull/187509.
The work around is that this PR keeps the currently broken behavior in
main and loads panels before control filters are ready. The thinking is
that the migration would replace like for like and not introduce any
performance changes. Then, at a later time, the regression could be
resolved.
#### reviewing
These are the same changes from
https://github.com/elastic/kibana/pull/190273 minus some work to
introduce a current regression in main. A full re-review is not needed.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <hannah.wright@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Upgrades `@testing-library/user-event` to `^14.5.2`. See the release
notes for `v14` for breaking changes:
https://github.com/testing-library/user-event/releases/tag/v14.0.0
I was facing an
[issue](https://github.com/testing-library/user-event/issues/662) with
`v13.5.0` with `userEvent.click()` in a PR
(https://github.com/elastic/kibana/pull/189729) and was able to verify
that `v14.4.3` onwards fixes it so I decided to update that package.
What a rabbit hole 😅 !
- In `user-event` `v14` events return a promise, so this PR updates
usage of the likes of `userEvent.click` with `await userEvent.click`.
Regex to search for `userEvent` calls that miss `await` except `.setup`:
`(?<!await\s)userEvent\.(?!setup\b)`
- The way to handle pointer events needed changing from `, undefined, {
skipPointerEventsCheck: true });` to `, { pointerEventsCheck: 0 });`.
- I tried a bit to do the refactor with codemods, but there were quite
some edge cases so it ended up being done manually.
- I looked into all failing tests and tried my best to update them, but
for some of them I lacked the context to make them work again. If you're
a code owner and find a skipped test in this PR please give it a try to
fix and push in this PR or let me know if it's fine for you to fix in
follow ups.
List of files where I had to skip tests (`git diff main...HEAD
-G'\.skip' --name-only`):
### `packages/kbn-dom-drag-drop`
- `packages/kbn-dom-drag-drop/src/droppable.test.tsx`
### `x-pack/plugins/cases`
- `x-pack/plugins/cases/public/components/templates/form.test.tsx`
-
`x-pack/plugins/cases/public/components/user_actions/user_actions_list.test.tsx`
### `x-pack/plugins/cloud_security_posture`
-
`x-pack/plugins/cloud_security_posture/public/components/fleet_extensions/policy_template_form.test.tsx`
### `x-pack/plugins/lens`
-
`x-pack/plugins/lens/public/datasources/form_based/dimension_panel/format_selector.test.tsx`
### `x-pack/plugins/observability_solution`
-
`x-pack/plugins/observability_solution/synthetics/public/apps/synthetics/components/monitor_add_edit/fields/request_body_field.test.tsx`
### `x-pack/plugins/security_solution`
-
`x-pack/plugins/security_solution/public/management/components/console/components/command_input/integration_tests/command_input.test.tsx`
-
`x-pack/plugins/security_solution/public/management/components/endpoint_responder/command_render_components/integration_tests/kill_process_action.test.tsx`
-
`x-pack/plugins/security_solution/public/management/components/endpoint_responder/command_render_components/integration_tests/release_action.test.tsx`
-
`x-pack/plugins/security_solution/public/management/components/endpoint_responder/command_render_components/integration_tests/status_action.test.tsx`
-
`x-pack/plugins/security_solution/public/management/components/endpoint_responder/command_render_components/integration_tests/upload_action.test.tsx`
-
`x-pack/plugins/security_solution/public/management/components/endpoint_response_actions_list/integration_tests/response_actions_log.test.tsx`
-
`x-pack/plugins/security_solution/public/management/pages/event_filters/view/components/event_filters_flyout.test.tsx`
-
`x-pack/plugins/security_solution/public/management/pages/response_actions/view/response_actions_list_page.test.tsx`
----
I plan to do a talk on Kibana Demo Days to walk through some of the
breaking changes and learnings.
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
PR adds PresentationContainer to embeddable examples. This example shows
developers how to create a dashboard like experience with embeddable
registry and PresentationContainer interfaces
### Test instructions
1. start kibana with `yarn start --run-examples`
2. install web logs sample data
3. navigate to `http://localhost:5601/app/embeddablesApp`
4. Select `PresentationContainer example` tab
### Presentation container example
Example starts with empty display and users can add embeddables
<img width="800" alt="Screenshot 2024-09-05 at 1 58 55 PM"
src="https://github.com/user-attachments/assets/406651ca-e611-4a3e-8b2d-4207eb5011b1">
Editing time range, adding or removing panels, or changing panel state
by adding custom time ranges will show unsaved changes and allow user to
reset changes or save changes
<img width="800" alt="Screenshot 2024-09-05 at 1 59 51 PM"
src="https://github.com/user-attachments/assets/cd84e39c-6de0-4ac6-832f-7d8e3682610b">
After adding an embeddable, user can use panel actions to remove the
embeddable
<img width="800" alt="Screenshot 2024-09-05 at 2 00 50 PM"
src="https://github.com/user-attachments/assets/63a2515c-f378-419f-b2f5-db71712fdffc">
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
#190273 introduced a performance regression. Reverting to move metrics to baseline again and create some time to identify root cause.
Co-authored-by: Thomas Neirynck <thomas@elastic.co>
closes https://github.com/elastic/kibana/issues/191137,
https://github.com/elastic/kibana/issues/190988,
https://github.com/elastic/kibana/issues/191155
PR replaces legacy embeddable control group implementation with react
control group implementation in DashboardContainer.
### Test instructions
1. Open dashboard via dashboard application or portable dashboard
2. Mess around with controls. There should be no changes in behavior
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
PR added `lastUsedDataViewId$` to `ControlGroupApi`.
`lastUsedDataViewId$` is implemented in `initializeControlsManager`.
PR also cleaned up typings by removing `DataControlEditorState`.
`DataControlEditorState` was a weird smooshing together of
DefaultDataControlState and stuff used by the editor. Instead of
`DataControlEditorState`, values used by the editor are just passed in
as top level keys.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR has breadth, but not depth. This adds 3 new `eslint` rules. The
first two protect against the use of code generated from strings (`eval`
and friends), which will not work client-side due to our CSP, and is not
something we wish to support server-side. The last rule aims to prevent
a subtle class of bugs, and to defend against a subset of prototype
pollution exploits:
- `no-new-func` to be compliant with our CSP, and to prevent code
execution from strings server-side:
https://eslint.org/docs/latest/rules/no-new-func
- `no-implied-eval` to be compliant with our CSP, and to prevent code
execution from strings server-side:
https://eslint.org/docs/latest/rules/no-implied-eval. Note that this
function implies that it prevents no-new-func, but I don't see [test
cases](https://github.com/eslint/eslint/blob/main/tests/lib/rules/no-implied-eval.js)
covering this behavior, so I think we should play it safe and enable
both rules.
- `no-prototype-builtins` to prevent accessing shadowed properties:
https://eslint.org/docs/latest/rules/no-prototype-builtins
In order to be compliant with `no-prototype-builtins`, I've migrated all
usages and variants of `Object.hasOwnProperty` to use the newer
[`Object.hasOwn`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwn).
Move react_controls from examples plugin to controls plugin. This PR
does not effect user facing features since it does not effect the legacy
control group implementation or its usage. Future PRs will integrate the
new control group with dashboard and ControlGroupRenderer and then
remove the legacy control group implementation.
PR increases page load bundle size because of new action registration
and the control group react embeddable registration. This will be a
temporary increase as removing the legacy control group will remove the
legacy embeddable factory registration, which is larger then react
embeddable registration.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Hannah Mudge <Heenawter@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
