Currently we remove CODEOWNERS on backport branches to avoid review
assignments: reviews were already collected on the source pull request.
If there's a conflict, it will go through another round of review but
not require all the original assignees.
We want to re-add the file for our own tooling, and to avoid CODEOWNERS
merge conflicts on backports. To do this, we're going to add a global
override to code assignments on backport branches.
This updates our CODEOWNERS libraries to ignore assignments to
`kibanamachine`.
---------
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
Closes https://github.com/elastic/kibana/issues/185028
## Summary
### Problem
The ticket mentions that there was an issue with displaying results.
However both `display results` and `visualize query` are working as
expected based on my investigation. More details including a video are
attached
[here](https://github.com/elastic/kibana/issues/185028#issuecomment-2464879452).
The function calling loop seems to occur when the AI Assistant is trying
to send the output to Slack via the Kibana Slack connector. In order to
do this, the LLM invokes the function `execute_connector`. For the Slack
connector, `id` and `params` properties are required. However, the LLM
only populated `id` and not `params` which causes an error when
validated against the schema for the Slack connector.
- Sometimes, it's able to retry a few times and successfully send the
output to Slack.
- Sometimes, it goes into a loop trying to find `params` and failing
repeatedly.
Attaching another similar issue for more context -
https://github.com/elastic/kibana/issues/195564
_With the solution below, my intention is to send the output to Slack in
one go, without retrying the function `execute_connector`._
### Solution
Based on the solutions I experimented with, seems like we need to force
the LLM to understand what's needed for the Slack connector. I tried a
few options here and the combination of updates that worked are as
follows:
- Appending an AdHoc instruction about the Slack connector properties.
(This gives the LLM some additional information about the required
properties)
- Updating the `properties` attached to the connector (when passing the
connector list to the LLM), to reflect both `id` and `params` with
`message`.
With the above change, the AI Assistant has managed to consistently send
the output to Slack _**without any retries**_ because of missing
`params`.
### Screenshots:
(all alert triggers successfully sent the output to Slack without having
to retry the function)
<img width="1452" alt="success-attempts-to-slack-connector"
src="https://github.com/user-attachments/assets/715a5957-2c04-4a55-868f-34abe564f6d4">
Closes https://github.com/elastic/kibana/issues/191777
In 8.15, map embeddable was migrated from a legacy embeddable to a react
embeddable. This changed reference injection. See below for details.
TLDR is that legacy embeddables pass all references to the embeddable
factory when no references for the panel exist. React embeddables just
pass an empty reference list regardless of if panel references exist or
not.
[Reference injection with legacy
embeddables](https://github.com/elastic/kibana/blob/8.15/src/plugins/dashboard/common/dashboard_container/persistable_state/dashboard_container_references.ts#L53)
```
workingState.panels[key] = { ...panel };
const filteredReferences = getReferencesForPanelId(key, references);
const panelReferences = filteredReferences.length === 0 ? references : filteredReferences;
```
[Reference injection with react
embeddables](https://github.com/elastic/kibana/blob/8.15/src/plugins/dashboard/public/dashboard_container/embeddable/dashboard_container.tsx#L835)
```
const rawState = this.getInput().panels[childId].explicitInput;
const { id, ...serializedState } = rawState;
if (!rawState || Object.keys(serializedState).length === 0) return;
const references = getReferencesForPanelId(childId, this.savedObjectReferences);
return {
rawState,
references,
};
```
### Test instructions
1) install dashboard from 7.17 saved objects from issue.
2) Open dashboard. Verify data-view is found. Note, layer will not load
since your install has no index 'logstash-*', but reference problem has
been fixed
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
closes [#198758](https://github.com/elastic/kibana/issues/198758)
## Summary
This PR removes the Entity type used across the Inventory and replaces
it with `InventoryEntityLatest`, which provides strong typing for the
latest entity object. This change makes the code leverage TypeScript’s
intellisense and autocompletion in the editor, making the code easier to
work with and more maintainable across the codebase.
`InventoryEntityLatest` is the interface that the API returns and what
the UI consumes. Note that this is distinct from the index mapping
defined by `entityLatestSchema`, creating a separation layer between
Elasticsearch and the UI.
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
### Context
In our Cypress tests, we use API calls to set up the data needed to run
the tests. Currently, we are using basic authentication for both ESS and
serverless environments. However, for serverless, we should be using API
key authentication, especially given that basic authentication will be
deprecated soon.
### Challenges
* Handling different authentication methods depending on whether the
environment is serverless or ESS.
* Allowing some tests to access or modify internal indexes.
* Managing how the username is handled across different tests.
### Implentation
To ensure the correct authentication is used based on the environment
where the tests are executed, the `rootRequest` method is used to build
the API request. Within this method, the appropriate authentication type
is selected.
All API calls will use an `admin` API key. The `admin` role is the least
restrictive, which is appropriate for setting up data for tests rather
than validating application behavior. This role minimizes the risk of
issues during setup.
A specific challenge arose when we needed to access or modify internal
indexes, a capability restricted to the `system_indices_superuser` role
for testing purposes. The issue stems from the API key generation
method, which is tied to the user's role rather than the user itself.
Since serverless currently lacks a role that permits access to internal
indexes, we are, upon recommendation from the appex-qa team, using the
Elasticsearch client directly with the `system_indices_superuser` role
for these scenarios.
For tests that assert the username, we made adjustments. Previously, the
`system_indices_superuser` role was used universally, which is no longer
the case for serverless. We now retrieve the username dynamically from
user information instead of hardcoding the value.
### To be discussed
When making modifications related to "username", it became apparent that
we sometimes use "fullname" and, in other cases, "username," even though
they seem intended to represent the same concept. Should we standardize
on a single term across the solution?
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Extracts `IndexAdapter` from `DataStreamAdapter` and
`IndexPatternAdapter` from `DataStreamSpaceAdapter`.
There are no breaking changes for the _data-stream-adapter_ package; the
behavior of both the `DataStreamAdapter` and `DataStreamSpaceAdapter`
remains unchanged.
The new _index-adapter_ package exports `IndexAdapter` and
`IndexPatternAdapter` to manage individual indices without using data
streams.
This is needed for SIEM rule migrations.
---------
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/198976
Part of https://github.com/elastic/kibana/issues/193245
This PR contains the changes to migrate infrastructure test folder to
Deployment-agnostic testing strategy.
#### How to test
Serverless
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts --grep="APM"
```
It's recommended to be run against
[MKI](https://github.com/crespocarlos/kibana/blob/main/x-pack/test_serverless/README.md#run-tests-on-mki)
Stateful
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts --grep="APM"
```
Checks
- [ ] (OPTIONAL, only if a test has been unskipped) Run flaky test suite
- [x] local run for serverless
- [x] local run for stateful
- [x] MKI run for serverless
## Summary
This PR makes the `vis-type-timeseries-plugin` a shared component fixing
the dependency error for infra plugin.
I removed the infra folder from the exceptions list because it was
preventing the linter from acknowledging the fix.
1. Speeds up functional test suite by setting the time picker via ui
settings
2. removes legacy tests from editor frame (replaced by adding some
conditions to drag_drop functional tests) as they were not the best
tests anyway
## Summary
Closes https://github.com/elastic/kibana/issues/198969
Part of https://github.com/elastic/kibana/issues/193245
This PR contains the changes to migrate `environment` test folder to
Deployment-agnostic testing strategy.
### How to test
- Serverless
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts --grep="APM"
```
It's recommended to be run against
[MKI](https://github.com/crespocarlos/kibana/blob/main/x-pack/test_serverless/README.md#run-tests-on-mki)
- Stateful
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts --grep="APM"
```
## Checks
- [ ] (OPTIONAL, only if a test has been unskipped) Run flaky test suite
- [x] local run for serverless
- [x] local run for stateful
- [x] MKI run for serverless
Move the following Dataset Quality API Integration test suites
to deployment agnostic test suites:
1. `/data_streams/degraded_docs.spec.ts`
2. `/data_streams/degraded_fields.spec.ts`
3. `/data_streams/data_stream_details.spec.ts`
4. `/data_streams/degraded_field_values.spec.ts`
Note that individual tests (e.g. related to authorization in suites) or
test suites dependent on role management, or the ones which behave
differently on Serverless vs. Stateful, haven't been moved to deployment
agnostic.
----
After this commit, the remaining tests in Serlerless/Stateful directories
will be:
**Dataset Quality Serverless API Integration tests** (under
`x-pack/test_serverless/api_integration/test_suites/observability/dataset_quality_api_integration`):
1. `/data_stream_details.ts` _Only contains a single test which cannot
be moved to DA_
**Dataset Quality Stateful API Integration tests** (under
`x-pack/test/dataset_quality_api_integration/tests`):
1. `/data_streams/data_stream_details.spec.ts` _Only contains a single
test which cannot be moved to DA_
2. `/data_streams/degraded_docs.spec.ts` _Only contains a single test
which cannot be moved to DA_
3. `/data_streams/stats.spec.ts` _This suite whole cannot be moved to DA
as it depends on role management_
4. `/integrations/integration_dashboards.spec.ts` _Not moved in this PR_
**Partially addresses:** https://github.com/elastic/kibana/issues/171520
## Summary
This PR adds is built on top of https://github.com/elastic/kibana/pull/193828 and https://github.com/elastic/kibana/pull/196948 and adds an Alert Suppression editable component for Three Way Diff tab's final edit side of the upgrade prebuilt rule workflow.
## Details
https://github.com/elastic/kibana/issues/171520 required adding editable components for each field diffable rule field. Alert Suppression edit component was extracted from Define Rule Step Component into a separate reusable component. To simplify the logic it was split into common Alert Suppression and Threshold Alert Suppression since the latter is a specific use case.
## Caveats
Upgrade prebuilt rules workflow is quite different from rule creation and editing. In create and edit rule forms users are capable to change any field at their will. Upgrade prebuilt rules workflow allow to modify only specific fields having diff in the current rule upgrade.
There are fields which depend on each other. In particular Alert Suppression isn't supported for EQL sequence though it's addressed in https://github.com/elastic/kibana/pull/189725.
- Alert Suppression editable component in Three Way Diff workflow isn't disabled EQL sequence rule queries. Alert suppression support for rules with EQL sequence queries is implemented in https://github.com/elastic/kibana/pull/189725.
- Machine learning rule type require running selected machine learning jobs otherwise input could be disabled in case of there are no fields to pick from otherwise a warning message below the combobox is shown.
## How to test
The simplest way to test is via patching installed prebuilt rules via Rule Patch API. Please follow steps below
- Enable Prebuilt rule customization feature by adding a `prebuiltRulesCustomizationEnabled` feature flag
- Run Kibana locally
- Install a prebuilt rule, e.g. `Potential Code Execution via Postgresql` with rule_id `2a692072-d78d-42f3-a48a-775677d79c4e`
- Patch the installed rule by running a query below
```bash
curl -X PATCH --user elastic:changeme -H 'Content-Type: application/json' -H 'kbn-xsrf: 123' -H "elastic-api-version: 2023-10-31" -d '{"rule_id":"2a692072-d78d-42f3-a48a-775677d79c4e","version":1,"alert_suppression":{"group_by":["host.name"]}}' http://localhost:5601/kbn/api/detection_engine/rules
```
- Open `Detection Rules (SIEM)` Page -> `Rule Updates` -> click on `Potential Code Execution via Postgresql` rule -> expand `EQL Query` to see EQL Query -> press `Edit` button
## Screenshots
Custom query prebuilt rule (UI looks similar for EQL, Indicator Match, New Terms and ES|QL rule types)
Machine learning prebuilt rule with a diff in alert suppression
Threshold prebuilt rule
### Authz API migration for unauthorized routes
This PR migrates unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
### What to do next?
1. Review the changes in this PR.
2. Elaborate on the reasoning to opt-out of authorization.
3. Routes without a compelling reason to opt-out of authorization should
plan to introduce them as soon as possible.
2. You might need to update your tests to reflect the new security
configuration:
- If you have snapshot tests that include the route definition.
## Any questions?
If you have any questions or need help with API authorization, please
reach out to the `@elastic/kibana-security` team.
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani01@gmail.com>
## 📓 Summary
Closes https://github.com/elastic/observability-dev/issues/4070
- Update the deprecation callouts to suggest that the user use Discover.
- Replace the beta badge in Logs Explorer with a deprecation notice.
- Mark the advanced setting to enable the log stream to be deprecated.
<img width="844" alt="Screenshot 2024-11-11 at 15 22 51"
src="https://github.com/user-attachments/assets/5f8a4858-cad5-4d75-9868-d1c9d54a9ce5">
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: Mike Birnstiehl <114418652+mdbirnstiehl@users.noreply.github.com>
### Summary
Closes https://github.com/elastic/kibana/issues/198970
Part of https://github.com/elastic/kibana/issues/193245
This PR contains the changes to migrate error_rate test folder to
Deployment-agnostic testing strategy.
#### How to test
Serverless
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts --grep="APM"
```
It's recommended to be run against
[MKI](https://github.com/crespocarlos/kibana/blob/main/x-pack/test_serverless/README.md#run-tests-on-mki)
Stateful
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts --grep="APM"
```
Checks
- [ ] (OPTIONAL, only if a test has been unskipped) Run flaky test suite
- [x] local run for serverless
- [x] local run for stateful
- [x] MKI run for serverless
### Authz API migration for unauthorized routes
This PR migrates unauthorized routes owned by your team to a new
security configuration.
Please refer to the documentation for more information: [Authorization
API](https://docs.elastic.dev/kibana-dev-docs/key-concepts/security-api-authorization)
### **Before migration:**
```ts
router.get({
path: '/api/path',
...
}, handler);
```
### **After migration:**
```ts
router.get({
path: '/api/path',
security: {
authz: {
enabled: false,
reason: 'This route is opted out from authorization because ...',
},
},
...
}, handler);
```
### What to do next?
1. Review the changes in this PR.
2. Elaborate on the reasoning to opt-out of authorization.
3. Routes without a compelling reason to opt-out of authorization should
plan to introduce them as soon as possible.
2. You might need to update your tests to reflect the new security
configuration:
- If you have snapshot tests that include the route definition.
## Any questions?
If you have any questions or need help with API authorization, please
reach out to the `@elastic/kibana-security` team.
Co-authored-by: Jean-Louis Leysens <jeanlouis.leysens@elastic.co>
Fixes#181876
## Summary
This PR fixes the custom equation label on the preview lens chart.
|With label|Without label|With group by field|
|---|---|---|
||
## Summary
Partially addresses https://github.com/elastic/kibana/issues/191812
This PR implement higher-level convenience methods for working with
`STATS` commands:
- `commands.stats.list()` - iterates over all `STATS` commands.
- `commands.stats.byIndex()` - retrieves the Nth `STATS` command.
- `commands.stats.summarize()` - returns summary about fields used in
aggregates and grouping for all `STATS` commands in the query.
- `commands.stats.summarizeCommand()` - same as `.summarize()`, but
returns a summary only about the requested command.
Usage:
```ts
const query = EsqlQuery.fromSrc('FROM index | STATS a = max(b)');
const summary = commands.stats.summarize(query); // [ { aggregates: { a: { fields: ['b'] }} ]
```
### 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)
## 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
Closes [#198959](https://github.com/elastic/kibana/issues/198959)
Part of https://github.com/elastic/kibana/issues/193245
This PR contains the changes to migrate `alerts` test folder to
Deployment-agnostic testing strategy.
It also fixes a bug when filtering alerts by
`kibana.alert.rule.producer`. On serverless ,the producer is
`observability`, not `apm`
### How to test
- Serverless
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts --grep="APM"
```
It's recommended to be run against
[MKI](https://github.com/crespocarlos/kibana/blob/main/x-pack/test_serverless/README.md#run-tests-on-mki)
- This PR won't pass on MKI while the instance is not created using the
`kibana.alert.rule.producer` fix from this PR
- Stateful
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts --grep="APM"
```
---------
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/198965
Part of https://github.com/elastic/kibana/issues/193245
This PR contains the changes to migrate `data_view` test folder to
Deployment-agnostic testing strategy.
### How to test
- Serverless
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/serverless/oblt.serverless.config.ts --grep="APM"
```
It's recommended to be run against
[MKI](https://github.com/crespocarlos/kibana/blob/main/x-pack/test_serverless/README.md#run-tests-on-mki)
- Stateful
```
node scripts/functional_tests_server --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts
node scripts/functional_test_runner --config x-pack/test/api_integration/deployment_agnostic/configs/stateful/oblt.stateful.config.ts --grep="APM"
```
## Checks
- [x] (OPTIONAL, only if a test has been unskipped) Run flaky test suite
- [x] local run for serverless
- [x] local run for stateful
- [x] MKI run for serverless
**Partially addresses: https://github.com/elastic/kibana/issues/171520**
**Is a follow-up to: https://github.com/elastic/kibana/pull/196326**
This PR enables editing of common fields in the new "Updates" tab of the rule upgrade flyout. The common fields are fields applicable to all rule types.
## Summary
These fields are editable now:
- `building_block`
- `description`
- `false_positives`
- `investigation_fields`
- `max_signals`
- `note`
- `references`
- `related_integrations`
- `required_fields`
- `risk_score`
- `risk_score_mapping`
- `rule_name_override`
- `rule_schedule`
- `setup`
- `severity`
- `severity_mapping`
- `tags`
- `threat`
- `timeline_template`
- `timestamp_override`
<img width="2672" alt="Schermafbeelding 2024-10-16 om 17 32 06" src="https://github.com/user-attachments/assets/6dd615e2-6e84-4e1f-b674-f42d03f575e7">
### Testing
- Ensure the `prebuiltRulesCustomizationEnabled` feature flag is enabled.
- To simulate the availability of prebuilt rule upgrades, downgrade a currently installed prebuilt rule using the `PATCH api/detection_engine/rules` API.
- Set `version: 1` in the request body to downgrade it to version 1.
- Modify other rule fields in the request body as needed to test the changes.
Fixes https://github.com/elastic/kibana/issues/196696
When adding a semantic text field, we now have an additional step in the
file uploading process which calls inference for the selected inference
endpoint.
The response of the inference call is ignored and a poll is started to
check to see of the model has been deployed by check to see if
`num_allocations > 0`
Any errors returned from the inference call will stop the upload, unless
they are timeout errors which are ignored.
https://github.com/user-attachments/assets/382ce565-3b4b-47a3-a081-d79c15aa462f
## Summary
This PR closes this issue:
https://github.com/elastic/kibana/issues/197623
Now we don't close the Popover content when clicking in any of the
options listed in order to keep this content visible. And to solve the
z-index issue where the Popover were displayed on top of the Flyout we
are modifying the Flyout z-index to become exactly the same as the
Popover + 1 to overlap this content.
Now we keep the same tab index focus we got before opening the Flyout
from the Popover options.
