# Backport
This will backport the following commits from `main` to `8.10`:
- [Fix osquery cypress tests
(#163988)](https://github.com/elastic/kibana/pull/163988)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Patryk
Kopyciński","email":"contact@patrykkopycinski.com"},"sourceCommit":{"committedDate":"2023-08-16T22:11:05Z","message":"Fix
osquery cypress tests (#163988)\n\n## Summary\r\n\r\nAdjust tests to
https://github.com/elastic/kibana/pull/161614\r\nSplit tests into
smaller files to better utilize parallelization and\r\nincrease the
stability of
tests","sha":"fd33ed55fd9bc81d006ca41c85b7bd4117741e80","branchLabelMapping":{"^v8.10.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","backport:prev-minor","v8.10.0","v8.11.0"],"number":163988,"url":"https://github.com/elastic/kibana/pull/163988","mergeCommit":{"message":"Fix
osquery cypress tests (#163988)\n\n## Summary\r\n\r\nAdjust tests to
https://github.com/elastic/kibana/pull/161614\r\nSplit tests into
smaller files to better utilize parallelization and\r\nincrease the
stability of
tests","sha":"fd33ed55fd9bc81d006ca41c85b7bd4117741e80"}},"sourceBranch":"main","suggestedTargetBranches":["8.11"],"targetPullRequestStates":[{"branch":"main","label":"v8.10.0","labelRegex":"^v8.10.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/163988","number":163988,"mergeCommit":{"message":"Fix
osquery cypress tests (#163988)\n\n## Summary\r\n\r\nAdjust tests to
https://github.com/elastic/kibana/pull/161614\r\nSplit tests into
smaller files to better utilize parallelization and\r\nincrease the
stability of
tests","sha":"fd33ed55fd9bc81d006ca41c85b7bd4117741e80"}},{"branch":"8.11","label":"v8.11.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
Co-authored-by: Patryk Kopyciński <contact@patrykkopycinski.com>
# Backport
This will backport the following commits from `main` to `8.10`:
- [[Lens] add performance journey to track rendering time for XY
visualization and suggestions panel
(#163412)](https://github.com/elastic/kibana/pull/163412)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Dzmitry
Lemechko","email":"dzmitry.lemechko@elastic.co"},"sourceCommit":{"committedDate":"2023-08-17T10:01:03Z","message":"[Lens]
add performance journey to track rendering time for XY visualization and
suggestions panel (#163412)\n\n## Summary\r\n\r\nRelated to
#163089\r\n\r\nAdding the first performance journey for the Lens Editor.
It simulated\r\nloading existing Lens visualisation with data view
having 10k fields.\r\n\r\nWe collect the following metrics:\r\n-
`fetchFieldsExistenceInfo` reports time it takes to fetch fields
in\r\nData Panel\r\n- `lensVisualizationRenderTime` reports both time it
takes to fetch the\r\ndata (`time_to_data`) and render the main
visualization\r\n(`time_to_render`)\r\n- `lensSuggestionsRenderTime`
reports time it takes to render\r\nsuggestions panel\r\n\r\nMetrics
consistency\r\n\r\n<img width=\"568\"
alt=\"image\"\r\nsrc=\"3384bb8e-6152-4bae-93dc-4f7f4167ed07\">\r\n\r\nRun
locally with \r\n```\r\nnode scripts/functional_tests --config
x-pack/performance/journeys/many_fields_lens_editor.ts\r\n```\r\n\r\nMetrics
will be available here
\r\n\r\ndd0473ac-826f-5621-9a10-25319700326e?_g=h@61c5ac8\r\n\r\n---------\r\n\r\nCo-authored-by:
Drew Tate
<drewctate@gmail.com>","sha":"15b118c724d174d1482ae9a31f9e87dccfe2a66c","branchLabelMapping":{"^v8.10.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["performance","release_note:skip","v8.10.0","v8.11.0"],"number":163412,"url":"https://github.com/elastic/kibana/pull/163412","mergeCommit":{"message":"[Lens]
add performance journey to track rendering time for XY visualization and
suggestions panel (#163412)\n\n## Summary\r\n\r\nRelated to
#163089\r\n\r\nAdding the first performance journey for the Lens Editor.
It simulated\r\nloading existing Lens visualisation with data view
having 10k fields.\r\n\r\nWe collect the following metrics:\r\n-
`fetchFieldsExistenceInfo` reports time it takes to fetch fields
in\r\nData Panel\r\n- `lensVisualizationRenderTime` reports both time it
takes to fetch the\r\ndata (`time_to_data`) and render the main
visualization\r\n(`time_to_render`)\r\n- `lensSuggestionsRenderTime`
reports time it takes to render\r\nsuggestions panel\r\n\r\nMetrics
consistency\r\n\r\n<img width=\"568\"
alt=\"image\"\r\nsrc=\"3384bb8e-6152-4bae-93dc-4f7f4167ed07\">\r\n\r\nRun
locally with \r\n```\r\nnode scripts/functional_tests --config
x-pack/performance/journeys/many_fields_lens_editor.ts\r\n```\r\n\r\nMetrics
will be available here
\r\n\r\ndd0473ac-826f-5621-9a10-25319700326e?_g=h@61c5ac8\r\n\r\n---------\r\n\r\nCo-authored-by:
Drew Tate
<drewctate@gmail.com>","sha":"15b118c724d174d1482ae9a31f9e87dccfe2a66c"}},"sourceBranch":"main","suggestedTargetBranches":["8.11"],"targetPullRequestStates":[{"branch":"main","label":"v8.10.0","labelRegex":"^v8.10.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/163412","number":163412,"mergeCommit":{"message":"[Lens]
add performance journey to track rendering time for XY visualization and
suggestions panel (#163412)\n\n## Summary\r\n\r\nRelated to
#163089\r\n\r\nAdding the first performance journey for the Lens Editor.
It simulated\r\nloading existing Lens visualisation with data view
having 10k fields.\r\n\r\nWe collect the following metrics:\r\n-
`fetchFieldsExistenceInfo` reports time it takes to fetch fields
in\r\nData Panel\r\n- `lensVisualizationRenderTime` reports both time it
takes to fetch the\r\ndata (`time_to_data`) and render the main
visualization\r\n(`time_to_render`)\r\n- `lensSuggestionsRenderTime`
reports time it takes to render\r\nsuggestions panel\r\n\r\nMetrics
consistency\r\n\r\n<img width=\"568\"
alt=\"image\"\r\nsrc=\"3384bb8e-6152-4bae-93dc-4f7f4167ed07\">\r\n\r\nRun
locally with \r\n```\r\nnode scripts/functional_tests --config
x-pack/performance/journeys/many_fields_lens_editor.ts\r\n```\r\n\r\nMetrics
will be available here
\r\n\r\ndd0473ac-826f-5621-9a10-25319700326e?_g=h@61c5ac8\r\n\r\n---------\r\n\r\nCo-authored-by:
Drew Tate
<drewctate@gmail.com>","sha":"15b118c724d174d1482ae9a31f9e87dccfe2a66c"}},{"branch":"8.11","label":"v8.11.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
Co-authored-by: Dzmitry Lemechko <dzmitry.lemechko@elastic.co>
## Summary
This PR adds a dev feature flag
`xpack.index_management.dev.enableIndexDetailsPage` that will allow us
to build out the new index details page in small iterations. Without the
flag, the UI of Index Management is not changed. A skeleton component is
created for the details page (see screenshot below).
### How to test
1. Test the Index Management UI (Indices tab) without the flag and check
that no changes were introduced
1. Add `xpack.index_management.dev.enableIndexDetailsPage: true` to the
file `/config/kibana.dev.yml`
2. Navigate to the Indices tab in Index Management, toggle "hidden
indices" if no indices exist and click any index name
3. Check that the new index details page is displayed
4. Check that the tabs on the page are working
### Screenshots
<img width="1209" alt="Screenshot 2023-08-09 at 19 17 46"
src="e654ef36-ccf3-40a4-8c7b-750b83defef5">
### Checklist
Delete any items that are not applicable to this PR.
- [ ] 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)
- [ ]
[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
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] 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))
- [ ] 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 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))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### 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>
Previously the `ci:build-serverless-image` label was hooked into the
default `Build distribution` step, which only builds the x64 linux
distribution. This limited build is in support of starting functional
tests as quickly as possible.
In order to support ARM artifacts, this starts a non-blocking parallel
build that cross compiles.
There's tradeoffs to this approach. CI time will be kept near our hour
target, at the cost of building x64 artifacts twice. Adding cross
compilation to the primary build step will extend CI time by ~30
minutes.
## Summary
Inspired by https://glebbahmutov.com/blog/burning-tests/
Implements the idea presented here
https://glebbahmutov.com/blog/burning-tests/#bonus-3-burning-new-or-changed-specs
In short, on PR that is changing/adding new Cypress spec files we will
try to "burn" them, it means we will try to run each `it` `2` times to
make sure tests are written in a way that gives Cypress a chance to
recover from the failed test.
Also adding a command that allows to "burn" tests locally
```
yarn cypress:burn --spec "<>"
```
Right now the job is set to `soft_fail`, so it is not going to block the
PR from merging, but hopefully will help the Team to recognize potential
flakiness before it is merged to `main`
## Summary
Create a new functional config file that sets up elasticsearch configs
to have a low disk threshold and a low number of shards per node to test
for health checks and deprecations.
Previously this test failed because it seems that ES takes some time to
calculate the health checks hence the indicator critical issues are not
showing during the testing period (now we don't have flakiness since we
started the server with the indicators already in place) it also means
less `before` and `after` work inside the test cases.
Closes https://github.com/elastic/kibana/issues/160833
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Added pipeline entrypoint for security quality gate.
Only a script is added in order to use it as the entrypoint to build on
the serverless security quality gate.
### Checklist
Delete any items that are not applicable to this PR.
- [ ] 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)
- [ ]
[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
- [ ] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [ ] 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))
- [ ] 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 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))
- [ ] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
### Risk Matrix
Delete this section if it is not applicable to this PR.
Before closing this PR, invite QA, stakeholders, and other developers to
identify risks that should be tested prior to the change/feature
release.
When forming the risk matrix, consider some of the following examples
and how they may potentially impact the change:
| Risk | Probability | Severity | Mitigation/Notes |
|---------------------------|-------------|----------|-------------------------|
| Multiple Spaces—unexpected behavior in non-default Kibana Space.
| Low | High | Integration tests will verify that all features are still
supported in non-default Kibana Space and when user switches between
spaces. |
| Multiple nodes—Elasticsearch polling might have race conditions
when multiple Kibana nodes are polling for the same tasks. | High | Low
| Tasks are idempotent, so executing them multiple times will not result
in logical error, but will degrade performance. To test for this case we
add plenty of unit tests around this logic and document manual testing
procedure. |
| Code should gracefully handle cases when feature X or plugin Y are
disabled. | Medium | High | Unit tests will verify that any feature flag
or plugin combination still results in our service operational. |
| [See more potential risk
examples](https://github.com/elastic/kibana/blob/main/RISK_MATRIX.mdx) |
### 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: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Closes https://github.com/elastic/kibana/issues/162756
This PR fixes a problem introduced after the merge of
https://github.com/elastic/kibana/pull/160289
Looks like the behaviour of node regarding the use of the `FORCE_COLOR`
flag is now propagated differently when cashing the output of a given
node interpreter run in a bash variable which was affecting the script
and making it to fail when casting a number string to a number.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes - https://github.com/elastic/kibana/issues/153844
As part of this PR, as its just the stepping stone, we will only cover a
basic navigation flow and analyze the result obtained from Steps
Dashboard and data collected by the APM Agents for this journey
## Scope
- Generating a data set using Synthtrace instead of Archives
- Capturing the flow from Service Inventory to Trace Waterfall loading
on Transaction page
- Capturing Event loop utilisation metrics enabled for APM Journey
## How to run it
```
node scripts/run_performance.js --journey-path x-pack/performance/journeys/apm_service_inventory.ts --skip-warmup
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR makes the following changes:
- Update look & feel of contextual insights (previously called prompts)
according to the new design that is being developed. Some things might
still change, but hopefully not too much.
- Move all the Observability AI Assistant (previously called CoPilot)
code into a separate plugin for better isolation, more specific code
ownership and to solve some circular dependency issues
- Use connectors instead of a kibana.yml setting
Note: for OpenAI, the model is currently hardcoded to `gpt-4` until
https://github.com/elastic/kibana/issues/162204 has been addressed.
557676b6-065a-4b6f-86b2-1f0c2fd5e07e
---------
Co-authored-by: Coen Warmer <coen.warmer@gmail.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Lately the build storybooks ci step is getting closer to 60 minutes
running time. For now, instead of splitting the job into multiple ones,
I think we can go with a bigger machine.
## Summary
- Implement test plan as described in
`x-pack/plugins/security_solution/docs/testing/test_plans/detection_response/prebuilt_rules/installation_and_upgrade.md`
### 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
We received an alert on GPCTL that a kibana commit (9509425349) did
not exist, because it was being parsed as e4 (scientific representation)
which is not what we want 😅
So, in this PR i am making sure the hash is not being parsed in any
funny way.
Relevant slack thread:
https://elastic.slack.com/archives/C03PAKL2KLK/p1689264633036939
Adding the label `ci:build-serverless-image` will build and push the
serverless image to our registry. The url will be available as an
annotation at the top of Buildkite
Closes https://github.com/elastic/kibana/issues/161562
## Summary
Run Real Endpoint Cypress E2E on CI using Vagrant
---------
Co-authored-by: Tomasz Ciecierski <ciecierskitomek@gmail.com>
Co-authored-by: Ashokaditya <am.struktr@gmail.com>
Created a separated PR in order setup a basic setup for cypress and test
https://github.com/elastic/kibana/pull/160620 for serverless.
Basic setup to run cypress for serverless-oblt
#### How to run it
from
`x-pack/test_serverless/functional/test_suites/observability/cypress`
```
yarn cypress:serverless:open
```
Reverts elastic/kibana#160900 to re-enable the pipeline that updates the
version on the single tenant service, we have checked everything, no
dying pods anymore, since we have changed the functionality to avoid
cloning kibana 😬
This PR changes how Alert Page Filter Controls Work.
## Before
1. Filter Controls use to ignore invalid Selections. For example, if
User has selected `Open` as the filter, but there is actually no alert
with Status `Open`, filters would ignore that selection and would
proceed to show other alerts ( which are NOT `Open`) .
- It seemed it was confusing users. [This
bug](https://github.com/elastic/kibana/issues/159606) and [messages in
community
slack](https://elasticstack.slack.com/archives/CNRTGB9A4/p1686937708085629?thread_ts=1686841414.978319&cid=CNRTGB9A4)
are the examples. @paulewing also emphasized this.
- Below video shows what I mean.
01771587-e4e8-4331-9535-4ffa09877c02
## After
1. With this Change Control Filters no longer ignore invalid selection.
So if user has chosen to show only `Open` Alerts. Then that filter will
be taken into account even though no alert with `Open` exists and a
empty table will be show.
- Here is a video to demonstrate it.
62b17762-16c0-471f-8480-e9f46e2ca5ef
## Summary
This PR removes standalone `common` serverless tests and instead makes
them run as part of every serverless project's tests.
### Details
Before, the `common` tests ran on a "vanilla" Kibana serverless mode
(i.e. the `serverless` plugin was loaded but none of the
`serverless-PROJECT` plugins). With continued serverless development,
this state of Kibana doesn't work as expected anymore and since this is
not supported officially anyway, it's not worth to invest making it work
properly. So we decided to accept the extra test run time and actually
include `common` tests in every project.
Reverts elastic/kibana#160508 gpctl clones the repo to verify the
commit, but since cloning kibana is not trivial, ill revert for now,
until we find a better way to handle the above on gpctl.
## Summary
This PR enables gpctl for kibana with the config definition on
serverless gitops:
https://github.com/elastic/serverless-gitops/blob/main/gen/gpctl/kibana/config.yaml
This will enable treating kibana as a service and not as a stack
component, but this will only happen on dev and only after merging:
https://github.com/elastic/serverless-gitops/pull/306
So practically for now nothing else changes. We just need the extra step
to onboard the new worfklow. Another PR will succeed this one after
verifying that everything works as expected, that will remove the
existing (legacy) step that is using a bash script instead of gpctl for
QA and Staging.
## Summary
Splitting `test/functional/apps/dashboard/group2/config.ts` as it
getting close to 35 minutes and quite often run on its own on CI worker.
<img width="1713" alt="image"
src="ac7f5dc6-2a12-4057-af98-81ff53bac1c4">`
This PR splits config into 2 almost run time equal groups:
- test/functional/apps/dashboard/group2/config.ts 18m 31s
- test/functional/apps/dashboard/group6/config.ts 16m 53s
Flaky-test-runner for both configs:
https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/2522
## 📓 Summary
Closes https://github.com/elastic/observability-dev/issues/2655
This PR introduces a customized log consumption experience in the
Discover plugin. By leveraging the new `discover_log_explorer` plugin
and utilizing the `discover.customize` functionality, we have curated a
more tailored user experience.
The key feature of this implementation is the `DatasetSelector`
component, which replaces the original Discover `DataViewPicker`. It
handles the retrieval, rendering, and navigation of integrations and
data streams related to logs, providing an improved user interface.
This PR involves significant development efforts, including the creation
of the `discover_log_explorer` plugin, implementation of services, state
machines, custom hooks, and enhancements to presentational components.
The following overview will help reviewers understand the
responsibilities of each component in this implementation.
d725b699-452e-4718-8189-8dc1fab4d044
## DatasetsService & DatasetsClient
The DatasetsService is introduced, a crucial component that mediates
access to the newly implemented DatasetsClient. During the plugin's
lifecycle, the DatasetsService exposes a client property through its
start() method, providing convenient access to a DatasetsClient
instance.
The DatasetsClient is responsible for abstracting the data fetching
process for two endpoints: the integrations endpoint and the data
streams listing endpoint. These endpoints are utilized to populate the
selector options in the user interface. To facilitate this, the
DatasetsClient exposes the findIntegrations and findDatasets methods,
which handle the respective data fetching.
## Discover Customization
The critical part of this work consists of where the customization is
applied.
Inside the `public/plugin.tsx`, we lazy load and create, injecting the
required dependencies, the `CustomDatasetSelector`, which already
encapsulates all the logic required to make the selector work with the
external APIs.
We kept separating the data fetching logic from how the selector works,
and all the data and events are passed into the UI component with
properties.
```ts
discover.customize(
DISCOVER_LOG_EXPLORER_PROFILE_ID,
({ customizations, stateContainer }) => {
customizations.set({
id: 'search_bar',
CustomDataViewPicker: createLazyCustomDatasetSelector({
datasetsClient: datasetsService.client,
stateContainer,
}),
});
...
```
## Data fetching state machines & custom hooks
To handle the data fetching of integrations and unmanaged data streams,
we created two different state machines to separately handle the related
action for each dataset, such as remote search, in-memory search, error
handling etc.
### Integration machine and useIntegrations
The integrations state machine handles automatic data fetching of the
resources and additionally provides transitions for loading more
integrations, searching integrations by HTTP request, searching locally
into integration streams, and all the related loading and error handling
states.
It is then interpreted inside the `useIntegrations` custom hook, which
exposes the fetched data and handlers for all the above-mentioned
actions.
<img width="1975" alt="Screenshot 2023-05-30 at 09 44 42"
src="6daeca9f-826d-4a0f-bd90-eb4826ed1bde">
### Datasets machine and useDatasets
Similar to the integrations state machine, but simplified since the data
streams search can only happen with HTTP requests and there is no
pagination that requires to handle the load of more entries.
It is interpreted inside the `useDatasets` custom hook, which also
exposes the fetched data and handlers for the available actions.
<img width="1692" alt="Screenshot 2023-05-30 at 09 45 11"
src="5f9690e2-4e8f-439e-9ffd-f3b34cf3eaf5">
## DatasetSelector
The `DatasetSelector` component contains all the logic that manages the
navigation and searches across the different panels that render
integrations, integrations' streams or unmanaged streams.
As the datasets come from different APIs or are performed in-memory, the
search work follow this logic:
- When listing the integrations list (first level of the
`EuiContextMenu`), the search is done with an HTTP request.
- When listing the data streams list for a specific integration (second
level of the `EuiContextMenu`), the search is done in-memory, filtering
and sorting directly in the client.
- When listing the unmanaged data streams list (second level of the
`EuiContextMenu`), the search is done again with an HTTP request.
To handle these possible user journeys correctly without side effects,
we created another state machine and exposed its actions with an
internal `useDatasetSelector` custom hook.
<img width="1978" alt="Screenshot 2023-05-30 at 09 46 04"
src="84aa4247-c65d-40de-9eb6-6117bee731f8">
## Next steps
This component will change quite a lot until we won't get to a final
design. As soon as a first solid mvp is defined for production, a
complete test for the component will be implemented, among with a more
generic functional test for the core customization features.
---------
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Stratoula Kalafateli <efstratia.kalafateli@elastic.co>
Co-authored-by: Felix Stürmer <weltenwort@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/160385
Use the internal client instead of the scoped one for the extended stats
ES requests to avoid an error with unauthenticated users (when anonymous
access is allowed)
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Relates to https://github.com/elastic/kibana/issues/159451.
This PR adds api integration tests to:
- [x] GET /internal/observability_onboarding/custom_logs/privileges
- [x] GET
/internal/observability_onboarding/custom_logs/install_shipper_setup
- [x] POST /internal/observability_onboarding/custom_logs/save
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
As part of the actions for making Profiling production ready, this PR
adds basic API tests on the Profiling APIs checking if only users with
`access:profiling` are allowed to call our APIs, other users must be
forbidden.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Context: https://elastic.slack.com/archives/C0D8P2XK5/p1687424169737829
The flaky test runner was displaying incorrect name on the tasks on
Buildkite.
The reason was a partial match (cypress/security_solution_investigations
"includes" `security_solution`), now changed to a full match on the
keys.
## Summary
Update Osquery tests to changes done in
https://github.com/elastic/kibana/pull/159733
Add Osquery Cypress to `on_merge_unsupported_ftrs.yml` to get
notifications once tests are failing
---------
Co-authored-by: Tomasz Ciecierski <ciecierskitomek@gmail.com>
Co-authored-by: Tomasz Ciecierski <tomasz.ciecierski@elastic.co>
## Summary
Fix https://github.com/elastic/kibana/issues/158910
Changes the behavior of the `/api/status` endpoint to always returns a
consistent http status code, and in particular:
- during the preboot stage
- when accessed by unauthenticated users and `status.allowAnonymous` is
`false`.
That way, `/api/status` can properly be used for readiness checks.
Please refer to https://github.com/elastic/kibana/issues/158910 for more
details.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
[This PR copies off of this one which adds a config for Investigations,
but instead adds one for
Explore.](https://github.com/elastic/kibana/pull/158236)
In this PR following this issue:
https://github.com/elastic/kibana/issues/153661 we are creating a
Cypress execution just for the `Explore` team. That would help the teams
to improve their ownership of the tests.
- This PR moves one Explore test to the new directory. We plan to move
them all in a follow up PR.
- We are updating the codeowners file to reflect this new change.
- We are creating a new script that runs just the explore team.
- We are doing all the necessary changes to have all the tests inside
the new explore folder executed on the CI
- We are adding this new execution to the unsupported ftrs execution
### 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>
