# Backport
This will backport the following commits from `main` to `8.16`:
- [[SO migration] Move to previous step in update mappings wait when it
fails with search_phase_execution_exception
(#216693)](https://github.com/elastic/kibana/pull/216693)
<!--- Backport version: 9.6.6 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)
<!--BACKPORT [{"author":{"name":"Jesus
Wahrman","email":"41008968+jesuswr@users.noreply.github.com"},"sourceCommit":{"committedDate":"2025-04-04T13:37:06Z","message":"[SO
migration] Move to previous step in update mappings wait when it fails
with search_phase_execution_exception (#216693)\n\n##
Summary\n\nResolves
https://github.com/elastic/kibana/issues/207096\n\nThis continues the
work in https://github.com/elastic/kibana/pull/213979\n\nSometimes ES
returns a 200 response containing an error field when we\nwait for the
update mappings task. This case wasn't being handled. This\nPR handles
that case, when we find a `search_phase_execution_exception`\nin the ES
response we return a retryable error that sends us back to the\nupdate
mappings state. It does it for both migration algorithms, the\npriority
is ZDT but seemed like a nice to have in both.\n\n### Checklist\n\nCheck
the PR satisfies following conditions. \n\nReviewers should verify this
PR satisfies this list as well.\n\n- [x] [Unit or
functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere
updated or added to match the most common scenarios\n- [x] The PR
description includes the appropriate Release Notes section,\nand the
correct `release_note:*` label is applied per
the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"49380143432b654cf1b849d8c77b3abc2fb3aeb4","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Core","release_note:skip","backport:prev-major","backport:current-major","v9.1.0"],"title":"[SO
migration] Move to previous step in update mappings wait when it fails
with
search_phase_execution_exception","number":216693,"url":"https://github.com/elastic/kibana/pull/216693","mergeCommit":{"message":"[SO
migration] Move to previous step in update mappings wait when it fails
with search_phase_execution_exception (#216693)\n\n##
Summary\n\nResolves
https://github.com/elastic/kibana/issues/207096\n\nThis continues the
work in https://github.com/elastic/kibana/pull/213979\n\nSometimes ES
returns a 200 response containing an error field when we\nwait for the
update mappings task. This case wasn't being handled. This\nPR handles
that case, when we find a `search_phase_execution_exception`\nin the ES
response we return a retryable error that sends us back to the\nupdate
mappings state. It does it for both migration algorithms, the\npriority
is ZDT but seemed like a nice to have in both.\n\n### Checklist\n\nCheck
the PR satisfies following conditions. \n\nReviewers should verify this
PR satisfies this list as well.\n\n- [x] [Unit or
functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere
updated or added to match the most common scenarios\n- [x] The PR
description includes the appropriate Release Notes section,\nand the
correct `release_note:*` label is applied per
the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"49380143432b654cf1b849d8c77b3abc2fb3aeb4"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/216693","number":216693,"mergeCommit":{"message":"[SO
migration] Move to previous step in update mappings wait when it fails
with search_phase_execution_exception (#216693)\n\n##
Summary\n\nResolves
https://github.com/elastic/kibana/issues/207096\n\nThis continues the
work in https://github.com/elastic/kibana/pull/213979\n\nSometimes ES
returns a 200 response containing an error field when we\nwait for the
update mappings task. This case wasn't being handled. This\nPR handles
that case, when we find a `search_phase_execution_exception`\nin the ES
response we return a retryable error that sends us back to the\nupdate
mappings state. It does it for both migration algorithms, the\npriority
is ZDT but seemed like a nice to have in both.\n\n### Checklist\n\nCheck
the PR satisfies following conditions. \n\nReviewers should verify this
PR satisfies this list as well.\n\n- [x] [Unit or
functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere
updated or added to match the most common scenarios\n- [x] The PR
description includes the appropriate Release Notes section,\nand the
correct `release_note:*` label is applied per
the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"49380143432b654cf1b849d8c77b3abc2fb3aeb4"}}]}]
BACKPORT-->
Co-authored-by: Jesus Wahrman <41008968+jesuswr@users.noreply.github.com>
# Backport
This will backport the following commits from `main` to `8.16`:
- [Zdt retry on common failures
(#213979)](https://github.com/elastic/kibana/pull/213979)
<!--- Backport version: 9.6.6 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sorenlouv/backport)
<!--BACKPORT [{"author":{"name":"Jesus
Wahrman","email":"41008968+jesuswr@users.noreply.github.com"},"sourceCommit":{"committedDate":"2025-03-12T09:10:47Z","message":"Zdt
retry on common failures (#213979)\n\n## Summary\n\nresolves
https://github.com/elastic/kibana/issues/207096\n\nAdded a new handler
to `readWithPit`, `pickupUpdatedMappings` and\n`checkForUnknownDocs`.
This handler retries when it receives an error\nresponse including
`type: search_phase_execution_exception`.\n\n\n### Checklist\n\nCheck
the PR satisfies following conditions. \n\nReviewers should verify this
PR satisfies this list as well.\n\n- [x] [Unit or
functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere
updated or added to match the most common scenarios\n- [x] The PR
description includes the appropriate Release Notes section,\nand the
correct `release_note:*` label is applied per
the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"68b2bde0b032efb2fab3e8a30a7d5a9e0b601f7e","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:Saved
Objects","release_note:skip","backport:prev-major","Epic:ZDTmigrations","v9.1.0"],"title":"Zdt
retry on common
failures","number":213979,"url":"https://github.com/elastic/kibana/pull/213979","mergeCommit":{"message":"Zdt
retry on common failures (#213979)\n\n## Summary\n\nresolves
https://github.com/elastic/kibana/issues/207096\n\nAdded a new handler
to `readWithPit`, `pickupUpdatedMappings` and\n`checkForUnknownDocs`.
This handler retries when it receives an error\nresponse including
`type: search_phase_execution_exception`.\n\n\n### Checklist\n\nCheck
the PR satisfies following conditions. \n\nReviewers should verify this
PR satisfies this list as well.\n\n- [x] [Unit or
functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere
updated or added to match the most common scenarios\n- [x] The PR
description includes the appropriate Release Notes section,\nand the
correct `release_note:*` label is applied per
the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"68b2bde0b032efb2fab3e8a30a7d5a9e0b601f7e"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/213979","number":213979,"mergeCommit":{"message":"Zdt
retry on common failures (#213979)\n\n## Summary\n\nresolves
https://github.com/elastic/kibana/issues/207096\n\nAdded a new handler
to `readWithPit`, `pickupUpdatedMappings` and\n`checkForUnknownDocs`.
This handler retries when it receives an error\nresponse including
`type: search_phase_execution_exception`.\n\n\n### Checklist\n\nCheck
the PR satisfies following conditions. \n\nReviewers should verify this
PR satisfies this list as well.\n\n- [x] [Unit or
functional\ntests](https://www.elastic.co/guide/en/kibana/master/development-tests.html)\nwere
updated or added to match the most common scenarios\n- [x] The PR
description includes the appropriate Release Notes section,\nand the
correct `release_note:*` label is applied per
the\n[guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process)","sha":"68b2bde0b032efb2fab3e8a30a7d5a9e0b601f7e"}}]}]
BACKPORT-->
Co-authored-by: Jesus Wahrman <41008968+jesuswr@users.noreply.github.com>
# Backport
This will backport the following commits from `main` to `8.16`:
- [[docs] Remove experimental message from saved objects import and
export apis (#202173)](https://github.com/elastic/kibana/pull/202173)
<!--- Backport version: 9.4.3 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT [{"author":{"name":"Jesus
Wahrman","email":"41008968+jesuswr@users.noreply.github.com"},"sourceCommit":{"committedDate":"2024-12-02T11:05:52Z","message":"[docs]
Remove experimental message from saved objects import and export apis
(#202173)\n\n## Summary\r\n\r\nresolves
https://github.com/elastic/kibana/issues/159454\r\n\r\nRemove
experimental message from saved objects import and export
apis.\r\n\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following
conditions. \r\n\r\nReviewers should verify this PR satisfies this list
as well.\r\n\r\n-
[x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n\r\n###
Identify risks\r\n\r\nDoes this PR introduce any risks? For example,
consider risks like hard\r\nto test bugs, performance regression,
potential of data loss.\r\n\r\nDescribe the risk, its severity, and
mitigation for each identified\r\nrisk. Invite stakeholders and evaluate
how to proceed before merging.\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"9b99070470869ba390924cf64745771b6b143377","branchLabelMapping":{"^v9.0.0$":"main","^v8.18.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:skip","v9.0.0","docs","backport:version","v8.17.0","v8.18.0","v8.16.2","v8.15.6"],"title":"[docs]
Remove experimental message from saved objects import and export
apis","number":202173,"url":"https://github.com/elastic/kibana/pull/202173","mergeCommit":{"message":"[docs]
Remove experimental message from saved objects import and export apis
(#202173)\n\n## Summary\r\n\r\nresolves
https://github.com/elastic/kibana/issues/159454\r\n\r\nRemove
experimental message from saved objects import and export
apis.\r\n\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following
conditions. \r\n\r\nReviewers should verify this PR satisfies this list
as well.\r\n\r\n-
[x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n\r\n###
Identify risks\r\n\r\nDoes this PR introduce any risks? For example,
consider risks like hard\r\nto test bugs, performance regression,
potential of data loss.\r\n\r\nDescribe the risk, its severity, and
mitigation for each identified\r\nrisk. Invite stakeholders and evaluate
how to proceed before merging.\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"9b99070470869ba390924cf64745771b6b143377"}},"sourceBranch":"main","suggestedTargetBranches":["8.17","8.x","8.16","8.15"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/202173","number":202173,"mergeCommit":{"message":"[docs]
Remove experimental message from saved objects import and export apis
(#202173)\n\n## Summary\r\n\r\nresolves
https://github.com/elastic/kibana/issues/159454\r\n\r\nRemove
experimental message from saved objects import and export
apis.\r\n\r\n\r\n### Checklist\r\n\r\nCheck the PR satisfies following
conditions. \r\n\r\nReviewers should verify this PR satisfies this list
as well.\r\n\r\n-
[x]\r\n[Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html)\r\nwas
added for features that require explanation or tutorials\r\n\r\n###
Identify risks\r\n\r\nDoes this PR introduce any risks? For example,
consider risks like hard\r\nto test bugs, performance regression,
potential of data loss.\r\n\r\nDescribe the risk, its severity, and
mitigation for each identified\r\nrisk. Invite stakeholders and evaluate
how to proceed before merging.\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<42973632+kibanamachine@users.noreply.github.com>\r\nCo-authored-by:
Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"9b99070470869ba390924cf64745771b6b143377"}},{"branch":"8.17","label":"v8.17.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.x","label":"v8.18.0","branchLabelMappingKey":"^v8.18.0$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.16","label":"v8.16.2","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.15","label":"v8.15.6","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
# Backport
This will backport the following commits from `main` to `8.16`:
- [Fix issue with duplicate references in error object when copying
saved objects to space
(#200053)](https://github.com/elastic/kibana/pull/200053)
<!--- Backport version: 9.4.3 -->
### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)
<!--BACKPORT
[{"author":{"name":"Sid","email":"siddharthmantri1@gmail.com"},"sourceCommit":{"committedDate":"2024-11-18T15:46:07Z","message":"Fix
issue with duplicate references in error object when copying saved
objects to space (#200053)\n\nCloses
https://github.com/elastic/kibana/issues/158027\r\n\r\n##
Summary\r\n\r\nSimply dedupes references to objects if they are part of
the\r\nmissing_references in the copy saved objects to SO
endpoint\r\n\r\n### Notes\r\n- Update forEach over SOs to a regular for
loop since we had a couple of\r\nearly exit scenarios\r\n- Checks
against the set for references already added to the missing\r\nlist and
adds only if not present\r\n\r\n------\r\n\r\n**Old response: Note the
duplicate references**\r\n\r\n<img width=\"400\" alt=\"Screenshot
2024-11-14 at 01 52
54\"\r\nsrc=\"https://github.com/user-attachments/assets/67078080-e39d-43b2-bf7c-7abb76866fa4\">\r\n\r\n\r\n**New
response**\r\n\r\n<img width=\"800\" alt=\"Screenshot 2024-11-14 at 01
50
41\"\r\nsrc=\"https://github.com/user-attachments/assets/776db189-af8c-4522-bb03-f8efbb7cdcd9\">\r\n\r\n\r\n###
Release note\r\nDedupe results from copy saved objects to spaces API
when object\r\ncontains references to other
objects.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"262b48f1cf4d4f624be99c2f42d169e4ab1f1f44","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","release_note:fix","Team:Security","Feature:Saved
Objects","v9.0.0","backport:prev-minor","backport:prev-major","v8.17.0"],"title":"Fix
issue with duplicate references in error object when copying saved
objects to
space","number":200053,"url":"https://github.com/elastic/kibana/pull/200053","mergeCommit":{"message":"Fix
issue with duplicate references in error object when copying saved
objects to space (#200053)\n\nCloses
https://github.com/elastic/kibana/issues/158027\r\n\r\n##
Summary\r\n\r\nSimply dedupes references to objects if they are part of
the\r\nmissing_references in the copy saved objects to SO
endpoint\r\n\r\n### Notes\r\n- Update forEach over SOs to a regular for
loop since we had a couple of\r\nearly exit scenarios\r\n- Checks
against the set for references already added to the missing\r\nlist and
adds only if not present\r\n\r\n------\r\n\r\n**Old response: Note the
duplicate references**\r\n\r\n<img width=\"400\" alt=\"Screenshot
2024-11-14 at 01 52
54\"\r\nsrc=\"https://github.com/user-attachments/assets/67078080-e39d-43b2-bf7c-7abb76866fa4\">\r\n\r\n\r\n**New
response**\r\n\r\n<img width=\"800\" alt=\"Screenshot 2024-11-14 at 01
50
41\"\r\nsrc=\"https://github.com/user-attachments/assets/776db189-af8c-4522-bb03-f8efbb7cdcd9\">\r\n\r\n\r\n###
Release note\r\nDedupe results from copy saved objects to spaces API
when object\r\ncontains references to other
objects.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"262b48f1cf4d4f624be99c2f42d169e4ab1f1f44"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/200053","number":200053,"mergeCommit":{"message":"Fix
issue with duplicate references in error object when copying saved
objects to space (#200053)\n\nCloses
https://github.com/elastic/kibana/issues/158027\r\n\r\n##
Summary\r\n\r\nSimply dedupes references to objects if they are part of
the\r\nmissing_references in the copy saved objects to SO
endpoint\r\n\r\n### Notes\r\n- Update forEach over SOs to a regular for
loop since we had a couple of\r\nearly exit scenarios\r\n- Checks
against the set for references already added to the missing\r\nlist and
adds only if not present\r\n\r\n------\r\n\r\n**Old response: Note the
duplicate references**\r\n\r\n<img width=\"400\" alt=\"Screenshot
2024-11-14 at 01 52
54\"\r\nsrc=\"https://github.com/user-attachments/assets/67078080-e39d-43b2-bf7c-7abb76866fa4\">\r\n\r\n\r\n**New
response**\r\n\r\n<img width=\"800\" alt=\"Screenshot 2024-11-14 at 01
50
41\"\r\nsrc=\"https://github.com/user-attachments/assets/776db189-af8c-4522-bb03-f8efbb7cdcd9\">\r\n\r\n\r\n###
Release note\r\nDedupe results from copy saved objects to spaces API
when object\r\ncontains references to other
objects.\r\n\r\n---------\r\n\r\nCo-authored-by: Elastic Machine
<elasticmachine@users.noreply.github.com>","sha":"262b48f1cf4d4f624be99c2f42d169e4ab1f1f44"}},{"branch":"8.x","label":"v8.17.0","branchLabelMappingKey":"^v8.17.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
Co-authored-by: Sid <siddharthmantri1@gmail.com>
# Backport
This will backport the following commits from `main` to `8.16`:
- [Use more efficient strategies to process user input
(#196858)](https://github.com/elastic/kibana/pull/196858)
<!--- Backport version: 9.4.3 -->
### 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":"2024-10-22T12:07:25Z","message":"Use
more efficient strategies to process user input (#196858)\n\n##
Summary\r\n\r\nAddress performance concerns with
Regexps","sha":"c9637cf71c97e2290db57302d54b90caffb6b1bf","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Core","release_note:skip","v9.0.0","backport:all-open"],"title":"Use
more efficient strategies to process user
input","number":196858,"url":"https://github.com/elastic/kibana/pull/196858","mergeCommit":{"message":"Use
more efficient strategies to process user input (#196858)\n\n##
Summary\r\n\r\nAddress performance concerns with
Regexps","sha":"c9637cf71c97e2290db57302d54b90caffb6b1bf"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/196858","number":196858,"mergeCommit":{"message":"Use
more efficient strategies to process user input (#196858)\n\n##
Summary\r\n\r\nAddress performance concerns with
Regexps","sha":"c9637cf71c97e2290db57302d54b90caffb6b1bf"}}]}]
BACKPORT-->
Co-authored-by: Gerard Soldevila <gerard.soldevila@elastic.co>
# Backport
This will backport the following commits from `main` to `8.16`:
- [Update mappings if/when new SO types are introduced
(#197061)](https://github.com/elastic/kibana/pull/197061)
<!--- Backport version: 9.4.3 -->
### 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":"2024-10-24T08:21:43Z","message":"Update
mappings if/when new SO types are introduced (#197061)\n\n##
Summary\r\n\r\nAddresses
https://github.com/elastic/elastic-entity-model/issues/70\r\nFixes
regression introduced
in\r\nhttps://github.com/elastic/kibana/pull/176803","sha":"8de3636e43be7c874b2c3457f1496a0fc31f224d","branchLabelMapping":{"^v9.0.0$":"main","^v8.17.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["bug","Team:Core","release_note:skip","v9.0.0","backport:prev-minor","backport:prev-major","v8.16.0","v8.15.3"],"title":"Update
mappings if/when new SO types are
introduced","number":197061,"url":"https://github.com/elastic/kibana/pull/197061","mergeCommit":{"message":"Update
mappings if/when new SO types are introduced (#197061)\n\n##
Summary\r\n\r\nAddresses
https://github.com/elastic/elastic-entity-model/issues/70\r\nFixes
regression introduced
in\r\nhttps://github.com/elastic/kibana/pull/176803","sha":"8de3636e43be7c874b2c3457f1496a0fc31f224d"}},"sourceBranch":"main","suggestedTargetBranches":["8.16","8.15"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/197061","number":197061,"mergeCommit":{"message":"Update
mappings if/when new SO types are introduced (#197061)\n\n##
Summary\r\n\r\nAddresses
https://github.com/elastic/elastic-entity-model/issues/70\r\nFixes
regression introduced
in\r\nhttps://github.com/elastic/kibana/pull/176803","sha":"8de3636e43be7c874b2c3457f1496a0fc31f224d"}},{"branch":"8.16","label":"v8.16.0","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.15","label":"v8.15.3","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
Co-authored-by: Gerard Soldevila <gerard.soldevila@elastic.co>
# Backport
This will backport the following commits from `main` to `8.x`:
- [[HTTP] Set explicit access for `public` HTTP APIs
(#192554)](https://github.com/elastic/kibana/pull/192554)
<!--- Backport version: 9.4.3 -->
### 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":"2024-09-23T14:53:31Z","message":"[HTTP]
Set explicit access for `public` HTTP APIs (#192554)\n\n##
Summary\r\n\r\nWe will be enforcing restricted access to internal HTTP
APIs [from\r\n9.0](https://github.com/elastic/kibana/issues/186781).
This PR is part 1\r\nof audit checking that our public APIs have their
access tag set\r\nexplicitly to ensure they are still available to end
users after we\r\nstart enforcing HTTP API restrictions. APIs reviewed
in this
PR\r\n([docs](https://www.elastic.co/guide/en/kibana/current/dashboard-import-api.html)):\r\n\r\n<img
width=\"260\" alt=\"Screenshot 2024-09-11 at 11 25
55\"\r\nsrc=\"https://github.com/user-attachments/assets/499b1f1f-8e01-4463-9410-4500e438cd23\">\r\n\r\n##
Note to reviewers\r\n\r\nThis audit is focussed on set `access:
'public'` where needed. Per the\r\nscreenshot our public-facing
documentation is taken as the source of\r\ntruth for which APIs should
be public. This may differ per offering so\r\nplease consider whether a
given HTTP API should be public on both\r\nserverless and stateful
offerings.\r\n\r\n## Risks\r\n\r\n* If we miss an API that should be
public, end users will encounter a\r\n`400` response when they try to
use the HTTP API on 9.0\r\n* If we set an API's access to \"public\" it
will not have the same\r\nrestrictions applied to
it.","sha":"3fa5bdf8732101812a656ec954e2a8d779838938","branchLabelMapping":{"^v9.0.0$":"main","^v8.16.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Feature:http","Team:Core","release_note:skip","v9.0.0","v8.16.0","backport:version"],"title":"[HTTP]
Set explicit access for `public` HTTP
APIs","number":192554,"url":"https://github.com/elastic/kibana/pull/192554","mergeCommit":{"message":"[HTTP]
Set explicit access for `public` HTTP APIs (#192554)\n\n##
Summary\r\n\r\nWe will be enforcing restricted access to internal HTTP
APIs [from\r\n9.0](https://github.com/elastic/kibana/issues/186781).
This PR is part 1\r\nof audit checking that our public APIs have their
access tag set\r\nexplicitly to ensure they are still available to end
users after we\r\nstart enforcing HTTP API restrictions. APIs reviewed
in this
PR\r\n([docs](https://www.elastic.co/guide/en/kibana/current/dashboard-import-api.html)):\r\n\r\n<img
width=\"260\" alt=\"Screenshot 2024-09-11 at 11 25
55\"\r\nsrc=\"https://github.com/user-attachments/assets/499b1f1f-8e01-4463-9410-4500e438cd23\">\r\n\r\n##
Note to reviewers\r\n\r\nThis audit is focussed on set `access:
'public'` where needed. Per the\r\nscreenshot our public-facing
documentation is taken as the source of\r\ntruth for which APIs should
be public. This may differ per offering so\r\nplease consider whether a
given HTTP API should be public on both\r\nserverless and stateful
offerings.\r\n\r\n## Risks\r\n\r\n* If we miss an API that should be
public, end users will encounter a\r\n`400` response when they try to
use the HTTP API on 9.0\r\n* If we set an API's access to \"public\" it
will not have the same\r\nrestrictions applied to
it.","sha":"3fa5bdf8732101812a656ec954e2a8d779838938"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.0.0","branchLabelMappingKey":"^v9.0.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/192554","number":192554,"mergeCommit":{"message":"[HTTP]
Set explicit access for `public` HTTP APIs (#192554)\n\n##
Summary\r\n\r\nWe will be enforcing restricted access to internal HTTP
APIs [from\r\n9.0](https://github.com/elastic/kibana/issues/186781).
This PR is part 1\r\nof audit checking that our public APIs have their
access tag set\r\nexplicitly to ensure they are still available to end
users after we\r\nstart enforcing HTTP API restrictions. APIs reviewed
in this
PR\r\n([docs](https://www.elastic.co/guide/en/kibana/current/dashboard-import-api.html)):\r\n\r\n<img
width=\"260\" alt=\"Screenshot 2024-09-11 at 11 25
55\"\r\nsrc=\"https://github.com/user-attachments/assets/499b1f1f-8e01-4463-9410-4500e438cd23\">\r\n\r\n##
Note to reviewers\r\n\r\nThis audit is focussed on set `access:
'public'` where needed. Per the\r\nscreenshot our public-facing
documentation is taken as the source of\r\ntruth for which APIs should
be public. This may differ per offering so\r\nplease consider whether a
given HTTP API should be public on both\r\nserverless and stateful
offerings.\r\n\r\n## Risks\r\n\r\n* If we miss an API that should be
public, end users will encounter a\r\n`400` response when they try to
use the HTTP API on 9.0\r\n* If we set an API's access to \"public\" it
will not have the same\r\nrestrictions applied to
it.","sha":"3fa5bdf8732101812a656ec954e2a8d779838938"}},{"branch":"8.x","label":"v8.16.0","branchLabelMappingKey":"^v8.16.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
Co-authored-by: Jean-Louis Leysens <jeanlouis.leysens@elastic.co>
## 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
Part of https://github.com/elastic/kibana/issues/186530
Follow-up of https://github.com/elastic/kibana/pull/187064
The goal of this PR is to provide the necessary means to allow
implementing the [Counting
views](https://docs.google.com/document/d/1W77qoweixcjrq0sEKh_LjIk3j33Xyy9umod9mG9BlOM/edit)
part of the _Dashboards++_ initiative.
We do this by extending the capabilities of the _usage counters_ APIs:
* We support custom retention periods. Currently data is only kept in SO
indices for 5 days. Having 90 days worth of counting was required for
Dashboards++.
* We expose a Search API that will allow retrieving persisted counters.
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## 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
Part of https://github.com/elastic/kibana/issues/186530.
This PR sets the basis for allowing namespaced usage counters.
It relocates `usage-counters` SO type from `.kibana` to a dedicated
`.kibana_usage_counters`.
Furthermore, the original SO type is removed, and replaced by 2 separate
types:
* `server-counters`
* `ui-counters`
Note that these 2 steps are necessary if we want to leverage
`namespaces` property of the saved objects.
We can't currently update the `namespaceType: 'agnostic'` without
causing a migration.
Thus, these two types will be defined as `namespaceType: single`.
Up until now, UI counters were stored under a special `domainId:
uiCounter`.
This forced a workaround that consisted in storing `appName:eventName`
in the `counterName` property of the SO.
Having a dedicated SO type for them allows to store `appName` as
`domainId`, avoiding the need for a
[workaround](https://github.com/elastic/kibana/blob/main/src/plugins/usage_collection/common/ui_counters.ts).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Reopening https://github.com/elastic/kibana/pull/186326 with my account,
non-internal PRs are just terrible to work with
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Tiago Costa <tiago.costa@elastic.co>
Co-authored-by: Aleh Zasypkin <aleh.zasypkin@elastic.co>
## Summary
Addresses https://github.com/elastic/kibana/issues/177831.
The PR introduces specific steps to check that
`cluster.routing.allocation.enable` has a suitable value for _reindex
migrations_.
Up until now, this check was done systematically after the `INIT` step.
Now, a couple new dedicated steps have been introduced, which allow
verifying this setting on _reindex migrations_ only (highlighted in
orange):
## Summary
Addresses https://github.com/elastic/kibana/issues/185918
The idea is to simply check whether the index that a migrator is trying
to `write_block` (aka the source of the reindex operation) matches the
target index name. In this case:
* We assume that other migrators are half way through, ahead of us.
* We abort operation and trust other instances' migrators to finish the
job.
* Subsequent restart, when migration has finished, should basically be a
no-op.
## Summary
We recently "discovered" that ES calls performed from the SOR were not
having the default retry mechanism used by the ES client.
This is caused by the way we construct the ES client wrapper used for
the SOR, that forces the `maxRetries` option to `0`
8911bfabb0/packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/repository_es_client.ts (L38-L40)
I initially tried to fully get rid of `retryCallCluster` in
https://github.com/elastic/kibana/pull/184658, as we assumed that
re-enabling the retry mechanism would be sufficient, but this was
causing flakiness in test suites (uncaught rejections in plugins not
properly stopping after ES and Kibana are shut down, with
`NoLivingConnectionsError` errors...)
So instead, I just re-enabled the ES client native mechanism by removing
the `maxRetries` override.
## Summary
Closes https://github.com/elastic/ingest-dev/issues/3252
## Add integration
Added warning to Add integration when the integration requires root
privilege and the selected existing agent policy has unprivileged agents
enrolled.
To verify:
- enroll an agent with docker (it has unprivileged: true)
- try to add an integration that requires root e.g. auditd_manager
- verify that when trying to save the integration, the warning callout
is part of the confirm deploy modal
<img width="807" alt="image"
src="420da729-a4f4-4861-9767-001699629397">
## Add agent flyout
Added warning to Add agent flyout when an unprivileged agent is detected
in combination with an agent policy that has integrations requiring root
To verify:
- add an integration to an agent policy that requires root e.g.
auditd_manager
- open Add agent flyout, verify that the warning callout is visible
<img width="1273" alt="image"
src="e4ae1d73-358b-4d3c-9ca0-27e88bc734a6">
### Open question:
- Do we want to show the warning on `Add agent flyout` only for newly
enrolled agents (in the last 10 mins like we query enrolled agents), or
any unprivileged agents that are enrolled to this policy?
- Decision: No longer applicable as we decided to not show a count here
### 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: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
This pull request introduces a new SO used for keeping relations between
artifactId and policyId. It addresses an issue where some users found
the single SO structure containing too many nested entries. Originally,
we planned to rewrite the existing Manifest Manager. However, during the
POC implementation, it became clear that the effort required to refactor
and retest the existing solution would be substantial. Therefore, this
pull request can be considered as the first step in transitioning our
approach from one SO to this new, distributed one.
The main idea behind these changes is to modify the structure of the SO,
rather than the logic of the Manifest Manager. To accomplish this, we
need to retrieve the SO from the new source, translate it into the
existing SO format (many SOs to one), execute the unchanged operations
of the Manifest Manager on artifacts, translate the resulting SO into
multiple SOs, and save them.
This change is expected to be deployed with a Feature Flag, and we need
to ensure that everything continues to function correctly in both cases.
Therefore, I've introduced a new FTR suite with the Feature Flag
enabled, which should be run alongside tests with the Feature Flag
disabled. This suite contains duplicated test files that depend on SO
logic. When we activate the Feature Flag, these tests should replace the
existing ones, as the Unified Manifest SO will become the default
approach.
It appears that there is no need to introduce any kind of migrations, as
the Manifest Manager is capable of recreating missing SOs (which has
been tested).
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
Follow-up of #176803
Now that `8.14` has been branched and it is about to be released, we can
remove the test that ensures the `HASH_TO_VERSION_MAP` is aligned.
This PR also rolls back a few changes on the map that shouldn't have
been performed, as they belong to `8.15.0`.
## Summary
Fix https://github.com/elastic/kibana/issues/183112
Add a new `mergeAttributes` option for both `update` and `bulkUpdate`,
which, when set to `false`, allows to perform a "full" update (fully
replacing the current attributes of the document) instead of a "partial"
one (merging the attributes).
Technically, ES doesn't really support it, so it was only made possible
due to the "client-side" update we implemented for ZDT / SO version BWC.
Closes https://github.com/elastic/kibana/issues/180377
## Summary
Add a new `support_agentless` property in agent policy and in
preconfiguration; this property is only allowed when the environment has
both `isServerless` set to `true` and `agentless` feature flag enabled,
otherwise policy creation/update will throw error `supports_agentless is
only allowed in serverless environments that support agentless feature`.
No UI change is required for now as this property will be needed as part
of a wider support to agentless policies.
## Testing
### Serverless
- Run serverless env configured for agentless following [this
guide](https://docs.elastic.dev/security-solution/cloud-security/serverless/develop-for-kibana#agentless-local-set-up)
- Make sure to have `agentless` feature flag enabled
- Create an agent policy with `support_agentless` property:
```
POST kbn:/api/fleet/agent_policies
{
"name": "New agent policy",
"namespace": "default",
"supports_agentless": true
}
```
- Update an existing agent policy with the new property:
```
PUT kbn:/api/fleet/agent_policies/<opolicy_id>
{
"name": "New agent policy",
"supports_agentless": true
}
```
- Create a preconfigured agent policy in kibana.dev.yml, and verify it
that it's correct via `GET kbn:/api/fleet/agent_policies`:
```
xpack.fleet.agentPolicies: [
{
"name": "Agentless Policy",
"id": "agentless",
"is_managed": true,
"namespace": "default",
"supports_agentless": true,
},
]
```
- Note that if `agentless` feature flag is disabled, any of the above
will throw an error.
### Stateful
Spin up a stateful env and verify that all of the previous commands fail
with `400` and above error message.
### Checklist
- [ ]
[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
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Closes https://github.com/elastic/kibana/issues/177323
## Summary
Allow to override `inputs` in `PUT package_policies/:id` endpoint. This
functionality will be useful for support and troubleshooting purposes,
but it shouldn't be used in place of normal updates to the policies.
- `inputs` parameters are saved in package policy SO `overrides` field
and then
[merged](https://github.com/elastic/kibana/pull/181453/files#diff-ee6c1fe752205768ab54e6107a869041bcbb6130a0c982fa169bf5aba570a30eR84)
to the full agent policy
- `compiled_streams` and `compiled_inputs` are not allowed
Example with an Nginx policy:
```
PUT kbn:/api/fleet/package_policies/d4fd9578-534f-4e1a-bc75-dfbd4ff0aa14
{
"overrides": {
"inputs": {
"logfile-system-d4fd9578-534f-4e1a-bc75-dfbd4ff0aa14": {
"log_level": "debug"
}
}
}
}
```
Result in full agent policy:
### Checklist
- [ ]
[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
---------
Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR attempts to make it easier to quantity the time we're spending
waiting on ES during Kibana startup.
- Add a log entry once successfully connected to ES, surfacing the info
of how much time we waited.
- Add two new metric to our `kibana_started` event:
- the time we spent waiting for ES
- the time it took to perform the SO migration
Note that for "BWC" reasons (primarily - and simplicity's sake too)
we've not subtracting the time we spent from the `start` lifecycle
timing we already had.
## Summary
Part of https://github.com/elastic/kibana/issues/169547
View docs at [Changed
pages](https://kibana_169928.docs-preview.app.elstc.co/diff)
Add monitor api public api
### Testing
Make sure you have some monitors populated before testing this PR and
before switching to the branch
- [ ] Try editing already added monitors via API
- [ ] Test adding monitors via API, and then edit those via and
subsqeuently try editing via API the same monitor
- [ ] Test editing monitors via API
- [ ] Test deleting monitors via API
- [ ] Test getting monitors via API
- [ ] Testing private as well public locations
Basic workflow that i am interesting in testing is to make sure, you can
add/edit via both API and UI without any issues
Test each of HTTP/TCP/ICMP browser examples
<img width="1728" alt="image"
src="3575d93a-5f04-4c80-ac62-038643f466f8">
---------
Co-authored-by: Justin Kambic <jk@elastic.co>
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Dominique Clarke <dominique.clarke@elastic.co>
## Summary
Follow up on https://github.com/elastic/kibana/pull/170539
Related to https://github.com/elastic/ingest-dev/issues/2471 (Phase 1)
Dynamically creating settings fields from configuration.
These settings are saved in the agent policy SO's `advanced_settings`
field.
In the current pr the agent policy read/create/update works including
the UI.
It still has to be extended to support a few more type of settings: e.g.
dropdown values, settings consisting of multiple fields.
<img width="2212" alt="image"
src="c2ee7187-41bf-42a4-8a22-f43ea8ccfb8c">
These settings are added to the full agent policy agents section:
<img width="687" alt="image"
src="05e244f3-148c-4c88-9b9c-fd665fd0154c">
## Old description:
Add support for saved object mapping and api field name,
## Example API calls and full policy generation
<img width="600" alt="Screenshot 2024-04-02 at 3 54 35 PM"
src="ee2ea087-3e02-4351-9138-c56ace1d5b34">
<img width="500" alt="Screenshot 2024-04-02 at 4 13 42 PM"
src="97514b2e-ef39-475e-8a88-1204ce2c0cda">
<img width="600" alt="Screenshot 2024-04-02 at 4 13 54 PM"
src="6553e133-ea07-48b5-b0ec-c45861b9b246">
<img width="600" alt="Screenshot 2024-04-02 at 5 42 27 PM"
src="faa560fd-7303-46f5-ae2e-034fc10dddfd">
## Open questions/Issues
### Saved objects
*I think we will still have to do some work to add a new model version
when adding a new saved object field, I do not see an easy way to
programatically generate that. In a first time it probably could be a
manual action to add those migration
### API
Open api generation, I think as a first iteration it could be a manual
operation to update openAPI spec, but we should be able to
programatically generate that with a script in the future
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Co-authored-by: Julia Bardi <90178898+juliaElastic@users.noreply.github.com>
Co-authored-by: Julia Bardi <julia.bardi@elastic.co>
## Summary
Align V2 behavior with ZDT after
https://github.com/elastic/kibana/pull/179595
Under the assumption that whenever we want to add new root fields (e.g.
[created_by](https://github.com/elastic/kibana/pull/179344/)), we will
systematically add mappings for them, we can skip the
`updateAndPickupMappings` operation iif ONLY root fields' mappings have
changed during an upgrade (aka if none of the SO types have updated
their mappings).
Up until now, the logic was updating ALL SO types whenever a `root`
field was added / updated.
This is expensive and unnecessary, and can cause a noticeable impact to
large customers during migrations.
Closes#179356
## Summary
This PR changes the custom dashboards' saved object and API from having
one saved object per asset type to having one saved object per
dashboard.
| Before | After |
|--------|------|
| ``` { dashboardIdList: string[]; assetType: string } ``` | ``` {
dashboardId: string; dashboardFilterAssetIdEnabled: boolean; assetType:
string; }```|
The API endpoints are changed as well to
`api/infra/{assetType}/custom-dashboards`:
- GET api/infra/host/custom-dashboards
- POST api/infra/host/custom-dashboards
{
"dashboardSavedObjectId": string,
"dashboardFilterAssetIdEnabled": boolean
}
The new endpoints are using
`api/infra/{assetType}/custom-dashboards/{id}` where `id` is the id of
the saved object
- **new** PUT api/infra/host/custom-dashboards/123
- **new** DELETE api/infra/host/custom-dashboards/123
After adding the separate PUT endpoint I added a validation to prevent
posting the same dashboard object (payload with the same asset type and
dashboard id) twice. So if the POST endpoint is called twice with the
same params/payload it will return 400 and a message that the dashboard
already exists: "Dashboard with id {id} has already been linked to
{asset type}"
Testing:
1. Unit tests
- Run in this order in separate terminal tabs/windows
- `node scripts/functional_tests_server --config
x-pack/test/api_integration/config`
- `node scripts/functional_test_runner --config
x-pack/test/api_integration/apis/metrics_ui/config.ts --grep 'Infra
Custom Dashboards API'`
2. Dev tools
- First go to Stack Management > Advanced Settings
- Search for "infra" and enable `Custom dashboards for asset details in
Infrastructure`:
<img width="1704" alt="image"
src="614258c8-ee36-4466-b16c-d48f58c3f5dc">
- Go to Dev Tools and run
- POST:
```
POST kbn:/api/infra/host/custom-dashboards
{
"dashboardSavedObjectId": "123",
"dashboardFilterAssetIdEnabled": true
}
```
if the same payload is posted 2 times the **second** time the response
will be 400 because the dashboard for the current asset already exists:
- GET: `GET kbn:/api/infra/host/custom-dashboards`
Example Response:
```
[
{
"id": "a21acbc4-8102-4b09-8bd1-1a9aa4c36f10",
"assetType": "host",
"dashboardSavedObjectId": "123",
"dashboardFilterAssetIdEnabled": true
}
]
```
- PUT (update the returned dashboard):
```
PUT
kbn:/api/infra/host/custom-dashboards/a21acbc4-8102-4b09-8bd1-1a9aa4c36f10
{
"dashboardSavedObjectId": "123",
"dashboardFilterAssetIdEnabled": false
}
```
- DELETE (delete the returned dashboard): `DELETE
kbn:/api/infra/host/custom-dashboards/a21acbc4-8102-4b09-8bd1-1a9aa4c36f10`
---------
Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
## Summary
This PR adds an optional `created_by` field to root saved object fields.
We're doing for adding a filter by an
author to the
dashboard listing page (and then other listings)
### Implementation
#### `created_by: {type: keyword}`
In this implementation, I added `created_by` as a simple keyword field
assuming we will store `profile_uid` only
```
created_by: {
type: 'keyword',
},
```
The `profile_uid` is not always available, as azasypkin described
[here](https://github.com/elastic/kibana/issues/175431#issuecomment-1914577548)
It is not available for anonymous users, for users authenticated via
proxy, and, in some cases, for API users authenticated with API keys.
But this is the best way to globally identify users and longer term we
might get `profile_uid` for all the users
#### Accessing `getCurrentUser` from saved object repo
After exploring different options and discussing with pgayvallet we
decided to provide `getCurrentUser` through existing security extensions
as it's a better isolation of concern, and we avoid leaking the request
down to the SOR.
## Summary
Fix https://github.com/elastic/kibana/issues/179783
Create the aliases during initial index creation, instead of doing it in
a later stage. This avoids an additional roundtrip with ES during
project creation.
**Before:**
```
INIT -> CREATE_TARGET_INDEX -> UPDATE_ALIASES -> INDEX_STATE_UPDATE_DONE -> DONE
```
**After:**
```
INIT -> CREATE_TARGET_INDEX -> INDEX_STATE_UPDATE_DONE -> DONE
```
## Summary
Fix https://github.com/elastic/kibana/issues/179258
Change the version compatibility and mapping generation
(`checkVersionCompatibility` and `generateAdditiveMappingDiff`) of the
ZDT migration algorithm to support the scenario were root fields are
added (adding new fields to our base mappings)
