## Summary
Address #166459
This PR scaffolds telemetry into the notification service, to enable
reporting when deduped toasts are dismissed. When a deduped toast is
dismissed; the message recurrence count and the toast message would be
emitted.
Telemetry Event Definition;
```typescript
{
eventType: "global_toast_list_toast_dismissed",
schema: {
"toast_deduplication_count": {
type: "long",
_meta: {
description: "toast message text"
}
},
"toast_message": {
type: "keyword",
_meta: {
description: "recurrence count for particular toast message"
}
},
"toast_message_type": {
type: "keyword",
_meta: {
description: "toast message type, accepted values are warning, danger, primary"
}
}
}
}
```
Testing;
- Ensure you have an existing dashboard, if you don't installing any
sample data would bootstrap a dashboard automatically
- Search for `visualize library` from the global search bar, and
navigate to visualize library.
- Attempt to create a visualization, select the `TSVB` visualization
type. At this step there typically wouldn't be an error
- We can simulate an error, by open Dev tools and blocking the URL
`/internal/metrics/vis/data` like so <img width="604" alt="Screenshot
2023-09-21 at 11 49 41"
src="ad320569-33b2-4335-8052-981d1761ea67">
on doing this, we then attempt refreshing the query, we would then be
presented with an error toast, similar to the screenshot below;
<img width="482" alt="Screenshot 2023-09-21 at 11 52 51"
src="fef07e72-625b-4457-abc3-9214d64f9e48">
click the refresh query button as much as you like to increase it's
recurrence count.
- From here on we verify that; clicking the dismiss button sends a
telemetry event, also not interacting with the toast and it's display
lifetime elapsing with the toast clearing itself, the telemetry gets
sent still. In either case there should be a request calling the
resource `kibana_browser` with a payload containing the telemetry event
definition above.
### 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
<!-- - [ ] 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>
Addresses https://github.com/elastic/kibana/issues/160411
## Summary
This PR adds a package that contains a form component for the Advanced
Settings UI in serverless.
This implementation was extracted from the the `Form` component in the
`advancedSettings` plugin, excluding some functionalities:
- The form doesn't support search queries.
- The form doesn't divide the settings into categories.
### Testing
The form can be tested in the Storybook Preview from the CI build. Some
things to be tested:
- Making changes to any of the fields displays the bottom bar.
- Clicking the Cancel button clears the changes.
- Clicking the Save button triggers a `saveChanges` action with the
correct changes.
- The bottom bar correctly shows the number of unsaved settings.
- Toggling the `isSavingEnabled` control to `false` disables all fields.
- Toggling the `requirePageReload` control to `true` causes saving of
changes to any of the fields to trigger a `showReloadPagePrompt` action.
### 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
- [x] Any UI touched in this PR is usable by keyboard only (learn more
about [keyboard accessibility](https://webaim.org/techniques/keyboard/))
- [x] Any UI touched in this PR does not create any new axe failures
(run axe in browser:
[FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/),
[Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US))
- [x] This renders correctly on smaller devices using a responsive
layout. (You can test this [in your
browser](https://www.browserstack.com/guide/responsive-testing-on-local-server))
- [x] This was checked for [cross-browser
compatibility](https://www.elastic.co/support/matrix#matrix_browsers)
<!--
### 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>
Co-authored-by: Clint Andrew Hall <clint@clintandrewhall.com>
## Summary
This PR is the core part of #166813. The original work seems to grow
large, and we'd like to enable a preventive check beforehand to prevent
more errors from entering the codebase.
The idea is to have a selective type check that would only check changed
files' projects.
- [x] when there's no extra label, run the selective type check only on
the diffing files' projects (success:
https://buildkite.com/elastic/kibana-pull-request/builds/161837)
- [x] when the label `ci:hard-typecheck` is present, run the regular
(but now, working) full typecheck (expected to fail: )
cc: @watson
---------
Co-authored-by: Brad White <brad.white@elastic.co>
Co-authored-by: Thomas Watson <w@tson.dk>
Co-authored-by: Thomas Watson <watson@elastic.co>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Fixes a long list of julian's UI bugs. Tested on both stateful and
serverless. See videos on visual fixes.
1a450bf6-7477-40a4-a020-a5172b56ef4c
92b40ecd-d888-4fd6-af91-045e81a1843f
Things to note:
- I had to adjust the asset path here as locally on main the images were
broken (the header for example).
## Summary
Closes https://github.com/elastic/kibana/issues/166874
Hides indices starting with . (and considered as system from the
autocomplete)
<img width="785" alt="image"
src="9c4cce79-c844-41b6-a30e-06dad49f7c52">
Followed the exact pattern that the dataview management page is using.
## Summary
Prepares the serverless FTR tests to be runnable with a custom ES image.
(`--esServerlessImage` cli arg)
Creates a pipeline for testing and promoting ES Serverless docker
releases.
The job can be triggered here:
https://buildkite.com/elastic/kibana-elasticsearch-serverless-verify-and-promote
The three main env variables it takes:
- BUILDKITE_BRANCH: the kibana branch to test with (maybe not as
important)
- BUILDKITE_COMMIT: the kibana commit to test with
- ES_SERVERLESS_IMAGE: the elasticsearch serverless image, or tag to use
from this repo:
`docker.elastic.co/elasticsearch-ci/elasticsearch-serverless`
## TODOS:
- [x] set `latest_verified` with full img path as default
- [x] ~~find other CLIs that might need the `esServerlessImage` argument
(if the docker runner has multiple usages)~~ | I confused the `yarn es
docker` with this, because I thought we only run ES serverless in a
docker container, but `elasticsearch` can also be run in docker.
- [x] set `latest-compatible` or similar flag in a manifest in gcs for
Elastic's use-case
- [ ] ensure we can only verify "forward" (ie.: to avoid a
parameterization on old versions to set our pointers back) [on a second
thought, this might be kept as a feature to roll back (if we should ever
need that)]
There are two confusing things I couldn't sort out just yet:
#### Ambiguity in --esServerlessImage
We can either have 2 CLI args: one for an image tag, one for an image
repo/image url, or we can have one (like I have it now) and interpret
that in the code, it can be either the image url, or the tag. It's more
flexible, but it's two things in one. Is it ok this way, or is it too
confusing?
e.g.:
```
node scripts/functional_tests --esFrom serverless --esServerlessImage docker.elastic.co/elasticsearch-ci/elasticsearch-serverless:git-8fc8f941bd4d --bail --config x-pack/test_serverless/functional/test_suites/security/config.ts
# or
node scripts/functional_tests --esFrom serverless --esServerlessImage latest --bail --config x-pack/test_serverless/functional/test_suites/security/config.ts
```
#### Ambiguity in the default image path
The published ES Serverless images will sit on this image path:
`docker.elastic.co/elasticsearch-ci/elasticsearch-serverless`, however,
our one exception is the `latest-verified` which we will be tagging
under a different path, where we have write rights:
`docker.elastic.co/kibana-ci/elasticsearch-serverless:latest-verified`.
Is it okay, that by default, we're searching in the `elasticsearch-ci`
images for any tags as parameters (after all, all the new images will be
published there), however our grand default will ultimately be
`docker.elastic.co/kibana-ci/elasticsearch-serverless:latest-verified`.
## Links
Buildkite:
https://buildkite.com/elastic/kibana-elasticsearch-serverless-verify-and-promote
eg.:
https://buildkite.com/elastic/kibana-elasticsearch-serverless-verify-and-promote/builds/24
Closes: https://github.com/elastic/kibana/issues/162931
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
This PR removes the Profiling dependency from APM, introduced on `8.10`.
- Exposes a new service in profiling-data-access plugin
- Create a new APM API that calls the new service and checks if
Profiling is initialized
- Move Locators from the Profiling plugin to the Observability-shared
plugin
- Move logic to check Profiling status (has_setup/has_data...) from
Profiling server to profiling-data-access plugin
- Create API tests, testing the status services based on different
scenarios:
- When profiling hasn't been initialized and there's no data
- When profiling is initialized but has no data
- When collector integration is not installed
- When symbolized integration is not installed
- When APM server integration is not found
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR is updating Discover's rule to be created under the
`stackAlerts` consumer and we created an [breaking change
issue](https://github.com/elastic/dev/issues/2344) to explain the
consequences of this update.
We also fix the rule's consumer for all rule types created under the
observability rule management to use their producer instead of `alerts`.
Also, we add the ability for the ES Query and new Generic Threshold
rules type to pick the consumer associated to the rule. The
`ensureAuthorized` and the `filter` functions have modified and
simplified to support this use case please check the newest unit test
added in
`x-pack/plugins/alerting/server/authorization/alerting_authorization.test.ts`.
There is now a dropdown in the rule form to prompt the user when
creating ES Query/Generic threshold rules to select the consumer based
on their authorized consumers (we can no longer use `alerts` for these).
If there is only 1 option, then the dropdown will not be shown and the
option will be chosen automatically.
Generic threshold rules will have the following possible consumers:
- infrastructure
- logs
ES query rules will have the following possible consumers:
- infrastructure
- logs
- stackAlerts (only from the stack management rule page)
## To Test:
### Single Consumer:
1. Create a user with only `logs` feature enabled (ensuring
`stackAlerts` is not enabled).
2. Navigate to the O11Y rule management page
3. Click the create rule button
4. Assert that both ES query and generic threshold rules are available
5. Click ES query and fill out the relevant information and create the
rule
6. Assert that the rule created has `logs` set in the `consumer` field
7. Repeat 5-6 for the generic threshold rule
8. Repeat 2-7 but on the Stack Management rules page
9. Repeat 1-8 for the `infrastructure` feature.
### Multiple Consumers:
1. Create a user with `logs`, `infrastructure` and `apm` features
enabled (ensuring `stackAlerts` is not enabled).
2. Navigate to the O11Y rule management page
3. Click the create rule button
4. Assert that both ES query and generic threshold rules are available
5. Click ES query and fill out the relevant information and create the
rule
6. A dropdown should prompt the user to select between 1 of the 3
consumers, select 1
7. Assert that the rule was created with the selected consumer
8. Repeat 5-7 for the generic threshold rule
9. Repeat 2-8 but on the Stack Management rules page
### 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
---------
Co-authored-by: Jiawei Wu <74562234+JiaweiWu@users.noreply.github.com>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Closes#166580
To avoid confusion, rename any usages of ESS because it has been
established to represent Elastic Cloud and there are situations where ES
serverless and Elastic Cloud can be used within the same context.
## Summary
Closes#166543
- It is counterintuitive to `CTRL + C` from the `yarn es serverless`
process and the cluster is still running. This has caused issues when
switching between stateful and serverless work flows for some
developers. This PR inverts the logic to always teardown the cluster
unless a flag is passed.
- Small docs update for changing ES memory allocation on all operation
systems.
- Fixes bug were cluster status would continue looping after `SIGINT`.
- Bind to `SIGINT` earlier so nodes are always killed
## Summary
Closes#163830
This adds server side validation to enforce dataset name format rules
for custom integrations. It then enhances the custom integrations Kibana
package to handle this seamlessly in the create form.
There is no client side validation for the rules per se because as long
as the dataset name passes other validations (length etc) then it is
always valid - it just comes down to whether it's prefixed or not.
## Other notes
- Added a "fields pipeline" to improve the readability of the context
update.
## UI / UX changes
- Users are informed when a prefix will be added.
<img width="886" alt="Screenshot 2023-09-20 at 13 19 49"
src="764d2bd0-03ef-40ce-8dae-107079c15feb">
- If the integration name has been touched, and the dataset name is
untouched, the dataset name will automatically match the integration
name.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Adds a new `managed` mode to Dashboards. When a user with write permissions opens a managed Dashboard they will be unable to hit the `edit` button - and will instead be prompted to clone the Dashboard first.
**Related to:** https://github.com/elastic/kibana/issues/161540, https://github.com/elastic/kibana/issues/161539
## Summary
Always force the last breadcrumb to be inactive.
## Details
Usual UX expects the last breadcrumb to be inactive as it represents the current page. The same can be seen from EUI [examples](https://eui.elastic.co/#/navigation/breadcrumbs). It turns out Serverless Security Solution plugin does't remove `href` and `onClick` fields from the last breadcrumb and passes it to `chrome.setBreadcrumbs()` or `serverless.setBreadcrumbs()` which renders the last breadcrumb as active but clicking on it only refreshes the page. ESS Security Solution on the other hand processes breadcrumbs currently. The same behavior may be the case for the other plungs as well.
As it's much simpler to strip off undesired fields at one place instead of processing them in plugins it's done in `packages/core/chrome/core-chrome-browser-internal/src/ui/header/header_breadcrumbs.tsx`. Security Solution codebase has been updated accordingly.
A side effect of this PR is consistent ESS and Serverless breadcrumbs behavior and it will help to reuse ESS tests for Serverless.
closes https://github.com/elastic/kibana/issues/164995
closes https://github.com/elastic/kibana/issues/165618
closes https://github.com/elastic/kibana/issues/166596
## 📝 Summary
### Observability Log Explorer Locators:
This PR adds 2 new customized locators to the Observability log explorer
profile. At the moment we implemented:
1- Single dataset selector locator
2- All dataset selector locator
With more locators to come in the future depending on the use cases.
### Log Explorer Locators:
We also added a log explorer locator that navigates to discover, this
can be used in case the **Observability Log Explorer** plugin is
disabled.
### Logs Onboarding:
The PR also replaces the temp navigation to the default discover we
implemented for[ 8.10
here](https://github.com/elastic/kibana/pull/163218) with the above new
Observability Log Explorer locators.
### APM:
After [disabling infra plugin in serverless
projects](https://github.com/elastic/kibana/pull/165289), APM links to
infra locators in serverless have been replaced to use the above
locators.
### Observability Landing Page:
The landing page now redirects to the Log Explorer if `logs-*-*` has
data in it, otherwise the flow continues as before.
### Necessary Refactoring:
To avoid the circular dependency between `ObservabilityLogExplorer` &
`ObservabilityOnboarding` after each one using the other's locator and
importing the necessary types, I moved the type definition for all
locators in the `deeplinks` package.
## ✅ Testing
- Onboarding Wizard in Serverless and Stateful
1. Navigate to the onboarding flow `/app/observabilityOnboarding/`
2. Choose either System logs or Stream log files
3. Go through the onboarding wizard
4. Click the Explore logs button at the end
5. You should be redirected to observability log explorer with the
integration and dataset preselected.
- APM links in Serverless
1. Navigate to APM and click on the logs links as shown in the Demos
below
2. All links should navigate to Observability Log Explorer with the
queries set in the search bar.
## 🎥 Demos
- APM Serverless
7161364e-333f-4ac4-87d5-7f1ffec699b3
- APM Stateful
058c9587-b766-4d4f-a73d-50fd381be4bb
- Onboarding Serverless
ee1cab42-f91c-4558-aa5f-4fa7e8963427
- Onboarding Stateful
a376a12b-499b-4488-a75a-d06e81f8e21d
- Observability Landing Page
c1c084ca-b1b1-4c4b-a4e6-ae8e157dcf57
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani@elastic.co>
Co-authored-by: Marco Antonio Ghiani <marcoantonio.ghiani01@gmail.com>
- Move logic to fetch the TopN functions to
'profiling-data-access-plugin'
- Create new TopN functions embeddable
- Refactor Universal profiling page on APM adding Tabs (Flamegraph | Top
10 functions)
- Create a new API on APM to fetch Top functions
<img width="1605" alt="Screenshot 2023-09-08 at 11 14 13"
src="76fc7bf3-094b-438b-99b8-3cab01539eb4">
<img width="1615" alt="Screenshot 2023-09-08 at 11 14 20"
src="c4d3e97a-eee0-4829-8d6f-545f9c844b18">
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Joseph Crail <joseph.crail@elastic.co>
> **Caveat**: the functional flow logic we've adopted for these
components is not one I would encourage, specifically, using "drilled"
`onChange` handlers and utilizing a composing-component-based store.
Ideally, we'd use a `redux` store, or, at the very least a React
`reducer`.
>
> In the interest of time and compatibility, we've opted to use the
pattern from the original components in `advancedSettings`. We plan to
revisit the state management and prop-drilling when `advancedSettings`
is refactored with these components.
> This PR is a prerequisite to
https://github.com/elastic/kibana/pull/166319 and to completing the
Advanced Settings page in Serverless.
> **Note**: Github appears to be a bit confused in the diff comparison,
due to the addition to `React.forwardRef`... apologies for the noise.
## Summary
While working on https://github.com/elastic/kibana/pull/166319 I found a
number of bugs when working against actual UI settings stored in Kibana.
This PR addresses those issues without waiting for the Settings page to
be complete:
- Refactors `input` components to have cleaner APIs, including
`unsavedChange` and `field` "all the way down".
- This cleans up confusing logic, and sets us up for Redux actions.
- Creates a `normalizeSettings` function.
- Settings returned from the `UiSettingsService` in an actual deployment
of Kibana are drastically unpredictable. In some cases, `type` is
missing, but `value` is there... or `value` is missing entirely, but a
`userValue` is there.
- This function "normalizes" the data, deriving missing parts where
possible.
- Changes the `onChangeFn` to accept `undefined` to indicate an unsaved
change has been reverted, rather than relying on the _value_ in the
unsaved change.
- This fixes a number of issues around resets and reverts.
- Alters the `unsavedChange` prop to be undefined, (to indicate the lack
of an unsaved change), rather than an undefined value.
- Fixes an issue where the `ImageFieldInput` wasn't removing a file that
had been set when resetting to default;
- Adds an imperative ref to `FieldInput` components to reset a field's
input beyond resetting the value, (if necessary).
- Fixes the Storybook `common` setups to allow for changes to the
`onChange` types.
- Fixed a bug where the `FieldRow` was indexing an unsaved change by
`name`, rather than by `id`.
- Fixed an issue where the reset link wasn't always clearing a change to
the default value.
- Fixes an issue with the aria label not being derived properly using
the `query`.
- Splits the utility functions into their respective namespaces:
`settings` and `fields`.
- Adds a few more tests to the utility functions to catch logic errors.
EUI `88.2.0` ➡️ `88.3.0`
## [`88.3.0`](https://github.com/elastic/eui/tree/v88.3.0)
- `EuiGlobalToastList` now shows a "Clear all" button by default once
above a certain number of toasts (defaults to 3). This threshold is
configurable with the `showClearAllButtonAt` prop
([#7111](https://github.com/elastic/eui/pull/7111))
- Added an optional `onClearAllToasts` callback to `EuiGlobalToastList`
([#7111](https://github.com/elastic/eui/pull/7111))
- Added the `value`, `onChange`, and `onCancel` props that allow
`EuiInlineEdit` to be used as a controlled component
([#7157](https://github.com/elastic/eui/pull/7157))
- Added `grabOmnidirectional`, `transitionLeftIn`, `transitionLeftOut`,
`transitionTopIn`, and `transitionTopOut` icon glyphs.
([#7168](https://github.com/elastic/eui/pull/7168))
**Bug fixes**
- Fixed `EuiInlineEdit` components to correctly spread `...rest`
attributes to the parent wrapper
([#7157](https://github.com/elastic/eui/pull/7157))
- Fixed `EuiListGroupItem` to correctly render the `extraAction` button
when `showToolTip` is also passed
([#7159](https://github.com/elastic/eui/pull/7159))
**Dependency updates**
- Updated `@hello-pangea/dnd` to v16.3.0
([#7125](https://github.com/elastic/eui/pull/7125))
- Updated `@types/lodash` to v4.14.198
([#7126](https://github.com/elastic/eui/pull/7126))
**Accessibility**
- `EuiAccordion` now correctly respects reduced motion settings
([#7161](https://github.com/elastic/eui/pull/7161))
- `EuiAccordion` now shows a focus outline to keyboard users around its
revealed children on open
([#7161](https://github.com/elastic/eui/pull/7161))
**CSS-in-JS conversions**
- Converted `EuiSplitPanel` to Emotion
([#7172](https://github.com/elastic/eui/pull/7172))
⚠️ As a quick heads up, serverless tests appear to have been extremely
flake/failure-prone the last couple weeks, particularly Cypress tests.
We've evaluated the listed failures and fixed ones that were related to
changes in this PR, and we're relatively confident the remaining
failures are not related to changes from EUI. Please let us know if you
think this is not the case.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Cee Chen <constance.chen@elastic.co>
Co-authored-by: Jon <jon@elastic.co>
## Summary
(this is the continuation of
https://github.com/elastic/kibana/pull/143910, which I started before my
parental leave and which is impossible to rebase)
With the introduction of more features that are part of licenses, we're
also adding more upsells to Kibana. These upsells advertise the feature,
they explain which license is required in order to use said feature and
they will link the client to the subscription page. Take the upsell for
more insights in the alert flyout as an example:
<img width="1584" alt="Screenshot 2022-10-18 at 16 39 52"
src="https://user-images.githubusercontent.com/68591/197629708-17978c8b-595e-4797-b80a-59c799896509.png">
Upsells come in all different shapes. Somtimes they're just links,
sometimes full pages and sometimes interactive popups. They are also
used across all solutions in Kibana.
There is currently no specific tracking in place for these types of
elements yet. Meaning we don't know how many people interact with them,
how many custerms see them and how well they perform in terms of
conversions.
It is technically already possible to analyze clicks on these elements
as part of the regular Kibana click tracking but it would require
setting up queries with lots of `data-test-subj` and `url` filters for
the right click events. Even if we wanted to set up tracking dashboards
with that data, we would still not know how often upsells are seen which
is necessary to calculate their click-through-rate. That rate can give
an indicator if an upsell performs well or if we might want to improve
it in the future.
For that reason, I'm proposing a dedicated set of tracking methods to
capture `impressions` and `clicks` for upsells. No conversion tracking
as of yet, but I will get back to that later.
This PR introduces the `@kbn/subscription-tracking` package. It
leverages the `@kbn/analytics-client` package to send dedicated
subscription tracking events.
It comes with a set of React components that automatically track
impressions and click events. Consumers of those components only need to
specify a `subscription context` that gives more details on the type of
feature that is advertised and the location of the upsell.
```typescript
import { SubscriptionLink } from '@kbn/subscription-tracking';
import type { SubscriptionContextData } from '@kbn/subscription-tracking';
const subscriptionContext: SubscriptionContextData = {
feature: 'threat-intelligence',
source: 'security__threat-intelligence',
};
export const Paywall = () => {
return (
<div>
<SubscriptionLink subscriptionContext={subscriptionContext}>
Upgrade to Platinum to get this feature
</SubscriptionLink>
</div>
)
}
```
The example above uses a `SubscriptionLink` which is a wrapper of
`EuiLink` . So it behaves just like a normal link. Alternatively,
upsells can also use a `SubscriptionButton` or `SubscriptionButtonEmpty`
which wrap `EuiButton` and `EuiButtonEmpty` respectively.
When the link is mounted, it will send off an `impression` event with
the given `subscriptionContext`. That piece of metadata consists of an
identifier of the advertised feature (in this case
`threat-intelligence`) and the `source` of the impression (in this case
the `threat-intelligence` page in the `security` solution). `source`
follows the following format:
`{solution-identifier}__location-identifier`.
There are no special rules for how to name these identifiers but it's
good practise to make sure that `feature` has the same value for all
upsells advertising the same feature (e.g. use enums for features to
prevent spelling mistakes).
Upon interaction with the upsell link/button, a special `click` event is
sent, which, again, contains the same subscription context.
If you want to use the `subscription-tracking` elements in your
solution, you have to set up a `SubscriptionTrackingProvider` in your
plugin setup and register the tracking events on startup. This PR
contains an example for this setup for the security plugin and some of
its sub-plugins.
## Next steps
- There are currently no dedicated tracking dashboards for these events
which I am planning to set up in the future.
- Since I only had a week's worth of time, I did not manage to add
conversion tracking. The addition of those events might be a lot harder
as well since the current license flow does not integrate seamlessly
into Kibana
- All upsells currently link to the license management page which
currently does not inform customers about our license and cloud
offering. It seems to me like a weak link in the subscription funnel and
it would be great to improve on that page.
- potential improvement: Send `impression` event when the element
becomes visible in the viewport instead of when the element is mounted
### Checklist
- [x]
[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)
was added for features that require explanation or tutorials
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
> [!IMPORTANT]
> I plan to merge this as an intermediate state. The next step is
changing the breadcrumbs component and make the project name as part of
it https://github.com/elastic/kibana/issues/166593
## Summary
close https://github.com/elastic/kibana/issues/166182
Shows project name in the Kibana header.
To test locally add to the `config/serverless.yml`:
```
xpack.cloud.serverless.project_id: "random"
xpack.cloud.serverless.project_name: "My Search Project"
```
I hardcoded 320px max-width to enable truncation for longer titles:
In general, the header is not very flexible and has issues on smaller
screen, but this needs to be fixed separately.
The link still leads to the `/projects` page of the cloud UI
## Summary
Removing `cluster.waitForClusterReady` in favour of unified
`waitUntilClusterReady` method.
We will keep waiting for `yellow` cluster status in the FTR stateful
tests and `green` in serverless tests.
## Summary
Upgrade `openpgp` from `5.3.0` to `5.10.1`
Commit log:
https://github.com/openpgpjs/openpgpjs/compare/v5.3.0...v5.10.1
There is an incompatibility of `Uint8Array` when using Jest/JSDom with
the TextEncoder/TextDecoder from node `util`.
`https://github.com/kayahr/text-encoding` has been added as a
`devDependency` so it can be used in the polyfill. It provides a working
TextEncoder/Decoder for our Jest tests.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/164905
This PR replaces individual shard failure and timeout warnings with a
single "incomplete data" warning. This work is required for
https://github.com/elastic/kibana/issues/163381
<img width="500" alt="Screen Shot 2023-09-06 at 9 35 52 AM"
src="77e62792-c1f1-4780-b4f2-3aca24e4691b">
<img width="500" alt="Screen Shot 2023-09-06 at 9 36 00 AM"
src="56f37db1-2b4a-484b-9244-66b352d82dc1">
<img width="500" alt="Screen Shot 2023-09-06 at 9 36 07 AM"
src="4a777963-6e88-4736-9d63-99a2843ebdbb">
### Test instructions
* Install flights and web logs sample data
* Create data view kibana_sample_data*. **Set time field to timestamp**
* open discover and select kibana_sample_data* data view
* Add filter with custom DSL
```
{
"error_query": {
"indices": [
{
"error_type": "exception",
"message": "local shard failure message 123",
"name": "kibana_sample_data_logs",
"shard_ids": [
0
]
}
]
}
}
```
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Julia Rechkunova <julia.rechkunova@gmail.com>
Co-authored-by: Marco Liberati <dej611@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/161876
Creates a plugin providing utilities to access metrics data. The plugin
only exposes a server API which includes a client with two methods:
- `getMetricIndices` to retrieve the user-defined indices where metrics
are located
- `updateMetricIndices` to update the indices
The client is now used where we previously relied on infra plugin to
provide the configuration, in APM and Infra.
The plugin persists the configuration in a new saved object
`metrics-data-source`. Because this configuration was previously stored
in the `infrastructure-ui-source`, the plugin relies on a fallback to
reuse any existing value (see additional context
https://github.com/elastic/kibana/issues/161876#issuecomment-1673537400).
### Reviewers
There are no functional changes outside of Infra Monitoring UI and APM
UI, other codeowners are involved because this introduces a new saved
object
- APM - the change introduces a drop-in replacement of the
`infra.getMetricIndices` call. The ui code still relies on infra plugin
for a couple of components so we can't drop the dependency yet, those
we'll need to be moved to a tier 2 plugin (more details in
https://github.com/elastic/observability-dev/discussions/2787
(internal)) in a separate issue
### Testing
You'll need metrics data to verify data fetching works (I've used an
edge-oblt cluster)
1. Navigate to Infrastructure Settings and verify metric indices are
configured with the default value of `infrastructure-ui-source`
2. Update metric indices settings (if connected to oblt cluster add
`remote_cluster:..` indices)
3. Verify `metrics-data-source` saved object is persisted with correct
attributes
4. Verify Infrastructure Inventory is pulling data from the newly
configured indices
5. Go to APM services, verify service Infrastructure pulls data from
newly configured indices
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Jason Rhodes <jason.rhodes@elastic.co>
