## 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>
Fixes https://github.com/elastic/kibana/issues/189580
PR awaits until all control filters are ready and then applies
selections during reset.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/189407
## Summary
This PR adds an `order` attribute to the control factory so that the
ordering in the UI remains consistent - previously, the order was
determined by the order the factories were registered in (which is no
longer predictable now that the registration happens `async` - it's hard
to repro, but there were times where something delayed the options list
registration and it would appear at the end of my list). Adding and
sorting the UI based on the `order` of the factory removes this
uncertainty.
### 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)
## Summary
The range slider `value` was getting overwritten by the old value on
edit after the field name changed because we were passing in `value` as
part of the editor state manager - so, this resulted in the following
when editing a range slider with a defined `value` (for the sake of
clarity, let's say `value = [100, 200]`.
1. Change the field name to another number field (keeping it as a range
slider control) and save your changes
2. On save, the editor loops through the provided state manager key by
key and updates the control
3. The `fieldName` key is hit first because of the order of spread, so
this gets updated - which triggers the `fieldChangedSubscription` and
sets `value` to `undefined`
4. The `value` key gets hit afterward, which still has the old `[100,
200]` value because we don't clear up the dirty state - so, the editor
calls `value$.next([100, 200])`
5. The edited control now has the same selection as the old control
🔥
We should only add state to the editor state manager **that the editor
can change** - and since `value` is never changed via the editor,
removing this from the state manager fixes the above situation. I've
added a comment to hopefully clarify this.
### How to test
1. Create a range slider control and make a value change on it
2. Edit that control and pick a different data view and/or field - keep
it as a range slider control!
3. The value selected at step 1 **should be cleared**
### Before
https://github.com/user-attachments/assets/e6700538-deda-4196-8f52-c5446fa06518
### After
https://github.com/user-attachments/assets/be47fb2c-ecbf-4274-8beb-82a7e5462874
### 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)
While reviewing https://github.com/elastic/kibana/pull/188687, I noticed
that controls where still getting filtered by timeslider changes even
when chaining was disabled or the control was to the left of the
timeslider. This PR resolves this issue by only passing in timeslice
from `chaining$` instead of `controlGroupFetch$`.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
