# Backport
This will backport the following commits from `main` to `8.10`:
- [Log more information on requests that fail at global router level
(#165293)](https://github.com/elastic/kibana/pull/165293)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Gerard
Soldevila","email":"gerard.soldevila@elastic.co"},"sourceCommit":{"committedDate":"2023-09-04T12:20:27Z","message":"Log
more information on requests that fail at global router level
(#165293)\n\nThere are certain occasions where Kibana UI shows a blank
page (e.g. on\r\nthis
[failed\r\ntest](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/2999)).\r\nBlank
pages can happen when browsers are not able to fetch one or more\r\nof
the bootstrap resources, e.g. `/bootstrap.js`.\r\nSometimes, Kibana
server-side logs don't contain any information at all\r\nas to what
caused the failure.\r\n\r\nThis PR adds a bit more information in the
logs, hoping it will help us\r\nunderstanding why some of these requests
fail sometimes.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"86765b916dbfc424144735b9c5de904a4e7b7de0","branchLabelMapping":{"^v8.11.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","Team:Core","release_note:skip","backport:prev-minor","v8.11.0"],"number":165293,"url":"https://github.com/elastic/kibana/pull/165293","mergeCommit":{"message":"Log
more information on requests that fail at global router level
(#165293)\n\nThere are certain occasions where Kibana UI shows a blank
page (e.g. on\r\nthis
[failed\r\ntest](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/2999)).\r\nBlank
pages can happen when browsers are not able to fetch one or more\r\nof
the bootstrap resources, e.g. `/bootstrap.js`.\r\nSometimes, Kibana
server-side logs don't contain any information at all\r\nas to what
caused the failure.\r\n\r\nThis PR adds a bit more information in the
logs, hoping it will help us\r\nunderstanding why some of these requests
fail sometimes.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"86765b916dbfc424144735b9c5de904a4e7b7de0"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.11.0","labelRegex":"^v8.11.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/165293","number":165293,"mergeCommit":{"message":"Log
more information on requests that fail at global router level
(#165293)\n\nThere are certain occasions where Kibana UI shows a blank
page (e.g. on\r\nthis
[failed\r\ntest](https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/2999)).\r\nBlank
pages can happen when browsers are not able to fetch one or more\r\nof
the bootstrap resources, e.g. `/bootstrap.js`.\r\nSometimes, Kibana
server-side logs don't contain any information at all\r\nas to what
caused the failure.\r\n\r\nThis PR adds a bit more information in the
logs, hoping it will help us\r\nunderstanding why some of these requests
fail sometimes.\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"86765b916dbfc424144735b9c5de904a4e7b7de0"}}]}]
BACKPORT-->
Co-authored-by: Gerard Soldevila <gerard.soldevila@elastic.co>
# Backport
This will backport the following commits from `main` to `8.10`:
- [[SOR] implement downward compatible `update`
(#161822)](https://github.com/elastic/kibana/pull/161822)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Christiane (Tina)
Heiligers","email":"christiane.heiligers@elastic.co"},"sourceCommit":{"committedDate":"2023-09-01T08:27:17Z","message":"[SOR]
implement downward compatible `update` (#161822)\n\nPart of
https://github.com/elastic/kibana/issues/152807\r\n\r\n##
Summary\r\n\r\nChange the way the `update` API of the savedObjects
repository works, to\r\nstop using ES `update` and perform the update
manually instead by\r\nfetching the document, applying the update and
then re-indexing the\r\nwhole document.\r\n\r\nThis is required for BWC
and version cohabitation reasons, to allow us\r\nconverting the document
to the last known version before applying the\r\nupdate.\r\n\r\nThe
retry on conflict behavior is manually performed too, by
detecting\r\nconflict errors during the `index` calls and performing the
whole loop\r\n(fetch->migrate->update->index) again.\r\n\r\nUpserts are
done in a similar way, by checking the document's existence\r\nfirst,
and then using the `create` API.\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
pgayvallet
<pierre.gayvallet@elastic.co>","sha":"727929683e036abe1d5b8c2b05d9c0e5a7539b14","branchLabelMapping":{"^v8.11.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Core","Feature:Saved
Objects","release_note:skip","backport:all-open","v8.10.0","v8.11.0"],"number":161822,"url":"https://github.com/elastic/kibana/pull/161822","mergeCommit":{"message":"[SOR]
implement downward compatible `update` (#161822)\n\nPart of
https://github.com/elastic/kibana/issues/152807\r\n\r\n##
Summary\r\n\r\nChange the way the `update` API of the savedObjects
repository works, to\r\nstop using ES `update` and perform the update
manually instead by\r\nfetching the document, applying the update and
then re-indexing the\r\nwhole document.\r\n\r\nThis is required for BWC
and version cohabitation reasons, to allow us\r\nconverting the document
to the last known version before applying the\r\nupdate.\r\n\r\nThe
retry on conflict behavior is manually performed too, by
detecting\r\nconflict errors during the `index` calls and performing the
whole loop\r\n(fetch->migrate->update->index) again.\r\n\r\nUpserts are
done in a similar way, by checking the document's existence\r\nfirst,
and then using the `create` API.\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
pgayvallet
<pierre.gayvallet@elastic.co>","sha":"727929683e036abe1d5b8c2b05d9c0e5a7539b14"}},"sourceBranch":"main","suggestedTargetBranches":["8.10"],"targetPullRequestStates":[{"branch":"8.10","label":"v8.10.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.11.0","labelRegex":"^v8.11.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/161822","number":161822,"mergeCommit":{"message":"[SOR]
implement downward compatible `update` (#161822)\n\nPart of
https://github.com/elastic/kibana/issues/152807\r\n\r\n##
Summary\r\n\r\nChange the way the `update` API of the savedObjects
repository works, to\r\nstop using ES `update` and perform the update
manually instead by\r\nfetching the document, applying the update and
then re-indexing the\r\nwhole document.\r\n\r\nThis is required for BWC
and version cohabitation reasons, to allow us\r\nconverting the document
to the last known version before applying the\r\nupdate.\r\n\r\nThe
retry on conflict behavior is manually performed too, by
detecting\r\nconflict errors during the `index` calls and performing the
whole loop\r\n(fetch->migrate->update->index) again.\r\n\r\nUpserts are
done in a similar way, by checking the document's existence\r\nfirst,
and then using the `create` API.\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
pgayvallet
<pierre.gayvallet@elastic.co>","sha":"727929683e036abe1d5b8c2b05d9c0e5a7539b14"}}]}]
BACKPORT-->
Co-authored-by: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co>
# Backport
This will backport the following commits from `main` to `8.10`:
- [[SOR] Allow optionally downgrading documents with a higher version
model in API READ methods
(#164789)](https://github.com/elastic/kibana/pull/164789)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Christiane (Tina)
Heiligers","email":"christiane.heiligers@elastic.co"},"sourceCommit":{"committedDate":"2023-08-26T20:32:40Z","message":"[SOR]
Allow optionally downgrading documents with a higher version model in
API READ methods (#164789)\n\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"0f4052bc200b5e2d29e2b10983335fa5c13510fe","branchLabelMapping":{"^v8.11.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Saved
Objects","release_note:skip","backport:all-open","Epic:KBNA-7996","v8.10.0","v8.11.0"],"number":164789,"url":"https://github.com/elastic/kibana/pull/164789","mergeCommit":{"message":"[SOR]
Allow optionally downgrading documents with a higher version model in
API READ methods (#164789)\n\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"0f4052bc200b5e2d29e2b10983335fa5c13510fe"}},"sourceBranch":"main","suggestedTargetBranches":["8.10"],"targetPullRequestStates":[{"branch":"8.10","label":"v8.10.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"main","label":"v8.11.0","labelRegex":"^v8.11.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/164789","number":164789,"mergeCommit":{"message":"[SOR]
Allow optionally downgrading documents with a higher version model in
API READ methods (#164789)\n\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"0f4052bc200b5e2d29e2b10983335fa5c13510fe"}}]}]
BACKPORT-->
Co-authored-by: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co>
# Backport
This will backport the following commits from `main` to `8.10`:
- [[Logger] Strip ANSI escape codes from the message
(#164337)](https://github.com/elastic/kibana/pull/164337)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Alejandro Fernández
Haro","email":"alejandro.haro@elastic.co"},"sourceCommit":{"committedDate":"2023-08-25T09:53:57Z","message":"[Logger]
Strip ANSI escape codes from the message (#164337)\n\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"4b88b10b0f4e3539f697fecfbf2a2097aa620510","branchLabelMapping":{"^v8.11.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Core","Team:Security","release_note:skip","Team:
SecuritySolution","backport:prev-minor","v8.11.0"],"number":164337,"url":"https://github.com/elastic/kibana/pull/164337","mergeCommit":{"message":"[Logger]
Strip ANSI escape codes from the message (#164337)\n\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"4b88b10b0f4e3539f697fecfbf2a2097aa620510"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.11.0","labelRegex":"^v8.11.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/164337","number":164337,"mergeCommit":{"message":"[Logger]
Strip ANSI escape codes from the message (#164337)\n\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"4b88b10b0f4e3539f697fecfbf2a2097aa620510"}}]}]
BACKPORT-->
Co-authored-by: Alejandro Fernández Haro <alejandro.haro@elastic.co>
# Backport
This will backport the following commits from `main` to `8.10`:
- [RollingFileAppender: fix file moving mechanism
(#164688)](https://github.com/elastic/kibana/pull/164688)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Pierre
Gayvallet","email":"pierre.gayvallet@elastic.co"},"sourceCommit":{"committedDate":"2023-08-24T13:46:48Z","message":"RollingFileAppender:
fix file moving mechanism (#164688)\n\n## Summary\r\n\r\nOn some file
systems or volume mounts, `rename` is not supported and\r\nthrows a
`EXDEV` error, which breaks our file rolling.\r\n\r\nThis PR addresses
it by defaulting to `copy` + `unlink` if the `rename`\r\ncalls fails
with an `EXDEV` error.\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"d16594f266c962efeb6e44c64c7bc2089efddcb9","branchLabelMapping":{"^v8.11.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","Team:Core","release_note:skip","Feature:Logging","backport:prev-minor","v8.11.0"],"number":164688,"url":"https://github.com/elastic/kibana/pull/164688","mergeCommit":{"message":"RollingFileAppender:
fix file moving mechanism (#164688)\n\n## Summary\r\n\r\nOn some file
systems or volume mounts, `rename` is not supported and\r\nthrows a
`EXDEV` error, which breaks our file rolling.\r\n\r\nThis PR addresses
it by defaulting to `copy` + `unlink` if the `rename`\r\ncalls fails
with an `EXDEV` error.\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"d16594f266c962efeb6e44c64c7bc2089efddcb9"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.11.0","labelRegex":"^v8.11.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/164688","number":164688,"mergeCommit":{"message":"RollingFileAppender:
fix file moving mechanism (#164688)\n\n## Summary\r\n\r\nOn some file
systems or volume mounts, `rename` is not supported and\r\nthrows a
`EXDEV` error, which breaks our file rolling.\r\n\r\nThis PR addresses
it by defaulting to `copy` + `unlink` if the `rename`\r\ncalls fails
with an `EXDEV` error.\r\n\r\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"d16594f266c962efeb6e44c64c7bc2089efddcb9"}}]}]
BACKPORT-->
Co-authored-by: Pierre Gayvallet <pierre.gayvallet@elastic.co>
# Backport
This will backport the following commits from `main` to `8.10`:
- [[Flaky test #90578] Unskip test
(#163696)](https://github.com/elastic/kibana/pull/163696)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Alejandro Fernández
Haro","email":"alejandro.haro@elastic.co"},"sourceCommit":{"committedDate":"2023-08-24T13:02:34Z","message":"[Flaky
test #90578] Unskip test (#163696)\n\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"ba843882a7bb35aa3062efd6562ed85d5db157f4","branchLabelMapping":{"^v8.11.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Core","technical
debt","release_note:skip","Team:SharedUX","backport:prev-minor","v8.11.0"],"number":163696,"url":"https://github.com/elastic/kibana/pull/163696","mergeCommit":{"message":"[Flaky
test #90578] Unskip test (#163696)\n\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"ba843882a7bb35aa3062efd6562ed85d5db157f4"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.11.0","labelRegex":"^v8.11.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/163696","number":163696,"mergeCommit":{"message":"[Flaky
test #90578] Unskip test (#163696)\n\nCo-authored-by: Kibana Machine
<42973632+kibanamachine@users.noreply.github.com>","sha":"ba843882a7bb35aa3062efd6562ed85d5db157f4"}}]}]
BACKPORT-->
Co-authored-by: Alejandro Fernández Haro <alejandro.haro@elastic.co>
# Backport
This will backport the following commits from `main` to `8.10`:
- [[HTTP] Allow for internal requests to also specify special query
param `elasticInternalOrigin`
(#163796)](https://github.com/elastic/kibana/pull/163796)
<!--- Backport version: 8.9.7 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Jean-Louis
Leysens","email":"jeanlouis.leysens@elastic.co"},"sourceCommit":{"committedDate":"2023-08-21T09:55:33Z","message":"[HTTP]
Allow for internal requests to also specify special query param
`elasticInternalOrigin` (#163796)\n\n## Summary\r\n\r\nCloses
https://github.com/elastic/kibana/issues/163678\r\n\r\n* Raise the
notion of \"internal\" into `CoreKibanaRequest`. This enables\r\nus to
share this with lifecycle handlers and control validation of
query\r\nparams\r\n* Added new `isInternalRequest` alongside
`isSystemRequest` and\r\n`isFakeRequest`\r\n* Slight simplification to
existing internal restriction check\r\n* Some other chores and minor
fixes\r\n\r\n## Test\r\n\r\n* Start ES with `yarn es serverless` and
Kibana with `yarn start\r\n--serverless
--server.restrictInternalApis=true`\r\n* Add the service account token
to `kibana.dev.yml`:\r\n`elasticsearch.serviceAccountToken: <SAT>`\r\n*
Send a request to an internal endpoint like: `curl
-XPOST\r\n-uelastic:changeme
http://localhost:5601/<base-path>/api/files/find -H\r\n'kbn-xsrf: foo'
-H 'content-type: application/json' -d '{}'`\r\n * Should give you a 400
result\r\n* message like `{\"statusCode\":400,\"error\":\"Bad
Request\",\"message\":\"uri\r\n[http://localhost:5603/api/files/find]
with method [post] exists but is\r\nnot available with the current
configuration\"}`\r\n* Send the same request, but include the query
param:\r\n`elasticInternalOrigin=true`\r\n * Should give you a 200
result\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"23d39555e0d0fc36c760f0c148913db69749cb47","branchLabelMapping":{"^v8.10.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:http","Team:Core","release_note:skip","v8.10.0","v8.11.0"],"number":163796,"url":"https://github.com/elastic/kibana/pull/163796","mergeCommit":{"message":"[HTTP]
Allow for internal requests to also specify special query param
`elasticInternalOrigin` (#163796)\n\n## Summary\r\n\r\nCloses
https://github.com/elastic/kibana/issues/163678\r\n\r\n* Raise the
notion of \"internal\" into `CoreKibanaRequest`. This enables\r\nus to
share this with lifecycle handlers and control validation of
query\r\nparams\r\n* Added new `isInternalRequest` alongside
`isSystemRequest` and\r\n`isFakeRequest`\r\n* Slight simplification to
existing internal restriction check\r\n* Some other chores and minor
fixes\r\n\r\n## Test\r\n\r\n* Start ES with `yarn es serverless` and
Kibana with `yarn start\r\n--serverless
--server.restrictInternalApis=true`\r\n* Add the service account token
to `kibana.dev.yml`:\r\n`elasticsearch.serviceAccountToken: <SAT>`\r\n*
Send a request to an internal endpoint like: `curl
-XPOST\r\n-uelastic:changeme
http://localhost:5601/<base-path>/api/files/find -H\r\n'kbn-xsrf: foo'
-H 'content-type: application/json' -d '{}'`\r\n * Should give you a 400
result\r\n* message like `{\"statusCode\":400,\"error\":\"Bad
Request\",\"message\":\"uri\r\n[http://localhost:5603/api/files/find]
with method [post] exists but is\r\nnot available with the current
configuration\"}`\r\n* Send the same request, but include the query
param:\r\n`elasticInternalOrigin=true`\r\n * Should give you a 200
result\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"23d39555e0d0fc36c760f0c148913db69749cb47"}},"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/163796","number":163796,"mergeCommit":{"message":"[HTTP]
Allow for internal requests to also specify special query param
`elasticInternalOrigin` (#163796)\n\n## Summary\r\n\r\nCloses
https://github.com/elastic/kibana/issues/163678\r\n\r\n* Raise the
notion of \"internal\" into `CoreKibanaRequest`. This enables\r\nus to
share this with lifecycle handlers and control validation of
query\r\nparams\r\n* Added new `isInternalRequest` alongside
`isSystemRequest` and\r\n`isFakeRequest`\r\n* Slight simplification to
existing internal restriction check\r\n* Some other chores and minor
fixes\r\n\r\n## Test\r\n\r\n* Start ES with `yarn es serverless` and
Kibana with `yarn start\r\n--serverless
--server.restrictInternalApis=true`\r\n* Add the service account token
to `kibana.dev.yml`:\r\n`elasticsearch.serviceAccountToken: <SAT>`\r\n*
Send a request to an internal endpoint like: `curl
-XPOST\r\n-uelastic:changeme
http://localhost:5601/<base-path>/api/files/find -H\r\n'kbn-xsrf: foo'
-H 'content-type: application/json' -d '{}'`\r\n * Should give you a 400
result\r\n* message like `{\"statusCode\":400,\"error\":\"Bad
Request\",\"message\":\"uri\r\n[http://localhost:5603/api/files/find]
with method [post] exists but is\r\nnot available with the current
configuration\"}`\r\n* Send the same request, but include the query
param:\r\n`elasticInternalOrigin=true`\r\n * Should give you a 200
result\r\n\r\n---------\r\n\r\nCo-authored-by: kibanamachine
<42973632+kibanamachine@users.noreply.github.com>","sha":"23d39555e0d0fc36c760f0c148913db69749cb47"}},{"branch":"8.11","label":"v8.11.0","labelRegex":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
Co-authored-by: Jean-Louis Leysens <jeanlouis.leysens@elastic.co>
`85.1.0` ➡️ `86.0.0`
⚠️ The biggest change in this PR is migrating the `react-beautiful-dnd`
dependency to it's open-source forked successor, `@hello-pangea/dnd`.
This new fork has better typescript support and additionally supports
both React 17 and React 18.
## [`86.0.0`](https://github.com/elastic/eui/tree/v86.0.0)
- Added React 18 support (StrictMode not yet supported).
([#7012](https://github.com/elastic/eui/pull/7012))
**Deprecations**
- Deprecated `euiPaletteComplimentary`; Use `euiPaletteComplementary`
instead. ([#6992](https://github.com/elastic/eui/pull/6992))
**Breaking changes**
- Replaced the underlying drag-and-drop library from
`react-beautiful-dnd` to its fork `@hello-pangea/dnd`
([#7012](https://github.com/elastic/eui/pull/7012))
([#7012](https://github.com/elastic/eui/pull/7012))
- No code updates are needed if using only `<EuiDragDropContext>`,
`<EuiDroppable>` and `<EuiDraggable>` with no direct imports from
`react-beautiful-dnd`. In case you were importing things from
`react-beautiful-dnd` and using them together with EUI components, you
need to switch to `@hello-pangea/dnd` which has cross-compatible API.
---------
Co-authored-by: Tomasz Kajtoch <tomasz.kajtoch@elastic.co>
Co-authored-by: Tomasz Kajtoch <tomek@kajto.ch>
Co-authored-by: Cee Chen <549407+cee-chen@users.noreply.github.com>
Co-authored-by: Drew Tate <andrew.tate@elastic.co>
## Summary
I was not sure if there are other plans for these stats, but I went
ahead and cleaned those up:
### Issue 1. Sidenav groups are collapsed on a smaller screen
#### Before
#### After
<img width="1456" alt="Screenshot 2023-08-11 at 14 13 23"
src="3e52d05f-12fa-4d38-addb-538239e7d8d1">
### Issue 2. Collapsed sidenav state is empty
We reserved this for icons, but until we have them, I think it makes
sense to just hide the bar:
#### Berfore
#### After
<img width="1456" alt="Screenshot 2023-08-11 at 14 14 35"
src="99adadb4-637b-404b-9909-fe7e78e0224e">
### Issue 3. Navigation is not initialized when Kibana loaded with
hidden navigation
We initialize the navigation as we render the nav tree (the sidenav).
But if the sidenav is hidden, then the navigation is not initialized.
**So, for example, breadcrumbs are not displayed correctly until the nav
is opened.** As a hack, we will always render the tree, but will make it
hidden.
#### Before
<img width="1296" alt="Screenshot 2023-08-11 at 14 35 14"
src="499e4a97-b5c3-405d-968b-bae753f15b99">
#### After
<img width="1296" alt="Screenshot 2023-08-11 at 14 34 37"
src="ae51dea4-8d98-40f6-b3bc-c4d5df8e97fa">
## Summary
This PR adjusts the `data-test-subj` for the global loading indicator in
serverless projects such that at matches the stateful version. This
makes sure that functional tests and corresponding test helper methods
continue to work the same in stateful and serverless environments when
comes to waiting for global loading to finish, which is a key mechanism
to avoid test flakiness.
### Additional information
- The serverless project specific global loading indicator was
introduced with #158523
- The stateful loading indicator `data-test-subj` naming is implemented
here:
https://github.com/elastic/kibana/blob/main/packages/core/chrome/core-chrome-browser-internal/src/ui/loading_indicator.tsx#L61
Co-authored-by: Tim Sullivan <tsullivan@users.noreply.github.com>
## Summary
Closes https://github.com/elastic/kibana/issues/161889
Closes https://github.com/elastic/kibana/issues/162935
This PR gives the correct look and feel to the app menu bar.
1. The bar appears to the right of the side panel
2. The bar has fixed position below the fixed EuiHeader
3. Page content flows after the the bar
### Testing
1. Run `yarn es snapshot` in a terminal pane
2. Run `yarn serverless` in another pane
3. Log into the Kibana UI and check different forms of the menu bar
4. Use the dev-project switcher to test other solution projects
5. Test with a header banner:
```
#!/bin/bash
HOST=http://elastic:changeme@localhost:5601
curl -X POST "$HOST/internal/kibana/settings" \
-H 'kbn-xsrf: true' \
-H 'X-Elastic-Internal-Origin: Kibana' \
-H 'Content-Type: application/json' \
-d '{
"changes": {
"banners:placement": "top",
"banners:textContent": "Prefix. **SIMPLE BANNER MESSAGE CONTENT**.
Suffix."
}
}'
```
Set `banners:placement` to `null` to turn off the header banner.
**Known issue:** in some Observability project pages, the app menu bar
may appear as an empty div. This is explained in the [serverless project
layout
documentation](https://docs.elastic.dev/kibana-dev-docs/serverless-project-navigation#header-action-menu):
> **Note** The display of the toolbar container is conditional, based on
whether there is toolbar content to show. Make sure to pass undefined to
setHeaderActionMenu if there is no application content to show. In
classic layout, passing an empty span or div element suffices to "clear"
the toolbar, but in serverless projects it will cause a large empty
container to show below the header.
### Screenshots
_Will not be updated past a5222e428814c9d2211f4c14fe160dbea93f3e1b_
| | |
|---|---|
| **Project layout in Observability app** |
9fb8f57a-3de9-49e8-9d6d-d10fa83a3c83
|
| **Project layout in Observability app w/ header banner** |
19a0bf68-0df7-4f08-b987-125abe9e5680
|
| **Project layout in Security app** |
af1940fa-9d48-48a4-b675-0b3c8bcffc39
|
| **Project layout in Security app w/ header banner** |
d962952a-1d21-4bb3-8992-cafe4aed82a4
|
### 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
- [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)
---------
Co-authored-by: Cee Chen <549407+cee-chen@users.noreply.github.com>
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
fix https://github.com/elastic/kibana/issues/163337 for dashboard.
### Context:
In serverless navigation we changed how breadcrumbs work. Instead of
setting the full path manually, we automatically calculate the main
parts of the path from the side nav + current URL. This was done to keep
side nav and breadcrumbs in sync as much as possible and solve
consistency issues with breadcrumbs across apps.
https://docs.elastic.dev/kibana-dev-docs/serverless-project-navigation#breadcrumbs
Apps can append custom deeper context using the
`serverless.setBreadcrumbs` api. Regular `core.chrome.setBreadcrumbs`
has no effect when serverless nav is rendered.
## Summary
Unfortunately, #161914 regressed #162365 in that many plugins and their
Emotion styles (including EUI emotion styles) are now missing a cache
and are being appended to to the end of the document `<head>` as opposed
to within `<meta name="emotion">`.
What appears to be happening is many plugins are using a parent
`<KibanaThemeProvider>` but **not** a parent
`<KibanaRootContextProvider>` (not sure if this work is TBD or in
progress). This means that a parent `<EuiProvider>`, (which determines
the cache insertion of child Emotion styled components) is missing,
which is causing several CSS specificity bugs, e.g. around datagrid.
As a somewhat-bandaid-y fix, I've bogarted EUI's nested provider context
to check if the theme provider has a parent `EuiProvider`, and if it
doesn't, to use `KibanaEuiProvider` instead of `KibanaThemeProvider`.
This should set up the caches and context if needed, or otherwise simply
use the original `KibanaThemeProvider` component.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Clint Andrew Hall <clint@clintandrewhall.com>
## Summary
Closes https://github.com/elastic/kibana/issues/160834
This PR fixes a bug with the Dashboard app in serverless projects. The
Dashboard has a "Full screen" button that is intended to cause the
content area of the dashboard take up the entire viewport. To do this,
the dashboard app uses a chrome service to update an observable used in
the rendering of the header, which sets the layout to a "chromeless"
state. The bug is: in serverless, the project header must respect the
chromeless state.
### Testing
1. Run `yarn es snapshot` in one terminal and then `yarn serverless` in
another terminal.
2. Load sample data through the "Integrations" app, which can be found
in Global Search.
3. View a sample data dashboard, and use the `Full screen` button in the
app menu toolbar.
### 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: Christiane (Tina) Heiligers <christiane.heiligers@elastic.co>
## Summary
Closes https://github.com/elastic/kibana/issues/160141
The avatar menu needs to be displayed for serverless. It was previously
required to be hidden in serverless, so a config 'showNavLinks' was
added. This config is no longer needed, so it has been removed.
## Testing
Start KB with the `--serverless` flag and login as `elastic`.
The Avatar should appear in the top right coner.
> Pre-req for https://github.com/elastic/kibana/issues/56406
## Summary
We've had a long-standing problem in Kibana around our use of React
context, particularly with EUI and i18n. There hasn't existed an
idempotent context structure, and that has lead to a lot of unexpected
results, (e.g. missing translations, inconsistent dark mode, excess
context providers, etc).
The biggest change coming from this PR is knowing exactly which provider
to use in a particular use case. This means, for example,
`ReactDOM.render` calls won't be missing `i18n` or `theme` due to a
missing context. It also allows consumers to use `darkMode` without
having to read the `uiSetting` themselves, instead allowing the context
to do it for them.
We also haven't been honoring the intended [`EuiProvider`
API](https://eui.elastic.co/#/utilities/provider#theming-and-global-styles)...
in some cases we've been creating and re-creating the Emotion caches,
often by copy/paste of the cache code. We've also been nesting
`EuiThemeProvider` contexts unnecessarily-- thinking we need to render a
theme provider in an isolated component-- which renders an additional
`span` element into the DOM.
This PR attempts to address this inconsistency by creating a set of
context providers divided by use case:
### `KibanaRootContextProvider`
A root context provider for Kibana. This is the top level context
provider that wraps the entire application. It is responsible for
initializing all of the other contexts and providing them to the
application. It's provided as a package for specific use cases, (e.g.
the `RenderingService`, cases where we replace the entire page content,
Storybook, testing, etc), but not intended for plugins.
### `KibanaRenderContextProvider`
A render context provider for Kibana. This context is designed to be
used with ad-hoc renders of React components, (usually with
`ReactDOM.render`).
### `KibanaThemeContextProvider`
A theme context provider for Kibana. A corollary to EUI's
`EuiThemeProvider`, it uses Kibana services to ensure the EUI Theme is
customized correctly.
### (deprecated) `KibanaStyledComponentsThemeProvider`
A styled components theme provider for Kibana. This package is supplied
for compatibility with legacy code, but should not be used in new code.
## Deprecation strategy
This PR does *not* change any use of context by consumers. It maps the
existing contexts in `kibanaReact` to the new contexts, (along with the
loose API). This means that we won't have completely fixed all of our
dark mode issues yet. But this is necessary to keep this PR focused on
the change, rather than drawing in a lot of teams to review individual
uses.
We should, however, see an immediate performance improvement in the UI
from the reduction in `EuiProvider` calls.
## Open questions
- [ ] Does it make sense to expose a `useTheme` hook from
`@kbn/react-kibana-context-theme` to replace `useEuiTheme`?
## Next steps
- [ ] Update deprecated uses to new contexts.
- [ ] Audit and update calls to `ReactDOM.render`.
- [ ] Add ESLint rule to warn for use of EUI contexts.
- [ ] Delete code from `kibanaReact`.
## Summary
This PR addresses the occasional toast-floods/toast-storms with a simple
catch mechanism: deduplicate/group toasts by their broad alikeness,
their text and title.
This implementation plugs in to the `global_toast_list.tsx` in Kibana's
GlobalToastList component, capturing updates on the toast update stream,
and collapses toasts before passing them further to the downstream EUI
Toast list react components.
The core idea is to not display notifications directly, but to keep the
toast notifications apart from their visual representation. This way, we
can represent more notifications with one toast on our end, if we group
rightly. The only issue then, is to clean up everything nicely when it's
time. For this we're also exporting a mapping that shows which toast ID
represents which grouped toasts.
I also changed the type `ToastInputFields` to accept rendered react
components as title/text - this will prevent attempts to unmount react
components from elements that are not displayed, thus causing React
warnings.
The close-all button is an EUI feature, which we've started discussing
[here](https://github.com/elastic/eui/issues/6945), probably not part of
this PR.
## What toasts get merged?
The exact merging strategy was not settled, and it's kind of a valve,
where we trade off potential detail lost in toasts for the prevented
noise in the toast floods. The current strategy is as folows:
```
* These toasts will be merged:
* - where title and text are strings, and the same (1)
* - where titles are the same, and texts are missing (2)
* - where titles are the same, and the text's mount function is the same string (3)
* - where titles are missing, but the texts are the same string (4)
```
The base merge case is `(1) & (2)`, after some discussion with @Dosant
we decided to include (3) as a compromise, where we're still merging
somewhat similar toasts, and extend the merging to `ToastsApi::addError`
where all error toasts have a MountPoint as their text. We understand
this might hide some details (e.g.: same titles, but very slightly
different MountPoints as their text) but realistically this shouldn't
really happen.
The ultimate future improvement will be (as suggested in the comments by
@jloleysens) a sort of identifier to the toast, based on which we can
group without fear of losing information. But this will require more
work on all the call-sites.
Relates to: #161482
### Checklist
Delete any items that are not applicable to this PR.
- [x] [Unit or functional
tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)
were updated or added to match the most common scenarios
### For maintainers
- [x] This was checked for breaking API changes and was [labeled
appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Bumps node.js to 18.17.0 (replacement for PR #144012 which was later
reverted)
As a result, these categorical additions were needed:
- `node` evocations will need the `--openssl-legacy-provider` flag,
wherever it would use certain crypto functionalities
- tests required updating of the expected HTTPS Agent call arguments,
`noDelay` seems to be a default
- `window.[NAME]` fields cannot be written directly
- some stricter typechecks
This is using our in-house built node.js 18 versions through the URLs
the proxy-cache. (built with
https://github.com/elastic/kibana-custom-nodejs-builds/pull/4)
These urls are served from a bucket, where the RHEL7/Centos7 compatible
node distributables are. (see:
https://github.com/elastic/kibana-ci-proxy-cache/pull/7)
Further todos:
- [x] check docs wording and consistency
- [ ] update the dependency report
- [x] explain custom builds in documentation
- [x] node_sass prebuilts
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
Co-authored-by: Thomas Watson <w@tson.dk>
## Summary
When turning on `server.restrictInternalApis` a number of issues
surfaced due to defaulting to internal resulting in `400`s for:
* HTTP resources
* Static assets via `registerStaticDir`
* Use of `res.render(Html|Js|Css)` outside of HTTP resources
This PR:
* defaults our HTTP resources service to register routes by default
`public`, same for static dirs.
* Did an audit of all renderX usages, if outside of HTTP resources I
added an explicit `access: public`
* ...what else?
### Set `access: 'public'` for known set of "system" routes
Method | Path | Comment
-- | -- | --
GET | /api/status
GET | /api/stats
GET | /translations/{locale}.json
GET | /api/fleet/agent_policies
GET | /api/task_manager/_background_task_utilization
GET | /internal/task_manager/_background_task_utilization
GET | /internal/detection_engine/health/_cluster
POST | /internal/detection_engine/health/_cluster
GET | /internal/detection_engine/health/_space
POST | /internal/detection_engine/health/_space
POST | /internal/detection_engine/health/_rule
POST | /internal/detection_engine/health/_setup
GET | /bootstrap.js
GET | /bootstrap-anonymous.js
GET | \*\*/bundles/\* | Core's routes for serving JS & CSS bundles
## How to test
Run this PR with `kibana.dev.yml` containing
`server.restrictInternalApis: true` and navigate around Kibana UI
checking that there are no `400`s in the network resources tab due to
access restrictions.
## Notes
* Either left a comment about why `access` was set public or a simple
unit test to check that we are setting access for a given route
## To do
- [x] Manually test Kibana
- [x] Manually test with `interactiveSetup` plugin
- [ ] Add integration and e2e test (will do in a follow up PR)
Related: https://github.com/elastic/kibana/pull/162149
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Follow up to https://github.com/elastic/kibana/pull/161592
Some remaining EUI components that are still in Sass unfortunately need
to respect EUI's global CSS utilities (e.g. `.eui-yScroll`,
`.eui-textTruncate` - [full list
here](https://elastic.github.io/eui/#/utilities/css-utility-classes)).
Creating a separate utilities cache and insertion point should solve the
CSS order/specificity issues.
### Checklist
- [x] Confirm Emotion output order is expected in head (EUI globals, All
Emotion styles, Sass styles, then utilities last)
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Add a `buildFavor` property to `Env` (accessible from the plugin's
initializer context), Mimicking the idea of ES's `version.buildFlavor`
field.
Note: this is not supposed to be a replacement for feature flags, but
can be useful when wanting to toggle features based on actual
capabilities of our serverless product. Also, we already expose this
value through the configuration via the `serverless` context value, so
it now adds another way to access the information.
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
close https://github.com/elastic/kibana/issues/160011
This PR adds helpers for testing serverless specific navigation. There
are helpers for sidenav, breadcrumbs, global search, recent items, logo,
checking that no page reload happened during nav.
This PR also adds some serverless specific navigation tests. The should
serve as a navigation smoke check and testing helpers example. Solution
teams can improve them as they see fit.
Partially addresses https://github.com/elastic/kibana/issues/159590
## Summary
This PR adds an an internal uiSettings API that is a duplicate of the
public API and is intended for use by the browser-side uiSettings
client.
The PR also adds a config settings that is configured in serverless
context only and exposes the public uiSettings routes based on the value
of this setting (it defaults to false since we don't want to expose the
public routes in serverless).
**How to test:**
I. Verify that in serverless the internal routes are exposed but the
public ones aren't:
1. Start Es with `yarn es snapshot` and Kibana with `yarn
serverless-{mode}` where `{mode}` can be `es`, `oblt`, or `security`
(the public routes should be disabled for all projects).
2. Verify that the public endpoints are not accessible. For example,
`curl --user elastic:changeme
'http://localhost:5601/zhb/api/kibana/settings' -X 'GET'` should return
`{"statusCode":404,"error":"Not Found","message":"Not Found"}`.
3. Verify that the internal endpoints are accessible. For example, `curl
--user elastic:changeme
'http://localhost:5601/zhb/internal/kibana/settings' -X 'GET'` should
return
`{"settings":{"buildNum":{"userValue":9007199254740991},"isDefaultIndexMigrated":{"userValue":true},"defaultRoute":{"isOverridden":true,"userValue":"/app/elasticsearch"}}}`
II. Verify that the both public and internal routes are exposed in
self-managed:
1. Start Es with `yarn es snapshot` and Kibana with `yarn start`
2. Verify that the public endpoints are accessible. For example, `curl
--user elastic:changeme 'http://localhost:5601/zhb/api/kibana/settings'
-X 'GET'` should return
`{"settings":{"buildNum":{"userValue":9007199254740991},"isDefaultIndexMigrated":{"userValue":true}}}`
3. Verify that the internal endpoints are accessible. For example, `curl
--user elastic:changeme
'http://localhost:5601/zhb/internal/kibana/settings' -X 'GET'` should
return
`{"settings":{"buildNum":{"userValue":9007199254740991},"isDefaultIndexMigrated":{"userValue":true}}}`
III. Verify that the plugins/services that consume the internal
uiSettings endpoints work as expected in both self-managed and
serverless environment.
### 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
Fixing calculated theme tags. An issue found was in the bootstrap
renderer when User Profile's Theme was set to 'Light' and Adv. Setting's
Theme was set to 'Dark'.
In my original PR, I had originally had the UserSettings > darkMode be a
string ('', 'light', 'dark'), but changed it to a boolean | undefined
and the conditional no longer worked.
This should fix a number of sporadic darkmode issues
## Summary
Analyzing the MKI QA logs, I discovered that errors encountered during
shutdown were effectively triggering a second shutdown process, making
the logs unclear:
<img width="1564" alt="Screenshot 2023-07-13 at 16 07 22"
src="8d718a99-2187-4fa3-b6f6-9c3f0e7a3925">
it has the side effect to also make "normals" shutdown (e.g via SIGINT
like in the screenshot) to appear as error shutdowns because of the
error thrown during the shutdown.
This PR addresses it, by making sure that `Root` only shutdown once.
Errors occurring during the shutdown will be appearing in the logs, but
they will not surface as the cause of the shutdown (no `FATAL` log
entry).
## Summary
### Problem
The `HeaderLogo` being used by Kibana's nav isn't actually using the
`<EuiHeaderLogo>` component, it's instead a completely custom logo that
happens to bogart `EuiHeaderLogo`'s CSS styles. When `EuiHeaderLogo` was
recently converted from Sass to Emotion, any styles attached to that CSS
completely disappeared, hence the misaligned appearance below:
### Before
<img width="432" alt=""
src="f28e870c-e407-4c8b-b144-dd65fb27708d">
### After
<img width="443" alt=""
src="8c3ab23d-f942-4473-b7d5-c8c558933eb9">
### Solution
I opted to resolve the bug with the following interim steps:
1. Remove the `euiHeaderLogo` className - it isn't doing anything, and
this isn't an EuiHeaderLogo, so it might as well go
2. Add a `chrHeaderLogo` className (based on the className of a nearby
child element) and reinstate the most relevant CSS (flex alignment and
layout) needed to restore the logo visual behavior
Long-term, fixing `HeaderLogo` to use `EuiHeaderLogo` (this will require
updating `EuiHeaderLogo` to facilitate loading behavior and non-text
children) is probably the better solution, instead of making Kibana use
its own custom logo component.
### Checklist
- [x] Snapshots ~[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)
## Summary
fixes https://github.com/elastic/kibana/issues/161441
fixes https://github.com/elastic/kibana/issues/161464
The recent `EuiButtonEmpty`/`EuiButtonIcon` Emotion conversions have
highlighted a CSS order/specificity flaw in Kibana compared to EUI - EUI
orders its Sass _after_ its Emotion styles (see
https://elastic.github.io/eui/#/), and Kibana orders Sass _before_
Emotion styles.
I'm not totally sure why Greg set up Kibana's style order the way he did
in https://github.com/elastic/kibana/pull/134919, but at this point, EUI
has enough of its baseline atom components converted to Emotion that
remaining components in Sass are all generally molecules or higher level
components that need to come after Emotion.
### QA
- [x] Test as many pages in Kibana as possible to ensure no visual
regressions 🤞
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Fix https://github.com/elastic/kibana/issues/161424
Migrate away from deprecated EUI components for Core-owned code.
Note: I only tested the production (and examples) pages properly, I
didn't make sure the test plugins where displayed correctly, as long as
the data structure was still here for the tests to pass.
### Screenshots
#### Status page
<img width="1388" alt="Screenshot 2023-07-10 at 17 14 24"
src="d15adffa-d4fb-4dab-ad91-691a4c103541">
#### AppNotFound page
<img width="1352" alt="Screenshot 2023-07-10 at 17 14 40"
src="77dcc958-db53-4ec8-9a7f-af4ea0804a96">
#### Generated plugin landing page
<img width="1906" alt="Screenshot 2023-07-10 at 17 15 44"
src="7a45d1a3-181d-44c5-a4a1-d3bdb2ba6ee9">
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Looking at the logs, I realized we were not logging anything in `info`
level when Kibana is starting up or shutting down at the `Root` level,
making it quite awkward when trying to understand when an instance / pod
was started or shut down and even why. Also, we were not logging the
stack trace of the shutdown reason when present.
FWIW, this is (the exhaustive list of) what's displayed in some shutdown
scenarios (most recent to least recent):
<img width="1579" alt="Screenshot 2023-07-11 at 11 41 27"
src="a1a069d1-84ba-4124-aea4-298a70adac58">
As you can see:
1. We have no idea why Kibana was shut down
2. We don't know where this `no element in sequence` error even comes
from
This PR adds a few logs:
- `Kibana is starting` during `bootstrap`
- `Kibana is shutting down` during `shutdown`
- The shutdown reason's stack when provided
- `SIGINT received - initiating shutdown` and `SIGTERM received -
initiating shutdown` when receiving the associated signals
## Summary
Updated the Kibana collapsible nav Enterprise Search category to Search.
Updated the App Search & Workplace Search app navLinkStatuses to
`hidden` to remove them from the Kibana nav.
### Screenshots
<img width="270" alt="image"
src="1397e701-ca87-46f2-8c15-565bc3a9202c">
