## Summary
Removes the mSearch method from Dashboard content management.
The `mSearch` content management method was designed to be a temporary
implementation of search that allowed searching multiple saved object
types ([see more
[internal]](https://docs.google.com/document/d/1ssYmqSEUPrsuCR4iz8DohkEWekoYrm2yL4QR_fVxXLg/edit?tab=t.0#heading=h.6sj4n6bjcgp5)).
However, the mSearch implementation in the Dashboard Storage class lacks
extensibility as it requires a synchronous `toItemResult` function. As
we start migrating reference handling to the server, we will likely need
transforms that return Promises (ex. `savedObjectToItem`), such as
[retrieving tag saved objects from the SavedObjectTagging
client](https://github.com/elastic/kibana/issues/210619).
The Dashboard `mSearch` method was only used by the dashboard_picker and
this PR replaces its usage with the `search` method.
### Identify risks
There is a slight risk in serverless environments where a browser may
have already loaded the dashboard_picker module but lags behind the
server. In this case, the dashboard picker may fail to retrieve a list
of dashboards due to it calling the now non-existent `mSearch` method
provided by the server. In this case, the user simply needs to refresh
their browser to retrieve the latest UI modules.
## Summary
This PR optimizes the FTR service initialization by not loading UI
service for API tests and by removing retries during test user setup
## Changes
- Remove loading of common UI services from common services (UI services
should not be loaded for API tests)
- Move `security` service from `@kbn/ftr-common-functional-ui-services`
to `@kbn/ftr-common-functional-services` as it should be available to
API tests as well
- Only try once to delete `testUser` during init (this user usually does
not exist on a fresh deployment - and if it does, a single delete
request is enough to get rid of it)
## Benchmark results
**These changes will reduce FTR CI runtime overall by ~100 minutes**
🚀
Due to parallel workers in CI, the effective runtime of the whole CI job
will be less than that.
- The removal of UI service loading (which includes starting a browser
instance) for API tests reduces init time by ~0.5 seconds. With 313 API
configs that are started on CI, this reduces the runtime overall by ~156
seconds / ~2.6 minutes.
- The removal of test user delete retries reduces init time by ~10
seconds. With 589 FTR configs that are started on CI, this reduces the
runtime overall by ~5890 seconds / ~98 minutes.
- These numbers have been taken on a local machine and since CI workers
are usually slower, we should see at least this amount of improvement if
not more in CI.
- Fixes https://github.com/elastic/kibana/issues/211109
## Summary
This PR fixes a number of bugs in fields popularity logic:
- [x] If field popularity was customized via UI form, the value will be
saved now as a number instead of a string
- [x] Same for runtime fields in another part of the code
- [x] Since the data was polluted with string values, this PR makes sure
that the incrementing would still work and the result would be converted
to number.
- [x] If user opened the field flyout, when selected/deselected fields
as columns in the table, then opened the field flyout again, the data
shown as Popularity was outdated. Now it should be fixed.
- [x] Prevents reseting of Popularity scores in other fields.
- [x] Functional tests in
`test/functional/apps/discover/group6/_sidebar.ts` and
`test/functional/apps/management/data_views/_index_pattern_popularity.ts`.
### Checklist
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
## Summary
Updating the ES client to 9.0.
Resolves#116102
## What changes?
**Breaking change**: `body` has been removed.
Most of the changes are about bringing all the content inside the body
as a root attribute to the API params:
```diff
const response = await client.search({
index: 'test',
- body: {
query: {
match_all: {}
}
- }
})
```
For this reason, enabling the "Hide whitespace changes" option when
reviewing is recommended.
Some exceptions to this rule:
* Bulk APIs replace the `body` array with `operations` array (direct
replacement)
* Index Put Settings API replace `body` array with `settings` (direct
replacement)
* Msearch replaces the `body` array with `searches` array (direct
replacement)
* Document Index API replaces `body` with `document` (direct
replacement)
* Create Repository replaces `body` with `repository` (direct
replacement)
Because of a known issue in the client
(https://github.com/elastic/elasticsearch-js/issues/2584), there's still
an escape hatch to send data in the body in case the specific use case
requires it via `// @ts-expect-error elasticsearch@9.0.0
https://github.com/elastic/elasticsearch-js/issues/2584`, but it
shouldn't be abused because we lose types. In this PR we've used it in
those scenarios where we reuse the response of a GET as the body of a
PUT/POST.
### Other changes
* `estypes` can be imported from the root of the library as `import type
{ estypes } from '@elastic/elasticsearch';`
* `estypesWithBody` have been removed
* `requestTimeout`'s 30s default has been removed in the client. This PR
explicitly adds the setting in all client usages.
### Identify risks
- [x] The client places unknown properties as querystring, risking body
params leaking there, and causing 400 errors from ES => Solved by
forcing `body` usage there via `// @ts-expect-error elasticsearch@9.0.0
https://github.com/elastic/elasticsearch-js/issues/2584`. The next
version of the client will address this.
- [x] We need to run the MKI tests to make sure that we're not breaking
anything there =>
https://elastic.slack.com/archives/C04HT4P1YS3/p1739528112482629?thread_ts=1739480136.231439&cid=C04HT4P1YS3
---------
Co-authored-by: Gloria Hornero <gloria.hornero@elastic.co>
## Summary
The `/packages` folder at the root of the Kibana repository used to
contain a lot of packages.
In the context of SKA, they have been gradually moved to various
locations:
* `src/platform/packages`
* `x-pack/platform/packages`
* `src/core/packages`
Currently, only `devOnly: true` packages are left in this folder. This
comprises libraries for CLI scripts as well as testing utilities.
With this PR, we are moving ~half of these packages under
`src/platform/packages/(private|shared)/`.
In particular, we are moving those packages that are being used from
platform and/or solutions.
Since they are `"devOnly": true`, this means they are ONLY used from
tests, cypress tests, storybook configs, ./scripts/ folders inside some
modules, or other non-prod-time logic. Nonetheless, they are effectively
referenced from platform and/or solutions code, hence I decided they
should be placed under `platform` folders.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR was created in response to
https://github.com/elastic/kibana/pull/208858, it migrates all existing
language definitions within the `@kbn/code-editor` package into the
`@kbn/monaco` package to provide a separation of concern for logic that
doesn't particularly relate to the configurations for the code editor
UI.
With this change, all supported languages are ingested from the
`@kbn/monaco` package where they will be domiciled from henceforth, and
in turn fix the issue that was discovered relating to the way the
language definitions within `@kbn/code-editor` get registered as a side
effect.
With this change, to add support for a new language, said language
should be defined within `@kbn/monaco`, and registered in
`languages/index.ts`.
<!--
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] [See some risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx)
- [ ] ...
-->
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
part of https://github.com/elastic/kibana/issues/208908
Replaces scss to css-in-js. I've tested all the changes.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana/issues/195418
Gives `FROM` and `METADATA` autocomplete logic its own home 🏡
### 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
### Identify risks
- [ ] As with any refactor, there's a possibility this will introduce a
regression in the behavior of FROM. However, all automated tests are
passing and I have tested the behavior manually and can detect no
regression.
---------
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/204249
Clean up work from embeddable refactor. PR removes
`DashboardContainerInput` type, which is a duplicate of `DashboardState`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds a test config category to the scout reporting. This allows
us to distinguish between UI and API FTR tests.
A new property `testConfigCategory` has been added to all FTR configs
that don't already inherit it from a higher level config.
Closes https://github.com/elastic/kibana/issues/180057
The following items needed to be replaced with add panel actions
* vega - visType
* markdown - visType
* lens - visTypeAlias
* maps - visTypeAlias
As an added benefit, now these actions are displayed in embeddable
examples that uses ADD_PANEL_TRIGGER
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Resolves#209261
## Summary
Removes the code used to render Logs Explorer. This does not result in
any functional changes.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR fixes the missing highlight theme for HJSON specs in Vega.
The issue https://github.com/elastic/kibana/issues/205711 was caused by
https://github.com/elastic/kibana/pull/182348 that inadvertently
specified the code-editor package as sideEffect free. This cause the
compiler to exclude every import without exported and used methods.
This was the case for the code-editor that registered some language
highlighters in that way.
The solution adopted here is to mark the register_language.ts file as a
file with side effects, the alternative solution can be to register
these directly from within the code_editor component.
A third option is to move these registration within the monaco package
where other languages are also registered.
I'd like to leave to @elastic/appex-sharedux the preference to followup
with a better fix for the future.
I'd also like to have the opinion from @elastic/kibana-operations
because the misconfigured package issue can be seen only in production
and not in development mode. Is it possible that webpack doesn't apply
treeshaking when in development mode?
fix https://github.com/elastic/kibana/issues/205711
Should also fix the same issue but for TSVB Markdown
The fix was tested on CI by running at first only the CI FT with the
`sideEffects:false` to verify the failure (see
[build](https://buildkite.com/elastic/kibana-pull-request/builds/272375))
and then with the fix specifying the actual file that contains side
effects.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Users should use Lens to visualize data. Users should not use TSVB or
aggregation based panels. To this end, "easy button" UIs, such as
dashboard's "Add panel" flyout, should guide users to lens and not guide
them to legacy applications.
This PR removes `legacy` section from dashboard "Add panel" flyout.
Users can still add legacy panels to dashboards via "visualize"
application. The path is more steps, but this is as intended. Using old
stuff should be painful and require extra work as a caret to move users
to new stuff.
<img width="500" alt="Screenshot 2025-01-23 at 1 08 41 PM"
src="https://github.com/user-attachments/assets/e142cba9-a880-4ad6-a3f8-a981a03daaec"
/>
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR reworks saved query privileges to rely solely on a single global
`savedQueryManagement` privilege, and eliminates app-specific overrides.
This change simplifies the security model for users, fixes bugginess in
the saved query management UI, and reduces code complexity associated
with maintaining two separate security mechanisms (app-specific
overrides and global saved query management privileges).
### Background
Saved queries allow users to store a combination of KQL or Lucene
queries, filters, and time filters to use across various applications in
Kibana. Access to saved query saved objects are currently granted by the
following feature privileges:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_savedQueryManagement.all",
"feature_maps.all",
"feature_savedObjectsManagement.all",
"feature_visualize.all"
]
```
There is also a saved query management UI within the Unified Search bar
shared by applications across Kibana:
<img
src="https://github.com/user-attachments/assets/e4a7539b-3dd4-4d47-9ff8-205281ef50e3"
width="500" />
The way access to this UI is managed in Kibana is currently confusing
and buggy:
- If a user has `feature_discover.all` and `feature_dashboard.all` they
will be able to load and save queries in Discover and Dashboard.
- If a user has `feature_discover.all` and `feature_dashboard.read` they
will be able to load queries in both Discover and Dashboard, but only
save queries in Discover (even though they have write access to the SO,
and API access). Instead they have to navigate to Discover to save a
query before navigating back to Dashboard to load it, making for a
confusing and frustrating UX.
- Access to the UI is even more confusing in apps not listed in the
above feature privileges (e.g. alerting, SLOs). Some of them chose to
check one of the above feature privileges, meaning users who otherwise
should have saved query access won't see the management UI if they don't
also have the exact feature privilege being checked. Other apps just
always show the management UI, leading to bugs and failures when users
without one of the above feature privileges attempt to save queries.
### Existing improvements
In v8.11.0, we introduced a new ["Saved Query
Management"](https://github.com/elastic/kibana/pull/166937) privilege,
allowing users to access saved queries across all of Kibana with a
single global privilege:
<img
src="https://github.com/user-attachments/assets/ccbe79a4-bd0b-4ed6-89c9-117cc1f99ee2"
width="600" />
When this privilege is added to a role, it solves the
`feature_discover.all` and `feature_dashboard.read` issue mentioned
above. However, it does not fix any of the mentioned issues for roles
without the new privilege. We have so far postponed further improvements
to avoid a breaking change.
### Approach
To fully resolve these issues and migrate to a single global privilege,
these changes have been made:
- Remove saved query SO access from all application feature privileges
and instead only allow access through the global saved query management
privilege.
- Stop relying on application feature privileges for toggling the saved
query management UI, and instead rely on the global privilege.
To implement this with minimal breaking changes, we've used the Kibana
privilege migration framework. This allows us to seamlessly migrate
existing roles containing feature privileges that currently provide
access to saved queries, ensuring they are assigned the global saved
query management privilege on upgrade.
As a result, we had to deprecate the following feature privileges,
replacing them with V2 privileges without saved query SO access:
```json
[
"feature_discover.all",
"feature_dashboard.all",
"feature_maps.all",
"feature_visualize.all"
]
```
Each area of code that currently relies on any of these feature
privileges had to be updated to instead access `feature_X_V2` instead
(as well as future code).
This PR still introduces a minor breaking change, since users who have
`feature_discover.all` and `feature_dashboard.read` are now able to save
queries in Dashboard after upgrade, but we believe this is a better UX
(and likely the expected one) and worth a small breaking change.
### Testing
- All existing privileges should continue to work as they do now,
including deprecated V1 feature privileges and customized serverless
privileges. There should be no changes for existing user roles apart
from the minor breaking change outlined above.
- Check that code changes in your area don't introduce breaking changes
to existing behaviour. Many of the changes are just updating client UI
capabilities code from `feature.privilege` to `feature_v2.privilege`,
which is backward compatible.
- The `savedQueryManagement` feature should now globally control access
to saved query management in Unified Search for all new user roles.
Regardless of privileges for Discover, Dashboard, Maps, or Visualize,
new user roles should follow this behaviour:
- If `savedQueryManagement` is `none`, the user cannot see or access the
saved query management UI or APIs.
- If `savedQueryManagement` is `read`, the user can load queries from
the UI and access read APIs, but cannot save queries from the UI or make
changes to queries through APIs.
- If `savedQueryManagement` is `all`, the user can both load and save
queries from the UI and through APIs.
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md)
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
### Identify risks
This PR risks introducing unintended breaking changes to user privileges
related to saved queries if the deprecated features have not been
properly migrated, and users could gain or lose access to saved query
management on upgrade. This would be bad if it happened, but not overly
severe since it wouldn't grant them access to any ES data they couldn't
previously access (only query saved objects). We have automated testing
in place to help ensure features have been migrated correctly, but the
scope of these changes are broad and touch many places in the codebase.
Additionally, the UI capabilities types are not very strict, and are
referenced with string paths in many places, which makes changing them
riskier than changing strictly typed code. A combination of regex
searches and temporarily modifying the `Capabilities` type to cause type
errors for deprecated privileges was used to identify references in
code. Reviewers should consider if there are any other ways that UI
capabilities can be referenced which were not addressed in this PR.
Our automated tests already help mitigate the risk, but it's important
that code owners thoroughly review the changes in their area and
consider if they could have unintended consequences. The Platform
Security team should also review this PR thoroughly, especially since
some changes were made to platform code around privilege handling. The
Data Discovery team will also manually test the behaviour when upgrading
existing user roles with deprecated feature privileges as part of 9.0
upgrade testing.
---------
Co-authored-by: Matthias Wilhelm <matthias.wilhelm@elastic.co>
Co-authored-by: Matthias Wilhelm <ankertal@gmail.com>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: “jeramysoucy” <jeramy.soucy@elastic.co>
## Summary
This PR adds an "All logs" ad hoc (temporary) data view to the Discover
Observability root profile based on the central log sources setting,
allowing quick access to logs (with the most up to date log sources)
without needing to first manually create a data view:
To support this, a new `getDefaultAdHocDataViews` extension point has
been added to Discover, allowing profiles to specify an array of ad hoc
data view specs would should be created by default when the profile is
resolved, and automatically cleaned up when the profile changes or the
user leaves Discover.
Resolves#201669.
Resolves#189166.
### Notes
- The "All logs" ad hoc data view should only appear when using the
Observability Solution view (in any deployment type).
- Data view specs returned from `getDefaultAdHocDataViews` must include
consistent IDs across resolutions in order for Discover to manage them
correctly (e.g. to find and reload the data view after a page refresh).
Situations where we'd expect a change in ID (e.g. when saving to a
Discover session) are handled internally by Discover.
- To avoid a breaking change, the returned ad hoc data views have no
impact on the default data view shown when navigating to Discover. If
any persisted data views exist, one of them will be used as the default.
If no persisted data views exist, the first entry of the array returned
by `getDefaultAdHocDataViews` will be used as the default.
- We still want to notify users in Discover when they have no ES data at
all, and prompt them to install integrations. For this reason, the "no
data" page is still shown in Discover even if there are default profile
ad hoc data views (unlike if there are persisted data views, in which
case we use the default and hide the "no data" page).
- When saving a Discover session that uses a default profile ad hoc data
view, the data view will be copied on save as `{DATA_VIEW_NAME} (copy)`.
This allows us to assign a unique ID to the version that gets saved with
the Discover session, and avoids having to choose between the profile
data view or the embedded data view when reopening the session, which
has drawbacks:
- If choosing the profile data view, the Discover session may display
incorrectly if the log sources setting changed since it was saved, and
the user would no longer be able to view the session as it was intended
without first modifying the setting to the expected value.
- If choosing the embedded data view, the replacement shown after
opening the Discover session may not reflect the latest log sources
setting until a new session is started, and there would be no way for
the user to migrate the session to use the latest version of the profile
data view.
### Checklist
- [x] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
Fixes https://github.com/elastic/kibana/issues/204381
## Summary
The test that verifies tab changes in Console was failing because it was
verifying the presence of the tab content before it was fully loaded.
### Checklist
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
1. Extends the server-side prototype pollution protections introduced in
https://github.com/elastic/kibana/pull/190716 to include
`Array.prototype`.
2. Applies the same prototype pollution protections to the client-side.
### Identify risks
Does this PR introduce any risks? For example, consider risks like hard
to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified
risk. Invite stakeholders and evaluate how to proceed before merging.
- [ ] Sealing prototypes on the client can lead to failures in
third-party dependencies. I'm relying on sufficient functional test
coverage to detect issues here. As a result, these protections are
disabled by default for now, and can be controlled via setting
`server.prototypeHardening: true/false`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/203967
Supports dashboard variables in ES|QL charts.
This PR introduces the first phase of ES|QL controls. In this phase:
- the flow starts from Lens ES|QL editor (and no vice-versa, this will
happen on a later phase after we discuss some technical details with ES)
- it is only available for dashboards (we want to include them in other
apps as Discover but this is the next phase driven by the presentation
team)
- it supports variables for intervals, fields and values. I haven't
added support for functions. I am going to do it after this PR being
merged (there are some business questions I want to answer first)
For more info check this
[deck](https://docs.google.com/presentation/d/1qSbWLSoC5SseXuLix763vpp8sa7ikp3pQTbHImEHBoc)
### Implementation details
- There is a new service, the ESQLVariables service that is responsible
for ES|QL variables. I isolated this to a new plugin owned by the ES|QL
team for cleaner code and for avoiding circular dependencies
- A new ESQL_CONTROL type got created. It follows the exact same logic
as the rest controls. No changes in the architecture here.
- The creation of the controls (the control forms) have been added in
the esql plugin.
- Lens has small changes:
- The support of variables in the textBased datasource
- Two callbacks needed to be called after the creation / cancellation of
an ES|QL control
### Types of ES|QL variables
We have 2 types:
- Static Values (the user gives a list of values with his own
responsibility). As the flow starts from the editor we can identify what
they most possibly want to do and we give the user some options but they
have the freedom to do as they want. A basic validation has been added
too.
- Values from an ES|QL query (the user gives an ES|QL query that
generates the values). As the flow starts from the editor we can suggest
a query for the users but they can always change it as they wish.
<img width="1168" alt="image"
src="https://github.com/user-attachments/assets/cc28beb8-111c-43ad-9f26-865bc62ae512"
/>
### Example of a control creation from the editor
### Release note
ES|QL charts now allow the creation of controls in dashboards. You can
control a part of the query such as a field, an interval or a value.
### 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
- [x] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [x] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Andrea Del Rio <delrio.andre@gmail.com>
Co-authored-by: Devon Thomson <devon.thomson@elastic.co>
## Summary
Updated the search plugin config endpoint to return just features and
kibana version, removing the call to the enterprise search node.
### Checklist
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
PR cleans up presentation interface names for consistentency
* adds `$` suffix to all observables. For example, `dataLoading` =>
`dataLoading$`
* removes `Panel` naming convention from interface names since an api
may not be a panel, an api may be a dashboard. For example,
`PublisesPanelTitle` => `PublishesTitle`
#### Note to Reviewers
Pay special attention to any place where your application creates an
untyped API. In the example below, there is no typescript violation when
the parent returns `dataLoading` instead of `dataLoading$` since the
parent is not typed as `PublishesDataLoading`. Please check for
instances like these.
```
<ReactEmbeddableRenderer
getParentApi={() => {
dataLoading: new BehaviorSubject()
}}
/>
```
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Unifies the various `LibraryTransforms` interfaces, updates all by reference capable embeddables to use them in the same way, and migrates the clone functionality to use only serialized state.
