## Summary
Part of https://github.com/elastic/kibana/issues/200620
1. Remove usage of deprecated color variables
2. Remove usage of `@kbn/ui-theme`
3. A few other changes as requested by @andreadelrio
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Part of https://github.com/elastic/kibana-team/issues/1082
Selects certain Sass files to replace with styles declared with Emotion.
This PR does not include any changes that would be noticeable by
end-users. It changes the internals to use a different technology for
styling components.
~~Some `className` attributes have been kept, because they are
referenced in JS and tests.~~ Update: all classNames that are no longer
needed for styling purposes have been removed.
* If the className was needed for tests, it has been replaced with a
test-subj.
* If the className was used as a selector in production code, it has
been replaced with alternative JS.
## References
1. https://emotion.sh/docs/globals
2. https://emotion.sh/docs/best-practices
3.
https://github.com/elastic/eui/discussions/6828#discussioncomment-10825360
---------
Co-authored-by: Jatin Kathuria <jatin.kathuria@elastic.co>
## Summary
This PR is part of the Kibana Sustainable Architecture effort.
The goal is to start categorising Kibana packages into _generic
platform_ (`group: "platform"`) vs _solution-specific_.
```
group?: 'search' | 'security' | 'observability' | 'platform'
visibility?: 'private' | 'shared'
```
Uncategorised modules are considered to be `group: 'common', visibility:
'shared'` by default.
We want to prevent code from solution A to depend on code from solution
B.
Thus, the rules are pretty simple:
* Modules can only depend on:
* Modules in the same group
* OR modules with 'shared' visibility
* Modules in `'observability', 'security', 'search'` groups are
mandatorily `visibility: "private"`.
Long term, the goal is to re-organise packages into dedicated folders,
e.g.:
```
x-pack/platform/plugins/private
x-pack/observability/packages
```
For this first wave, we have categorised packages that seem
"straightforward":
* Any packages that have:
* at least one dependant module
* all dependants belong to the same group
* Categorise all Core packages:
* `@kbn/core-...-internal` => _platform/private_
* everything else => _platform/shared_
* Categorise as _platform/shared_ those packages that:
* Have at least one dependant in the _platform_ group.
* Don't have any `devOnly: true` dependants.
### What we ask from you, as CODEOWNERS of the _package manifests_, is
that you confirm that the categorisation is correct:
* `group: "platform", visibility: "private"` if it's a package that
should only be used from platform code, not from any solution code. It
will be loaded systematically in all serverless flavors, but solution
plugins and packages won't be able to `import` from it.
* `group: "platform", visibility: "shared"` if it's a package that can
be consumed by both platform and solutions code. It will be loaded
systematically in all serverless flavors, and anybody can import / use
code from it.
* `group: "observability" | "security" | "search", visibility:
"private"` if it's a package that is intented to be used exclusively
from a given solution. It won't be accessible nor loaded from other
solutions nor platform code.
Please refer to
[#kibana-sustainable-architecture](https://elastic.slack.com/archives/C07TCKTA22E)
for any related questions.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This PR migrates test suites that use `renderHook` from the library
`@testing-library/react-hooks` to adopt the equivalent and replacement
of `renderHook` from the export that is now available from
`@testing-library/react`. This work is required for the planned
migration to react18.
## Context
In this PR, usages of `waitForNextUpdate` that previously could have
been destructured from `renderHook` are now been replaced with `waitFor`
exported from `@testing-library/react`, furthermore `waitFor`
that would also have been destructured from the same renderHook result
is now been replaced with `waitFor` from the export of
`@testing-library/react`.
***Why is `waitFor` a sufficient enough replacement for
`waitForNextUpdate`, and better for testing values subject to async
computations?***
WaitFor will retry the provided callback if an error is returned, till
the configured timeout elapses. By default the retry interval is `50ms`
with a timeout value of `1000ms` that
effectively translates to at least 20 retries for assertions placed
within waitFor. See
https://testing-library.com/docs/dom-testing-library/api-async/#waitfor
for more information.
This however means that for person's writing tests, said person has to
be explicit about expectations that describe the internal state of the
hook being tested.
This implies checking for instance when a react query hook is being
rendered, there's an assertion that said hook isn't loading anymore.
In this PR you'd notice that this pattern has been adopted, with most
existing assertions following an invocation of `waitForNextUpdate` being
placed within a `waitFor`
invocation. In some cases the replacement is simply a `waitFor(() => new
Promise((resolve) => resolve(null)))` (many thanks to @kapral18, for
point out exactly why this works),
where this suffices the assertions that follow aren't placed within a
waitFor so this PR doesn't get larger than it needs to be.
It's also worth pointing out this PR might also contain changes to test
and application code to improve said existing test.
### What to do next?
1. Review the changes in this PR.
2. If you think the changes are correct, approve the PR.
## Any questions?
If you have any questions or need help with this PR, please leave
comments in this PR.
### Summary
This PR relocates some plugins and packages that are incorrectly
categorised, aiming at reducing inter-solution dependencies. It also
fixes some incorrect import statements that introduce unnecessary
dependencies with other components.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Maryam Saeidi <maryam.saeidi@elastic.co>
### Background
https://github.com/elastic/kibana/pull/194892 is refactoring
[DashboardRenderer](3391344e8d/src/plugins/dashboard/public/dashboard_container/external_api/dashboard_renderer.tsx)
component to replace Dashboard Embeddable with a plain old javascript
object. Dashboard Embeddable rendered its contents in a new react tree.
The new implementation does not. Since the new implementation does not
render the dashboard in a new react tree, any re-render in
`DashboardViewport` parent components causes `ExitFullScreenButton` to
re-render. In its current form, re-rendering `ExitFullScreenButton`
calls `onExit`, which causing dashboard to exit full screen mode.
This PR makes use of `useCallback` to fix the issue where re-rending
`ExitFullScreenButton` calls `onExit`.
### Test steps
1) Open dashboard that ships with sample web logs data set
2) switch to view mode
3) click "Full screen" button
4) Maximize a panel. Verify dashboard stays in full screen mode.
## Summary
This PR is part of
https://github.com/elastic/kibana-team/issues/1016#issuecomment-2399310175
and needed to upgrade Kibana to React@18 in Legacy mode.
We've found a problem in `react-monaco-editor` component which is a very
thin wrapper around `monaco` where it doesn't play nicely with React@18
in legacy mode. You can read on details around the issue here
https://github.com/elastic/eui/issues/8018 where we've found a similar
issue in EUI's search bar component. The workaround we've found is to
change `useEffect` -> `useLayouEffect` where the value that is coming
from the prop is set into the model. The issue and a fix might be a bit
controversal and the component is very thin, so I decided that it might
be better to bring the fork into Kibana with only what's needed and with
a workaround.
Closes: https://github.com/elastic/kibana/issues/195289
Closes: https://github.com/elastic/kibana/issues/195198
Closes: https://github.com/elastic/kibana/issues/195358
## Description
- The text editor must be fully accessible and functional across all
devices, ensuring users can edit text using various input methods, not
just a mouse. This functionality should be available in both the
expanded and collapsed states.
- Appropriate aria-label attribute must be assigned to elements to
provide users with clear context and understanding of the type of
element they are interacting with. This enhances usability and
accessibility for all users.
## What was changed:
- Updated the aria-label attribute for the editor button to improve
accessibility.
- Resolved an issue with the background color when activating
full-screen mode from the dialog.
- Fixed keyboard navigation for full-screen mode, enabling users to
activate Edit Mode using only the keyboard.
## Screen
https://github.com/user-attachments/assets/af122fab-3ce9-4a7f-b8b1-d75d39969781
<strike>Depends on https://github.com/elastic/kibana/issues/193526,
WON'T FIX</strike>
Fixes https://github.com/elastic/kibana/issues/192803
Fixes https://github.com/elastic/kibana/issues/191509
This PR updates the nav hierarchy for stateful/cloud and changes the
`accordion` to `panelOpener`. The menu items have been updated according
to the Figma file and the discussions happening in this
[issue](https://github.com/elastic/kibana/issues/192050). I took a video
below of how the new navigation looks like with the new changes
https://github.com/user-attachments/assets/e73c8dd9-b674-4146-bcde-443490569502
## What was changed
- AI & ML menu is removed and split into
- `AI Assistant`
- `Machine learning`: this menu was already present in the footer, it
was moved in the body (after Infrastucture)
- `Applications` now opens a `panelOpener` instead of an `accordion`
- Synthetics was moved to a new section
- “User Experience” was renamed to “User experience”
- `Infrastucture` now opens a `panelOpener` instead of an `accordion`
- Universal Profiling was moved to a separate section below
- Metrics Explorer was renamed to Metrics explorer
- `Machine learning` now opens a `panelOpener` instead of an `accordion`
- `Supplied Configurations` was added under the Machine learning >
Anomaly Detection section.
- The machine learning `link:
'securitySolutionUI:machine_learning-landing'` was completely removed.
Clicking on the `Machine learning` link will slide out the panel instead
(same behavior with clicking on the icon). More details about why I
removed this
[here](https://github.com/elastic/kibana/pull/192805#issuecomment-2359368851)
- Use sentence/case for the menu items
- `Other tools` now opens a `panelOpener` instead of an `accordion`
- Logs anomalies was added here
- Logs categories was added here
- Visualize library was added
- Clicking on the 1st level menu items (Applications, Infrastructure,
Machine learning, Other tools) toggles the panel on the right
(arrowRight).
- The icon was changed from the four small squares to the right-facing
caret
- The sub-nav menu slides out to the right whenever the label OR the
icon are clicked
- `Getting started` in the footer was renamed to `Add data`
- `Data Set Quality` was added under `Stack Management > Data` section
below `Index Management`
## Functional Tests
Some tests have been added that test:
- toggling of the panel when clicking on the link button
- `AI assistant` changes
- `Infrastructure` changes
- `Other Tools` changes
- `Machine Learning` changes
## What this PR doesn't do
I faced some issues with the footer, so footer will be separately
handled in this [issue](https://github.com/elastic/kibana/issues/192865)
---------
Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>
Co-authored-by: Sébastien Loix <sebastien.loix@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co>
## Summary
Prep for https://github.com/elastic/kibana/issues/138222
This PR updates `styled-components` package to the latest v5 version. I
would like to do it for react@18 upgrade to suppress a noisy warning
that is coming from `styled-components` when it is used with react@18.
Here is that PR
https://github.com/styled-components/styled-components/pull/3564/files
Updates the failed snapshot tests.
Dear reviewers, could you please smoke-check your apps visually? This is
a minor upgrade, but I think it is worth to click around anyway.
## Summary
Upgrades `@testing-library/user-event` to `^14.5.2`. See the release
notes for `v14` for breaking changes:
https://github.com/testing-library/user-event/releases/tag/v14.0.0
I was facing an
[issue](https://github.com/testing-library/user-event/issues/662) with
`v13.5.0` with `userEvent.click()` in a PR
(https://github.com/elastic/kibana/pull/189729) and was able to verify
that `v14.4.3` onwards fixes it so I decided to update that package.
What a rabbit hole 😅 !
- In `user-event` `v14` events return a promise, so this PR updates
usage of the likes of `userEvent.click` with `await userEvent.click`.
Regex to search for `userEvent` calls that miss `await` except `.setup`:
`(?<!await\s)userEvent\.(?!setup\b)`
- The way to handle pointer events needed changing from `, undefined, {
skipPointerEventsCheck: true });` to `, { pointerEventsCheck: 0 });`.
- I tried a bit to do the refactor with codemods, but there were quite
some edge cases so it ended up being done manually.
- I looked into all failing tests and tried my best to update them, but
for some of them I lacked the context to make them work again. If you're
a code owner and find a skipped test in this PR please give it a try to
fix and push in this PR or let me know if it's fine for you to fix in
follow ups.
List of files where I had to skip tests (`git diff main...HEAD
-G'\.skip' --name-only`):
### `packages/kbn-dom-drag-drop`
- `packages/kbn-dom-drag-drop/src/droppable.test.tsx`
### `x-pack/plugins/cases`
- `x-pack/plugins/cases/public/components/templates/form.test.tsx`
-
`x-pack/plugins/cases/public/components/user_actions/user_actions_list.test.tsx`
### `x-pack/plugins/cloud_security_posture`
-
`x-pack/plugins/cloud_security_posture/public/components/fleet_extensions/policy_template_form.test.tsx`
### `x-pack/plugins/lens`
-
`x-pack/plugins/lens/public/datasources/form_based/dimension_panel/format_selector.test.tsx`
### `x-pack/plugins/observability_solution`
-
`x-pack/plugins/observability_solution/synthetics/public/apps/synthetics/components/monitor_add_edit/fields/request_body_field.test.tsx`
### `x-pack/plugins/security_solution`
-
`x-pack/plugins/security_solution/public/management/components/console/components/command_input/integration_tests/command_input.test.tsx`
-
`x-pack/plugins/security_solution/public/management/components/endpoint_responder/command_render_components/integration_tests/kill_process_action.test.tsx`
-
`x-pack/plugins/security_solution/public/management/components/endpoint_responder/command_render_components/integration_tests/release_action.test.tsx`
-
`x-pack/plugins/security_solution/public/management/components/endpoint_responder/command_render_components/integration_tests/status_action.test.tsx`
-
`x-pack/plugins/security_solution/public/management/components/endpoint_responder/command_render_components/integration_tests/upload_action.test.tsx`
-
`x-pack/plugins/security_solution/public/management/components/endpoint_response_actions_list/integration_tests/response_actions_log.test.tsx`
-
`x-pack/plugins/security_solution/public/management/pages/event_filters/view/components/event_filters_flyout.test.tsx`
-
`x-pack/plugins/security_solution/public/management/pages/response_actions/view/response_actions_list_page.test.tsx`
----
I plan to do a talk on Kibana Demo Days to walk through some of the
breaking changes and learnings.
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [x] 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)
## Summary
Part of https://github.com/elastic/kibana/issues/138222
in @types/react@18 types [have become more
strict](https://github.com/DefinitelyTyped/DefinitelyTyped/pull/56210).
This PR addresses a bunch of easy fixes. The most common are:
### 1 Removal of implicit children
For components that do implement children but relied on their implicit
declaration from React.FunctionComponent or React.Component:
```diff
interface Props {
+ children?: React.ReactNode;
}
class SomeClassComponents React.Component<Props> {
render() {
return <div>{this.props.children}</div>
}
}
const SomeFunctionComponent: React.FunctionComponent<Props> = props => <div>{props.children}</div>
```
or
```diff
- const SomeFunctionComponent: React.FunctionComponent<Props> = props => <div>{props.children}</div>
+ const SomeFunctionComponent: React.FunctionComponent<React.PropsWithChildren<Props>> = props => <div>{props.children}</div>
```
*Note 1:*
The most common change occurs in unit tests where `renderHook` and
`wrapper` are used. I had to re-type the props so that `children` were
there
```diff
const { result } = renderHook(
() => {
return useLicense();
},
{
- wrapper: ({ children }) => (
+ wrapper: ({ children }: React.PropsWithChildren<{}>) => (
<TestProviders license={license}>{children}</TestProviders>
),
}
);
```
```diff
- const { result } = renderHook<GetCasesColumn, UseCasesColumnsReturnValue>(
+ const { result } = renderHook<React.PropsWithChildren<GetCasesColumn>, UseCasesColumnsReturnValue>(
() => useCasesColumns(defaultColumnArgs),
{
wrapper: ({ children }) => <TestProviders>{children}</TestProviders>,
}
);
```
*Note 2:*
With @types/react@17 the components that don't have any props apart from
`children` I had to use `React.PropsWithChildren<{}>`, whereas in
@types/react@18 the argument becomes optional, so it can be omitted, and
type simpler with `React.PropsWithChildren` without an argument
### 2 `this.context` becomes `unknown` (was `any`)
In a couple of places where `this.context` is used, I had to type it
### 3 `ComponentType` from enzyme is no longer compatible with
`ComponentType` from react
This one is a bummer, but where `wrappingComponent` with enzyme is used
I had to cast it to type from `enzyme`
```diff
- import { mount } from 'enzyme'
+ import { mount, ComponentType } from 'enzyme'
wrapper = mount(<ClosureOptions {...props} />, {
- wrappingComponent: TestProviders,
+ wrappingComponent: TestProviders as ComponentType<{}>,
});
```
Addresses https://github.com/elastic/kibana/issues/56406
## Summary
This PR is part of my June 2024 On-week project. It adds functionality
for persisting table page size (rows per page) and sorting in EUI
tables. When a user changes the size or sort, the new values are saved
in local storage, so that when the user navigates out of the page and
comes back, the page size and sort will be the same.
In this PR, the functionality is added to the following tables:
- Ingest Pipelines
- Index Management - all tables (indices, data streams, index templates,
component templates, enrich policies)
- ILM policies
08b0c004-65a1-4a58-b8fb-99010e1c3248
<!--
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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>
## Summary
This PR has breadth, but not depth. This adds 3 new `eslint` rules. The
first two protect against the use of code generated from strings (`eval`
and friends), which will not work client-side due to our CSP, and is not
something we wish to support server-side. The last rule aims to prevent
a subtle class of bugs, and to defend against a subset of prototype
pollution exploits:
- `no-new-func` to be compliant with our CSP, and to prevent code
execution from strings server-side:
https://eslint.org/docs/latest/rules/no-new-func
- `no-implied-eval` to be compliant with our CSP, and to prevent code
execution from strings server-side:
https://eslint.org/docs/latest/rules/no-implied-eval. Note that this
function implies that it prevents no-new-func, but I don't see [test
cases](https://github.com/eslint/eslint/blob/main/tests/lib/rules/no-implied-eval.js)
covering this behavior, so I think we should play it safe and enable
both rules.
- `no-prototype-builtins` to prevent accessing shadowed properties:
https://eslint.org/docs/latest/rules/no-prototype-builtins
In order to be compliant with `no-prototype-builtins`, I've migrated all
usages and variants of `Object.hasOwnProperty` to use the newer
[`Object.hasOwn`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwn).
## Summary
At the moment, our package generator creates all packages with the type
`shared-common`. This means that we cannot enforce boundaries between
server-side-only code and the browser, and vice-versa.
- [x] I started fixing `packages/core/*`
- [x] It took me to fixing `src/core/` type to be identified by the
`plugin` pattern (`public` and `server` directories) vs. a package
(either common, or single-scoped)
- [x] Unsurprisingly, this extended to packages importing core packages
hitting the boundaries eslint rules. And other packages importing the
latter.
- [x] Also a bunch of `common` logic that shouldn't be so _common_ 🙃
### For maintainers
- [x] 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
Closes https://github.com/elastic/kibana/issues/184025
This PR enables the migration from Ace to Monaco in Dev Tools Console by
default in the main branch. All serverless projects will still have the
migration disabled by default. After 8.15 is branched, the migration
will be disabled there as well. The intended release version for this
migration is 8.16.
### Functional tests
This PR creates a copy of functional tests for Monaco Console and keeps
the tests for Ace in a separate folder. When the migration is released,
we can remove the code for Ace together with tests.
The Monaco tests are not the exact copy of the Ace tests, since some
functionality and autocomplete behaviour is slightly different in the
migrated Console. For example, the auto-closing of brackets works in
Monaco when typing something, but is not kicking in in the tests.
Flaky test runner
### 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
- [ ] [Flaky Test
Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was
used on any tests changed
- [ ] 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>
Closes https://github.com/elastic/kibana/issues/186080
PR resolves issue by updating `Markdown` component to not throw when
`readOnly` and `content` is empty. Components should only throw on
catastrophic errors. In this case, Markdown can safely render an empty
markdown. This is a better out come then crashing an application.
### Test instructions
Follow steps from https://github.com/elastic/kibana/issues/186095 and
verify dashboard does not crash
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
fixes [176177](https://github.com/elastic/kibana/issues/176177)
relates to https://github.com/elastic/eui/issues/7765
## Summary
Changes the `min-block-size` to account for the `kibanaProjectHeader`
element, which exists only in serverless, to calculate the page size and
sticky elements' top position.
<img width="1728" alt="image"
src="3b3674dc-0f3a-4671-b5e9-0b2263c2c982">
## Stateful
2383aa9d-eee1-4aaa-94af-081f53ef84a4
## Serverless
6830e136-cb55-4bef-8a8c-2eaf3bdc8374
2c26014b-1572-430f-ae9c-6a4093f76422
af6449d7-4077-4340-b5af-8a29bfae95a2
### How to test
- Start a serverless instance
- `yarn es serverless --projectType=PROJECT_TYPE --kill --clean
--license trial -E xpack.security.authc.api_key.enabled=true`
- Start a local kibana
- Check if the pages still work as expected
## Summary
Upgrading intl packages from v2 to v6
### Packages upgrade:
- [x] Add @formatJS packages
- [x] `react-intl` Upgraded
- [x] `intl-messageformat` Upgraded
- [x] `intl-format-cache` removed
- [x] `intl-relativeformat` removed
- [x] `intl-messageformat-parser` removed
### Todo list:
- [x] Refactor HTML tags
- [x] Refactor Upgrade tags
- [x] Refactor `kbn-i18n`
- [x] Refactor `kbn-i18n-react`
- [x] Refactor `FormattedRelative` to `FormattedRelativeTime`
- [x] Refactor polyfills
- [x] Refactor IntlShape types
- [x] Rewrite Providers
- [x] Rewrite tests using i18n
- [x] Removed current pseudolocale implementation (tracker:
https://github.com/elastic/kibana/issues/180244)
- [x] Fix jest tests using rendered `Provider`
- [x] Remove no longer valid i18n packages documentation (tracker:
https://github.com/elastic/kibana/issues/180259)
Closes https://github.com/elastic/kibana/issues/178968
Closes https://github.com/elastic/kibana/issues/38642
## Notes to code reviewers
For team other than the core team, please review your plugins code
changes by filtering files by codeowners.
### Test Snapshot updates
Most of the changes are refactors of renamed functions and changed ICU
syntax.
The main updates are snapshot changes where `FormattedMessage` is now
memoized so snapshots capturing the html tree needed to be updated to
use `<Memo(MemoizedFormattedMessage)` instead of `<FormattedMessage`
### ICU now supports HTML tags:
before:
```
<FormattedMessage
defaultMessage="To buy a shoe, { link } and { cta }"
values={{
link: (
<a class="external_link" target="_blank" href="https://www.shoe.com/">
visit our website
</a>
),
cta: <strong class="important">eat a shoe</strong>,
}}
/>
```
after:
```
<FormattedMessage
defaultMessage="To buy a shoe, <a>visit our website</a> and <cta>eat a shoe</cta>"
values={{
a: msg => (
<a class="external_link" target="_blank" href="https://www.shoe.com/">
{msg}
</a>
),
cta: msg => <strong class="important">{msg}</strong>,
}}
/>
```
### Escape character to prevent ICU parsing changed from double slashes
to single quotes:
before: `\\{escaped\\}`
after: `'{escaped}'`
### No need for Intl Shape
the new packages under formatJS are written in typescript and come with
types support out of the box so no need to set types when using i18n.
Renamed `InjectedIntlProps` with `WrappedComponentProps`.
Removed `prop-types` and `intlShape` in favor of `IntlShape`.
### FormattedRelative has been renamed to FormattedRelativeTime and its
API has changed significantly. See
[FormattedRelativeTime](https://formatjs.io/docs/react-intl/upgrade-guide-3x#formattedrelativetime)
for more details.
### All tags specified must have corresponding values and will throw
error if it's missing
All tags are now parsed and expected to be formatted properly (all
opened tags must be closed).
To skip this check you can use the `ignoreTag: true` property
```
i18n.translate('xpack.apm.agentConfig.captureJmxMetrics.description', {
defaultMessage: 'This is not an HTML tag <JMX object name pattern>' +
ignoreTag: true,
}),
```
**When do I use ignore tags?**
If your message has HTML tags, it is preferred not to ignore the Tag to
have some string verification that the html tags you are adding are
properly formatted and closed.
If it the text between brackets is not an HTML tag and it is just a
fomat preference then using `ignoreTag` makes sense.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
