Consolidate time handling by:
- making sure the useTimefilter hook exposed from the data plugin
materializes both absolute and relative time ranges on a time range
update, and a refresh
- signal the type of refresh: no refresh (ie, date range change),
time-shift (refresh pressed, but for a materialized time range that is
different than the previous one), override (refresh on an absolute time
range)
- expose TimeState - the original time range, the absolute version of
it, and start/end epoch ms
- use global time ranges in Streams where possible
- move time refresh logic into `useStreamsAppFetch` (opt-in)
---------
Co-authored-by: Joe Reuter <email@johannes-reuter.de>
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
This PR prepares the changes needed for removing 8.x branch and create
8.19.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[react-reverse-portal](https://redirect.github.com/httptoolkit/react-reverse-portal)
| dependencies | minor | [`^2.2.0` ->
`^2.3.0`](https://renovatebot.com/diffs/npm/react-reverse-portal/2.2.0/2.3.0)
|
---
### Release Notes
<details>
<summary>httptoolkit/react-reverse-portal
(react-reverse-portal)</summary>
###
[`v2.3.0`](https://redirect.github.com/httptoolkit/react-reverse-portal/compare/v2.2.0...v2.3.0)
[Compare
Source](https://redirect.github.com/httptoolkit/react-reverse-portal/compare/v2.2.0...v2.3.0)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - At any time (no schedule defined),
Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Renovate
Bot](https://redirect.github.com/renovatebot/renovate).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOS4xMDcuMCIsInVwZGF0ZWRJblZlciI6IjM5LjEwNy4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJUZWFtOkRhdGFEaXNjb3ZlcnkiLCJiYWNrcG9ydDphbGwtb3BlbiIsInJlbGVhc2Vfbm90ZTpza2lwIl19-->
Co-authored-by: elastic-renovate-prod[bot] <174716857+elastic-renovate-prod[bot]@users.noreply.github.com>
## Summary
Resolves: https://github.com/elastic/kibana/issues/187481
* Enhances the integration upgrade callout to give special attention to
breaking changes in the changelog.
* Callout includes a CTA to review breaking changes
* If one breaking change between current and latest version CTA is a
direct link the PR
* If many breaking changes, a flyout is opened listing those breaking
changes
* Includes "I understand" checkbox that must be clicked before upgrade
is allowed
## Summary
This PR updates the handling of ES|QL mode fetches so that they continue
to run in the background when switching tabs, and the tab state is
properly updated when a fetch completes (even if not in the selected
tab).
The main changes include the following:
- Removes the `useEsqlMode` hook entirely and migrates the logic to a
`buildEsqlFetchSubscribe` function that's subscribed to directly in
`DiscoverDataStateContainer`, and tied to the lifetime of the state
container.
- Modifies the `updateTabs` logic to remove the dependency on raw URL
state for persisting/restoring tab state, and instead rely directly on
`DiscoverAppState` and a new internal state `lastPersistedGlobalState`
property. This was done because tab state updates can now happen after
changing tabs, and the raw URL state properties can become out of sync
in that case unless we manually sync them, which would be brittle. It
also removes duplicate state which we no longer need since we can just
update the URL directly from the state when switching to a tab.
- Updates `replaceUrlState` in `DiscoverAppStateContainer` to _not_
update the URL if its associated tab is not selected, and instead just
update the app state directly when unselected, to prevent leaking URL
state updates between tabs.
- Moves `TABS_ENABLED` to the main Discover `constants` file as
suggested in a previous PR review to avoid circular dependencies.
- A couple of small cleanups related to `unsafeCurrentId`.
Part of #216475.
### Checklist
- [ ] Any text added follows [EUI's writing
guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses
sentence case text and includes [i18n
support](https://github.com/elastic/kibana/blob/main/src/platform/packages/shared/kbn-i18n/README.md)
- [ ]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
- [ ] If a plugin configuration key changed, check if it needs to be
allowlisted in the cloud and added to the [docker
list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker)
- [ ] This was checked for breaking HTTP API changes, and any breaking
changes have been approved by the breaking-change committee. The
`release_note:breaking` label should be applied in these situations.
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] The PR description includes the appropriate Release Notes section,
and the correct `release_note:*` label is applied per the
[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
## Summary
Hides security sub-privileges for ai4soc/search_ai_lake tier.
### Reasoning for changes added to `x-pack/packages/security`:
Currently, the feature description of Security feature is tied to the
fact that it has a list of sub-privileges. This is true on ESS and
`essentials/complete` serverless tiers.
With the introduction of the lower `search_ai_lake` tier, security
feature would not have any sub-privileges available and thus it does not
make sense to show that description.
The ideal way to handle this would be to load feature privileges config
settings at the plugin level
(security_solution/security_solution_serverless) and set `description`
to `null | undefined` based on the tier, as currently the feature
privileges settings live in [kibana_features file
(v2_features)](795094d8c6/x-pack/solutions/security/packages/features/src/security/v2_features/kibana_features.ts (L72))
(also another set in v1_features) and the plugins only select a set of
those based on the [feature keys
available](d4a33a2b61/x-pack/solutions/security/plugins/security_solution_serverless/common/pli/pli_config.ts)
on each tier. The refactoring to pass in feature configs at the plugin
level (instead of just feature keys) is not in the scope of the work cut
out for RSA conf.
Thus the other simpler approach in this PR is to allow overriding the
description field on the tier specific config file.
## How to Test
1. While on the Kibana root directory, run ES/Kibana on serverless mode
with:
```bash
yarn es serverless --kill --projectType security --kibanaUrl=http://0.0.0.0:5601
```
and on a new window
```bash
yarn serverless-security --no-base-path
```
Enable the AI for SOC tier, by adding the following to your
`serverless.security.dev.yaml` file:
```json5
xpack.securitySolutionServerless.productTypes:
[
{ product_line: 'ai_soc', product_tier: 'search_ai_lake' },
]
```
2. Once Kibana is up and running login in with the `admin` role using
the role dropdown.
3. Navigate to `app/management/roles/edit`
4. Click on `Assign to space` button and assign a space to that role on
the `Assign role to spaces` flyout.
5. Expand the `Security` category and verify that `Security` feature is
listed in the list of features.
6. Also verify that there is neither an accordion icon beside `Security`
feature nor a description text under it about sub-privileges.
### 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)
- [ ] ...
Closes: #218362
**Description**
When user tabs through content rows on content tab, the information
about saved objects in the content row is announced as "link 1, link2"
which doesn't give any context to non-sighted user.
**Changes made:**
1. Set `aria-label` for mentioned place
# Screen
<img width="1063" alt="image"
src="https://github.com/user-attachments/assets/452885c2-9738-4d17-84c9-3033250c6841"
/>
## Summary
fix https://github.com/elastic/kibana/issues/217589 again
The implementation in https://github.com/elastic/kibana/pull/217599 for
the status table still relied on enzyme indirectly by using
`mountWithI18n`.
This PR refactors the test from implementing the enzyme-reliant helper
to using `renderReactTestingLibraryWithI18n` that doesn't.
## Note to reviewers:
If `renderReactTestingLibraryWithI18n` becomes the standard, renaming it
to something shorter (e.g. `renderWithI18n`) would be nicer. ATM, the
helper's only used in 13 files and it would be better to do so now that
when adoption becomes wide-spread.
The package is owned by `shared-ux` and renaming the function would
require code-reviews from too many teams to justify doing so in this PR.
### Checklist
Check the PR satisfies following conditions.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR adds new config option `defaultSolution`
(`xpack.spaces.defaultSolution`) which lets you specify a default
solution, similar to the way cloud plugin does it.
Addresses: #213144
## Summary
These 2 configs for all solutions take 35-39 minutes:
```
x-pack/test_serverless/functional/test_suites/<solution>/common_configs/config.group5.ts
x-pack/test_serverless/functional/test_suites/<solution>/common_configs/config.group6.ts
```
I added 4 additional groups under each solution and relocated some
configs to split original runtime by ~3:
```
x-pack/test_serverless/functional/test_suites/<solution>/common_configs/config.group9.ts
x-pack/test_serverless/functional/test_suites/<solution>/common_configs/config.group10.ts
x-pack/test_serverless/functional/test_suites/<solution>/common_configs/config.group11.ts
x-pack/test_serverless/functional/test_suites/<solution>/common_configs/config.group12.ts
```
It should help balancing configs better and retry failed ones faster.
After this PR groups runtime
|config path| runtime |
| ------------- | ------------- |
|x-pack/test_serverless/functional/test_suites/security/common_configs/config.group5.ts|
16m 15s |
|x-pack/test_serverless/functional/test_suites/security/common_configs/config.group6.ts|
18m 7s |
|x-pack/test_serverless/functional/test_suites/security/common_configs/config.group9.ts|
12m 7s |
|x-pack/test_serverless/functional/test_suites/security/common_configs/config.group10.ts
| 16m 13s |
|x-pack/test_serverless/functional/test_suites/security/common_configs/config.group11.ts|
14m 3s |
|x-pack/test_serverless/functional/test_suites/security/common_configs/config.group12.ts|
17m 47s |
## Summary
Just had some fun and made fp-ts available in the shared bundle, with
support for partial imports.
Changes in this PR:
* aligned `fp-ts` direct imports to the format: `fp-ts/<module>`
* Mapped the direct imports into the shared bundle re-using the same
`fp-ts` module under the hood
Closes#213943
## Summary
This PR ensures the service name is always encoded in the APM UIs. It's
a follow-up of https://github.com/elastic/kibana/pull/215031 and aims to
find a better solution to the problem:
- Add the encoding directly to `formatRequest` as suggested there
- I saw that there are many places where we use legacy Url builders, so
I will try to replace them where possible and use
apm router link method where the path is encoded
([ref](7158e0201b/src/platform/packages/shared/kbn-typed-react-router-config/src/create_router.ts (L184-L185)))
- The PR includes the changes to address the issue above:
- Replaced and removed `LegacyAPMLink`
- Refactored `useAPMHref` to support encoding (and extracted and test
the encoding logic)
- Example usage:
- Before:
```js
useAPMHref({
path: `/services/${serviceName}/.....`,
persistedFilters,
});
```
- After:
```js
useAPMHref({
path: '/services/{serviceName}/.......}',
pathParams: { serviceName },
persistedFilters,
});
```
- Used the APM router link method as much as possible
## Testing
- Run `node scripts/synthtrace trace_with_service_names_with_slashes.ts
--clean --live --uniqueIds --live`
- Go to service inventory and click the links:
https://github.com/user-attachments/assets/fcd4fbfc-4125-4cc8-9b00-53c5f375423f
## Summary
Redo of https://github.com/elastic/kibana/pull/193471
Closes https://github.com/elastic/security-team/issues/8644
> Fixes a bug where importing a rule fails with a connector into a space
where (1) the connector already exists, and (2) the existing connector
was exported and re-imported from another space. The import logic in
this scenario effectively tries to convert the action ID on the rule
import twice. The second conversion attempt tries to use the old action
ID to look up the correct new action ID in a map, however, in this test
scenario the action ID has already been updated by legacy SO ID
migration logic and there is no map entry with the new ID as a key. The
result is that the second attempt sets the action ID to undefined,
resulting in an import failure.
The root cause of the bug is that we have two different places in the
rule import logic where action IDs are migrated. The first ID migration
was done by `migrateLegacyActionsIds` prior to importing rule actions,
and the second migration was done by `importRuleActionConnectors` after
importing the actions. `importRuleActionConnectors` used a lookup table
to convert old IDs to new IDs, but if the connector already existed and
had an `originId` then the rule action would already be migrated by
`migrateLegacyActionsIds`. The lookup table used by
`importRuleActionConnectors` does not have entries for migrated IDs,
only the original IDs, so in that case the result of the lookup is
`undefined` which we assign to the action ID.
This PR reworks the logic to create a clean separation between action
and rule import. We now import the connectors first, ignoring the rules,
then migrate action IDs on the rules afterwards. This handles connectors
changing IDs in any way, either through the 7.x->8.0 migration long ago
or IDs changing on import if there are ID conflicts. Only after the
connectors are imported and rule actions are migrated do we then verify
if each rule action references a connector ID that actually exists with
the new `checkRuleActions` function, replacing
`checkIfActionsHaveMissingConnectors` and related functions that were
also buggy.
Finally, as a nice side effect this rework removes "rule action
connector missing" errors out of the `action_connector_errors` part of
the response. `action_connector_errors` is reserved for errors importing
connectors specifically. If a rule action is missing a connector and
therefore we don't import the rule, that's a rule error and it's
represented in the `errors` part of the response. Since the shape of the
response is not changing, I don't consider this a breaking change but
rather a bug fix.
## Repro Steps
Repro Steps
1. Download the export file below and change the extension back to
.ndjson from .json (github does not allow .ndjson files
[rules_export.json](https://github.com/user-attachments/files/17065272/rules_export.json)
2. Import the rule and connector into a space (default is fine)
3. Create a new space
4. Import the rule and connector into the new space
5. Import the rule and connector into the new space again, but check the
`Overwrite existing connectors with conflicting action "id"` box.
Observe the failure.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Enables the Trace section for the summary tab in the Traces Doc Viewer.
This PR focuses on just bringing the section with the widget, not for
adjusting the widget styles/look to be closer to the intended designs.
That is for follow-up work.
Closes#217067
## How to test
* Add the following to your `kibana.dev.yml`:
```yaml
discover.experimental.enabledProfiles:
- observability-traces-data-source-profile
- observability-traces-transaction-document-profile
- observability-traces-span-document-profile
```
* Ensure you are on an Observability root profile space
* Go to Discover, use or create a Data View profiles targetting
`traces-*` (such as `remote_cluster:traces-*`).
* Click on a span/transaction to expand the doc viewer
* The trace waterfall section should be present on the summary tab.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This pr fixes a bug with the RouteCapture component, used at a high
level in the security solution component tree, to reflect url changes
into redux. The code previously used the full result of
'react-router-dom' 's useLocation hook as the payload, which contains 4
parameters, pathname, search, hash that we make use of, and a 4th that
was added sometime later by the library that is essentially a random id
generated every time the hook is called, called key. We have never used
this, and it was being inadvertently copied into the redux state, and
also causing some other actions or hooks based listeners to run I think
as well.
Below is the contrived example of going from the home page to an empty
alerts page, and you can see 4 actions in the after, and 5 in the
before, with 1 updating only the key. May reduce more unneeded actions
with more going on in the page, but exactly how many is not known.
Before:
After:
### 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
## Summary
New event created for the video selectors inside rules, dashboards and
alerts cards.
```
export interface OnboardingHubSelectorCardClickedParams {
originStepId: string;
selectorId: string;
}
```
To verify:
Add these lines to kibana.dev.yml
```
logging.browser.root.level: debug
telemetry.optIn: true
```
1. In the onboarding hub, expand the rules card
2. It should log `Report event "Onboarding Hub Step Selector Clicked"`.
https://github.com/user-attachments/assets/c1b1084e-4917-4412-93ed-984a74b6b6b4
### Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
- [ ] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes: #215112
**Description**
Dialog modal, flyout, field visible title should be announced for the
users, especially using assistive technology to know what dialog modal,
flyout opened, what field is active and what is needed to enter in it.
**Changes made:**
1. Added `aria-labelledby={flyoutTitleId}` for mentioned places
Fixes https://github.com/elastic/kibana/issues/208671
## Summary
Before this PR, the displayed index mode of the data streams was
determined based on the index mode of the associated index template.
However, the index mode can also be set through the component template,
so that logic is not reliable and can cause incorrectly displayed index
mode like described in https://github.com/elastic/kibana/issues/208671.
In this PR, we replace this logic with the recently added `index_mode`
field to the Es Get Data Streams API (see
https://github.com/elastic/elasticsearch/pull/122486).
**How to test:**
1. Create a component template with a LogsDB index mode (you can also
test with other index modes):
```
PUT _component_template/my-component-template
{
"template": {
"settings": {
"index": {
"mode": "logsdb"
}
}
}
}
```
2. Create an index template that is composed of the component template
above:
```
PUT _index_template/my-index-template
{
"index_patterns": [
"my-ds-*"
],
"data_stream": {},
"composed_of": [
"my-component-template"
]
}
```
3. Create a data stream that matched the index pattern from the index
template above:
```
PUT _data_stream/my-ds-1
```
4. Go to the data streams table and verify that the index mode is
displayed correctly in the table.
<img width="1165" alt="Screenshot 2025-03-24 at 18 12 04"
src="https://github.com/user-attachments/assets/ea211c14-3d03-49c7-ace7-88b15e294d1f"
/>
5. Click on the created data stream and verify that the displayed index
mode in the details panel is correct:
<img width="1165" alt="Screenshot 2025-03-06 at 14 36 12"
src="https://github.com/user-attachments/assets/954864e2-ae2a-4cb8-9eef-2c5f8b417f52"
/>
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
## Summary
This PR adds support for disabling experimental features using the
existing `xpack.securitySolution.enableExperimental` configuration.
This solves the problem of not being able to disable a feature by config
once the feature has been enabled by default.
### The Challenge
When we start developing a feature under an experimental flag we always
follow the same steps:
1 - Create the experimental flag disabled by default + enable it via
config for testing
2 - Implement the feature
3 - Enable the experimental flag by default when we want to release the
feature.
4 - Deployments can disable the feature via config (as a safety
measure).
5 - Remove the experimental flag after some time.
We start by creating the flag disabled by default while we implement it.
In `experimental_features.ts`:
```ts
export const allowedExperimentalValues = Object.freeze({
myFeatureEnabled: false,
[...]
```
And enable it via config with:
```yml
xpack.securitySolution.enableExperimental:
- myFeatureEnabled
```
Once the implementation is done and the experimental flag can be enabled
by default, we have to do a trick:
Since the `xpack.securitySolution.enableExperimental` config can only
turn flags to _true_, instead of setting `myFeatureEnabled: true`, what
we have to do is rename the flag to `myFeatureDisabled` and keep the
value as _false_:
```ts
export const allowedExperimentalValues = Object.freeze({
myFeatureDisabled: false,
[...]
```
Then we also need to do a code refactor to update all the places in the
code where the flag was checked: `if (myFeatureEnabled)` -> `if
(!myFeatureDisabled)`
This way, we have the option of disabling the feature via config (in
case something goes wrong):
```yml
xpack.securitySolution.enableExperimental:
- myFeatureDisabled
```
### A solution
This PR introduces the possibility to turn a flag to _false_ using the
same `xpack.securitySolution.enableExperimental` config. This was
preferable to introducing a new config since this one is already
whitelisted in Cloud UI, can be easily overritten in deployments, and
also because people are used to it.
With these changes, the first two steps would be the same, with the
difference that we won't need to have the _Enabled_ or _Disabled_ word
at the end of the flag name. It could be just the feature name, in
`experimental_features.ts`:
```ts
export const allowedExperimentalValues = Object.freeze({
myFeature: false,
[...]
```
And when we need to enable the feature by default, we can just turn it
to `true`:
```ts
export const allowedExperimentalValues = Object.freeze({
myFeature: true,
[...]
```
No tedious refactor or confusing naming would be required.
Then, in case we need to disable the feature in a production deployment
for some reason, we could just do this via config :
```yml
xpack.securitySolution.enableExperimental:
- disable:myFeature
```
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Closes: #214760
**Description**
Dialog modal, flyout, field visible title should be announced for the
users, especially using assistive technology to know what dialog modal,
flyout opened, what field is active and what is needed to enter in it.
**Changes made:**
1. Set correct value for` aria-labelledby` attr.
Closes https://github.com/elastic/kibana/issues/208025
This change deleted the "Stream log files" onboarding flow which is now
replaced by the Auto Detect flow.
| Before | After |
| --- | --- |
| 
| 
|
Changes made:
* Deleted UI components responsible for rendering the Custom Logs flow
* Deleted the definition for a custom card in the onboarding search
results
* Deleted API endpoints and supporting files used only by the Custom
Logs flow
* `/internal/observability_onboarding/logs/setup/environment` endpoint
was still used by the OTel Host flow, so it was moved to a dedicated
OTel route and pathname changed to
`/internal/observability_onboarding/otel_host/setup`
* Functionality of the `/internal/observability_onboarding/otel/api_key`
endpoint was merged into the above mentioned OTel route, so UI has to
make a single API request to get all the necessary information from the
server
* Deleted Scout UI tests for the Custom Logs flow
* Deleted API integration tests for the deleted endpoints
* API tests that we previously testing
`/internal/observability_onboarding/logs/flow` were converted to test
`/internal/observability_onboarding/flow'` used by the Auto Detect flow
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR fixes an issue that can cause test execution to fail when `await
kbnClient.status.get()` doesn't return the Kibana version. The fallback
now uses the version from `package.json` in that case.
Example failure:
https://buildkite.com/elastic/kibana-on-merge/builds/66520#0196344e-f27e-4ab8-9bf7-f041b94c665d/268-3998
---------
Co-authored-by: Patryk Kopyciński <contact@patrykkopycinski.com>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
## Summary
Closes https://github.com/elastic/kibana/issues/216398
### Checklist
This test fails because it tests ES 9.0 with kibana 8.19 but this is not
compatible for field controls (ES changed the backend implementation in
8.19 and 9.1)
