[Dashboard] Inject / extract tag references#214788
Conversation
…t --include-path /api/status --include-path /api/alerting/rule/ --include-path /api/alerting/rules --include-path /api/actions --include-path /api/security/role --include-path /api/spaces --include-path /api/streams --include-path /api/fleet --include-path /api/dashboards --update'
TinaHeiligers
left a comment
There was a problem hiding this comment.
Core-related changes (test fixtures) LGTM.
|
Pinging @elastic/kibana-presentation (Team:Presentation) |
ThomThomson
left a comment
There was a problem hiding this comment.
Great work! Tested this locally in chrome by creating and updating a Dashboard SO via the API through devtools. Also tested that tags generated this way were treated the same + looked the same in the SO Management page as tags created via the UI.
Looked through the code and left a few questions, but otherwise everything looks pretty straightforward. Lots of test coverage added, which is very nice!
| { embeddablePersistableStateService: embeddableService } | ||
| ); | ||
|
|
||
| // TODO Provide tags as an array of tag names in the attribute. In that case, tag references |
There was a problem hiding this comment.
Do we have a followup issue for this?
| data: { | ||
| schema: dashboardAttributesSchema, | ||
| up: (data: DashboardCrudTypes['CreateIn']['data']) => attributesTov3(data), | ||
| up: (data: DashboardCrudTypes['CreateIn']['data']) => attributesTov3(data, [], () => []), |
There was a problem hiding this comment.
Why do we pass a blank references array here?
There was a problem hiding this comment.
Ah, those are now optional parameters. The content management up transforms do not supply references so we only transform the attributes. Fixed in ff8e17a.
| expect(response.body.item.attributes.panels).to.be.an('array'); | ||
| }); | ||
|
|
||
| describe('create a dashboard with tags', () => { |
There was a problem hiding this comment.
Great to see a new API Integration test added!
This allows saved object migrations to continue to use the synchronous itemAttrsToSavedObject function since they don't have a need for tag creation.
|
Will this require updating to a new version of the content management api? We're currently using version 3. |
💛 Build succeeded, but was flaky
Failed CI StepsTest FailuresMetrics [docs]
History
|
Fixes elastic#210619 ## Summary Provides a tags array on the request and response bodies of dashboards. This allows consumers of the Dashboards HTTP API and internal RPC API to add an array of tag names to the attributes in the body of create and update endpoints. The dashboard server will be responsible for converting the tag names into references in the saved object. If, during creation or update, a tag name does not have a matching tag saved object, a new tag saved object will be created. If the user lacks permissions to manage tags, then an error will be logged in the server and the tag will not be added to the dashboard. The server also injects the tag references as an array of tag names in the attributes of the response body of get and search endpoints of the HTTP and RPC APIs. For backwards compatibility in create and update endpoints, tags can alternatively be specified in the `references` array in the options instead of (or in addition to) the `attributes.tags` in the request body. Similarly, for backwards compatibility, tag references are returned in the `references` of the response body of get and search endpoints. Client-side tag handling is out of scope for this PR. Dashboards listing page and dashboard settings continue to use the tag references and do not use the `tags` attribute in the response. For example: Here's how we currently create a dashboard with tag references. ``` ## Creating a dashboard with tag references POST kbn:/api/dashboards/dashboard { "attributes": { "title": "my tagged dashboard" }, "references": [ { "type": "tag", "id": "37aab5de-a34d-47cb-9aa5-9375d5db595f", "name": "tag-ref-37aab5de-a34d-47cb-9aa5-9375d5db595f" }, { "type": "tag", "id": "5ed29bba-c14d-4302-9a8c-9602e40dbc2a", "name": "tag-ref-5ed29bba-c14d-4302-9a8c-9602e40dbc2a" }, { "type": "tag", "id": "fc7890e8-c00f-44a1-88a2-250e4d27e61d", "name": "tag-ref-fc7890e8-c00f-44a1-88a2-250e4d27e61d" } ] } ``` With this PR, creating a dashboard with tags is much simpler. ``` ## Creating a dashboard with tag names POST kbn:/api/dashboards/dashboard { "attributes": { "title": "my tagged dashboard", "tags": [ "boo", "foo", "bingo", "bongo" ] } } ``` ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [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] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ### Identify risks Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss. Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging. - [ ] If there are more than one tag saved objects with the same name, only one of the tag references will be added to the saved object when creating a dashboard. Creating tags with duplicate names are not permitted via the UI. But there is no such restrictions when creating tags from imported saved objects. Having multiple tags with the same name is an edge case that Kibana guards against with reasonable restrictions, so I think we should not be too concerned about it. - [ ] ... --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
|
Starting backport for target branches: 8.x https://github.com/elastic/kibana/actions/runs/14333621427 |
|
Starting backport for target branches: 8.x https://github.com/elastic/kibana/actions/runs/14333621459 |
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
1 similar comment
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
Fixes elastic#210619 ## Summary Provides a tags array on the request and response bodies of dashboards. This allows consumers of the Dashboards HTTP API and internal RPC API to add an array of tag names to the attributes in the body of create and update endpoints. The dashboard server will be responsible for converting the tag names into references in the saved object. If, during creation or update, a tag name does not have a matching tag saved object, a new tag saved object will be created. If the user lacks permissions to manage tags, then an error will be logged in the server and the tag will not be added to the dashboard. The server also injects the tag references as an array of tag names in the attributes of the response body of get and search endpoints of the HTTP and RPC APIs. For backwards compatibility in create and update endpoints, tags can alternatively be specified in the `references` array in the options instead of (or in addition to) the `attributes.tags` in the request body. Similarly, for backwards compatibility, tag references are returned in the `references` of the response body of get and search endpoints. Client-side tag handling is out of scope for this PR. Dashboards listing page and dashboard settings continue to use the tag references and do not use the `tags` attribute in the response. For example: Here's how we currently create a dashboard with tag references. ``` ## Creating a dashboard with tag references POST kbn:/api/dashboards/dashboard { "attributes": { "title": "my tagged dashboard" }, "references": [ { "type": "tag", "id": "37aab5de-a34d-47cb-9aa5-9375d5db595f", "name": "tag-ref-37aab5de-a34d-47cb-9aa5-9375d5db595f" }, { "type": "tag", "id": "5ed29bba-c14d-4302-9a8c-9602e40dbc2a", "name": "tag-ref-5ed29bba-c14d-4302-9a8c-9602e40dbc2a" }, { "type": "tag", "id": "fc7890e8-c00f-44a1-88a2-250e4d27e61d", "name": "tag-ref-fc7890e8-c00f-44a1-88a2-250e4d27e61d" } ] } ``` With this PR, creating a dashboard with tags is much simpler. ``` ## Creating a dashboard with tag names POST kbn:/api/dashboards/dashboard { "attributes": { "title": "my tagged dashboard", "tags": [ "boo", "foo", "bingo", "bongo" ] } } ``` ### Checklist Check the PR satisfies following conditions. Reviewers should verify this PR satisfies this list as well. - [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] The PR description includes the appropriate Release Notes section, and the correct `release_note:*` label is applied per the [guidelines](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) ### Identify risks Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss. Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging. - [ ] If there are more than one tag saved objects with the same name, only one of the tag references will be added to the saved object when creating a dashboard. Creating tags with duplicate names are not permitted via the UI. But there is no such restrictions when creating tags from imported saved objects. Having multiple tags with the same name is an edge case that Kibana guards against with reasonable restrictions, so I think we should not be too concerned about it. - [ ] ... --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com> (cherry picked from commit c4f7c64) # Conflicts: # src/platform/plugins/shared/dashboard/server/content_management/dashboard_storage.ts # src/platform/plugins/shared/dashboard/server/plugin.ts
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
|
Looks like this PR has a backport PR but it still hasn't been merged. Please merge it ASAP to keep the branches relatively in sync. |
# Backport This will backport the following commits from `main` to `8.x`: - [[Dashboard] Inject / extract tag references (#214788)](#214788) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Nick Peihl","email":"nick.peihl@elastic.co"},"sourceCommit":{"committedDate":"2025-03-31T14:52:24Z","message":"[Dashboard] Inject / extract tag references (#214788)\n\nFixes #210619\n\n## Summary\n\nProvides a tags array on the request and response bodies of dashboards.\n\nThis allows consumers of the Dashboards HTTP API and internal RPC API to\nadd an array of tag names to the attributes in the body of create and\nupdate endpoints. The dashboard server will be responsible for\nconverting the tag names into references in the saved object.\n\nIf, during creation or update, a tag name does not have a matching tag\nsaved object, a new tag saved object will be created. If the user lacks\npermissions to manage tags, then an error will be logged in the server\nand the tag will not be added to the dashboard.\n\nThe server also injects the tag references as an array of tag names in\nthe attributes of the response body of get and search endpoints of the\nHTTP and RPC APIs.\n\nFor backwards compatibility in create and update endpoints, tags can\nalternatively be specified in the `references` array in the options\ninstead of (or in addition to) the `attributes.tags` in the request\nbody. Similarly, for backwards compatibility, tag references are\nreturned in the `references` of the response body of get and search\nendpoints.\n\nClient-side tag handling is out of scope for this PR. Dashboards listing\npage and dashboard settings continue to use the tag references and do\nnot use the `tags` attribute in the response.\n\nFor example:\n\nHere's how we currently create a dashboard with tag references.\n```\n## Creating a dashboard with tag references\nPOST kbn:/api/dashboards/dashboard\n{\n \"attributes\": {\n \"title\": \"my tagged dashboard\"\n },\n \"references\": [\n {\n \"type\": \"tag\",\n \"id\": \"37aab5de-a34d-47cb-9aa5-9375d5db595f\",\n \"name\": \"tag-ref-37aab5de-a34d-47cb-9aa5-9375d5db595f\"\n },\n {\n \"type\": \"tag\",\n \"id\": \"5ed29bba-c14d-4302-9a8c-9602e40dbc2a\",\n \"name\": \"tag-ref-5ed29bba-c14d-4302-9a8c-9602e40dbc2a\"\n },\n {\n \"type\": \"tag\",\n \"id\": \"fc7890e8-c00f-44a1-88a2-250e4d27e61d\",\n \"name\": \"tag-ref-fc7890e8-c00f-44a1-88a2-250e4d27e61d\"\n }\n ]\n}\n```\n\nWith this PR, creating a dashboard with tags is much simpler.\n\n```\n## Creating a dashboard with tag names\nPOST kbn:/api/dashboards/dashboard\n{\n \"attributes\": {\n \"title\": \"my tagged dashboard\",\n \"tags\": [\n \"boo\",\n \"foo\",\n \"bingo\",\n \"bongo\"\n ]\n }\n}\n\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)\n\n### Identify risks\n\nDoes this PR introduce any risks? For example, consider risks like hard\nto test bugs, performance regression, potential of data loss.\n\nDescribe the risk, its severity, and mitigation for each identified\nrisk. Invite stakeholders and evaluate how to proceed before merging.\n\n- [ ] If there are more than one tag saved objects with the same name,\nonly one of the tag references will be added to the saved object when\ncreating a dashboard. Creating tags with duplicate names are not\npermitted via the UI. But there is no such restrictions when creating\ntags from imported saved objects. Having multiple tags with the same\nname is an edge case that Kibana guards against with reasonable\nrestrictions, so I think we should not be too concerned about it.\n- [ ] ...\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"c4f7c649b12b8189f1b7a00d4857c1372acc8755","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:enhancement","Team:Presentation","backport:version","v9.1.0","v8.19.0"],"title":"[Dashboard] Inject / extract tag references","number":214788,"url":"https://github.com/elastic/kibana/pull/214788","mergeCommit":{"message":"[Dashboard] Inject / extract tag references (#214788)\n\nFixes #210619\n\n## Summary\n\nProvides a tags array on the request and response bodies of dashboards.\n\nThis allows consumers of the Dashboards HTTP API and internal RPC API to\nadd an array of tag names to the attributes in the body of create and\nupdate endpoints. The dashboard server will be responsible for\nconverting the tag names into references in the saved object.\n\nIf, during creation or update, a tag name does not have a matching tag\nsaved object, a new tag saved object will be created. If the user lacks\npermissions to manage tags, then an error will be logged in the server\nand the tag will not be added to the dashboard.\n\nThe server also injects the tag references as an array of tag names in\nthe attributes of the response body of get and search endpoints of the\nHTTP and RPC APIs.\n\nFor backwards compatibility in create and update endpoints, tags can\nalternatively be specified in the `references` array in the options\ninstead of (or in addition to) the `attributes.tags` in the request\nbody. Similarly, for backwards compatibility, tag references are\nreturned in the `references` of the response body of get and search\nendpoints.\n\nClient-side tag handling is out of scope for this PR. Dashboards listing\npage and dashboard settings continue to use the tag references and do\nnot use the `tags` attribute in the response.\n\nFor example:\n\nHere's how we currently create a dashboard with tag references.\n```\n## Creating a dashboard with tag references\nPOST kbn:/api/dashboards/dashboard\n{\n \"attributes\": {\n \"title\": \"my tagged dashboard\"\n },\n \"references\": [\n {\n \"type\": \"tag\",\n \"id\": \"37aab5de-a34d-47cb-9aa5-9375d5db595f\",\n \"name\": \"tag-ref-37aab5de-a34d-47cb-9aa5-9375d5db595f\"\n },\n {\n \"type\": \"tag\",\n \"id\": \"5ed29bba-c14d-4302-9a8c-9602e40dbc2a\",\n \"name\": \"tag-ref-5ed29bba-c14d-4302-9a8c-9602e40dbc2a\"\n },\n {\n \"type\": \"tag\",\n \"id\": \"fc7890e8-c00f-44a1-88a2-250e4d27e61d\",\n \"name\": \"tag-ref-fc7890e8-c00f-44a1-88a2-250e4d27e61d\"\n }\n ]\n}\n```\n\nWith this PR, creating a dashboard with tags is much simpler.\n\n```\n## Creating a dashboard with tag names\nPOST kbn:/api/dashboards/dashboard\n{\n \"attributes\": {\n \"title\": \"my tagged dashboard\",\n \"tags\": [\n \"boo\",\n \"foo\",\n \"bingo\",\n \"bongo\"\n ]\n }\n}\n\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)\n\n### Identify risks\n\nDoes this PR introduce any risks? For example, consider risks like hard\nto test bugs, performance regression, potential of data loss.\n\nDescribe the risk, its severity, and mitigation for each identified\nrisk. Invite stakeholders and evaluate how to proceed before merging.\n\n- [ ] If there are more than one tag saved objects with the same name,\nonly one of the tag references will be added to the saved object when\ncreating a dashboard. Creating tags with duplicate names are not\npermitted via the UI. But there is no such restrictions when creating\ntags from imported saved objects. Having multiple tags with the same\nname is an edge case that Kibana guards against with reasonable\nrestrictions, so I think we should not be too concerned about it.\n- [ ] ...\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"c4f7c649b12b8189f1b7a00d4857c1372acc8755"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/214788","number":214788,"mergeCommit":{"message":"[Dashboard] Inject / extract tag references (#214788)\n\nFixes #210619\n\n## Summary\n\nProvides a tags array on the request and response bodies of dashboards.\n\nThis allows consumers of the Dashboards HTTP API and internal RPC API to\nadd an array of tag names to the attributes in the body of create and\nupdate endpoints. The dashboard server will be responsible for\nconverting the tag names into references in the saved object.\n\nIf, during creation or update, a tag name does not have a matching tag\nsaved object, a new tag saved object will be created. If the user lacks\npermissions to manage tags, then an error will be logged in the server\nand the tag will not be added to the dashboard.\n\nThe server also injects the tag references as an array of tag names in\nthe attributes of the response body of get and search endpoints of the\nHTTP and RPC APIs.\n\nFor backwards compatibility in create and update endpoints, tags can\nalternatively be specified in the `references` array in the options\ninstead of (or in addition to) the `attributes.tags` in the request\nbody. Similarly, for backwards compatibility, tag references are\nreturned in the `references` of the response body of get and search\nendpoints.\n\nClient-side tag handling is out of scope for this PR. Dashboards listing\npage and dashboard settings continue to use the tag references and do\nnot use the `tags` attribute in the response.\n\nFor example:\n\nHere's how we currently create a dashboard with tag references.\n```\n## Creating a dashboard with tag references\nPOST kbn:/api/dashboards/dashboard\n{\n \"attributes\": {\n \"title\": \"my tagged dashboard\"\n },\n \"references\": [\n {\n \"type\": \"tag\",\n \"id\": \"37aab5de-a34d-47cb-9aa5-9375d5db595f\",\n \"name\": \"tag-ref-37aab5de-a34d-47cb-9aa5-9375d5db595f\"\n },\n {\n \"type\": \"tag\",\n \"id\": \"5ed29bba-c14d-4302-9a8c-9602e40dbc2a\",\n \"name\": \"tag-ref-5ed29bba-c14d-4302-9a8c-9602e40dbc2a\"\n },\n {\n \"type\": \"tag\",\n \"id\": \"fc7890e8-c00f-44a1-88a2-250e4d27e61d\",\n \"name\": \"tag-ref-fc7890e8-c00f-44a1-88a2-250e4d27e61d\"\n }\n ]\n}\n```\n\nWith this PR, creating a dashboard with tags is much simpler.\n\n```\n## Creating a dashboard with tag names\nPOST kbn:/api/dashboards/dashboard\n{\n \"attributes\": {\n \"title\": \"my tagged dashboard\",\n \"tags\": [\n \"boo\",\n \"foo\",\n \"bingo\",\n \"bongo\"\n ]\n }\n}\n\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)\n\n### Identify risks\n\nDoes this PR introduce any risks? For example, consider risks like hard\nto test bugs, performance regression, potential of data loss.\n\nDescribe the risk, its severity, and mitigation for each identified\nrisk. Invite stakeholders and evaluate how to proceed before merging.\n\n- [ ] If there are more than one tag saved objects with the same name,\nonly one of the tag references will be added to the saved object when\ncreating a dashboard. Creating tags with duplicate names are not\npermitted via the UI. But there is no such restrictions when creating\ntags from imported saved objects. Having multiple tags with the same\nname is an edge case that Kibana guards against with reasonable\nrestrictions, so I think we should not be too concerned about it.\n- [ ] ...\n\n---------\n\nCo-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>","sha":"c4f7c649b12b8189f1b7a00d4857c1372acc8755"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT-->
…Start server api (#217586) ## Summary Changes the DashboardStart server api to provide a getContentClient function. In #214788, we set the `contentClient` returned from the content management register method after start lifecycle of all plugins. This means the `contentClient` returned from the `DashboardStart` contract was undefined. This PR changes the start contract to provide a getContentClient function instead. Only one consumer was using the contentClient from DashboardStart and this PR also updates that consumer.
…Start server api (elastic#217586) ## Summary Changes the DashboardStart server api to provide a getContentClient function. In elastic#214788, we set the `contentClient` returned from the content management register method after start lifecycle of all plugins. This means the `contentClient` returned from the `DashboardStart` contract was undefined. This PR changes the start contract to provide a getContentClient function instead. Only one consumer was using the contentClient from DashboardStart and this PR also updates that consumer. (cherry picked from commit 72d18d8) # Conflicts: # x-pack/solutions/observability/plugins/observability/server/routes/alerts/route.ts
…hboardStart server api (#217586) (#217989) # Backport This will backport the following commits from `main` to `8.x`: - [[Dashboards] Replace contentClient with getContentClient on DashboardStart server api (#217586)](#217586) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Nick Peihl","email":"nick.peihl@elastic.co"},"sourceCommit":{"committedDate":"2025-04-10T18:52:38Z","message":"[Dashboards] Replace contentClient with getContentClient on DashboardStart server api (#217586)\n\n## Summary\n\nChanges the DashboardStart server api to provide a getContentClient\nfunction.\n\nIn #214788, we set the\n`contentClient` returned from the content management register method\nafter start lifecycle of all plugins. This means the `contentClient`\nreturned from the `DashboardStart` contract was undefined. This PR\nchanges the start contract to provide a getContentClient function\ninstead.\n\nOnly one consumer was using the contentClient from DashboardStart and\nthis PR also updates that consumer.","sha":"72d18d8b992c99bb0be42123406453f0379f29d8","branchLabelMapping":{"^v9.1.0$":"main","^v8.19.0$":"8.x","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Presentation","release_note:plugin_api_changes","Team:obs-ux-management","backport:version","v9.1.0","v8.19.0"],"title":"[Dashboards] Replace contentClient with getContentClient on DashboardStart server api","number":217586,"url":"https://github.com/elastic/kibana/pull/217586","mergeCommit":{"message":"[Dashboards] Replace contentClient with getContentClient on DashboardStart server api (#217586)\n\n## Summary\n\nChanges the DashboardStart server api to provide a getContentClient\nfunction.\n\nIn #214788, we set the\n`contentClient` returned from the content management register method\nafter start lifecycle of all plugins. This means the `contentClient`\nreturned from the `DashboardStart` contract was undefined. This PR\nchanges the start contract to provide a getContentClient function\ninstead.\n\nOnly one consumer was using the contentClient from DashboardStart and\nthis PR also updates that consumer.","sha":"72d18d8b992c99bb0be42123406453f0379f29d8"}},"sourceBranch":"main","suggestedTargetBranches":["8.x"],"targetPullRequestStates":[{"branch":"main","label":"v9.1.0","branchLabelMappingKey":"^v9.1.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/217586","number":217586,"mergeCommit":{"message":"[Dashboards] Replace contentClient with getContentClient on DashboardStart server api (#217586)\n\n## Summary\n\nChanges the DashboardStart server api to provide a getContentClient\nfunction.\n\nIn #214788, we set the\n`contentClient` returned from the content management register method\nafter start lifecycle of all plugins. This means the `contentClient`\nreturned from the `DashboardStart` contract was undefined. This PR\nchanges the start contract to provide a getContentClient function\ninstead.\n\nOnly one consumer was using the contentClient from DashboardStart and\nthis PR also updates that consumer.","sha":"72d18d8b992c99bb0be42123406453f0379f29d8"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT-->
…n array of tag saved object ids (#233541) Part of #216346 #214788 updated dashboard CRUD API read `attributes.tags` as an array of tag names and write `attributes.tags` as an array of tag names. Returning `attributes.tags` as an array of tag names breaks the link between the tag saved object. Instead, `attributes.tags` should be an array of tag ids. #214788 updated dashboard CRUD API with a side effect where if a tag saved object did not exist for a tag name, then a tag saved object would be created for the tag name. APIs should not have side effects like this. This PR updates dashboard CRUD API read `attributes.tags` as an array of tag ids and write `attributes.tags` as an array of tag ids to avoid breaking the link between tag saved objects. The PR also removes the ability for the dashboard CRUD APIs to create tag saved objects. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
…n array of tag saved object ids (elastic#233541) Part of elastic#216346 elastic#214788 updated dashboard CRUD API read `attributes.tags` as an array of tag names and write `attributes.tags` as an array of tag names. Returning `attributes.tags` as an array of tag names breaks the link between the tag saved object. Instead, `attributes.tags` should be an array of tag ids. elastic#214788 updated dashboard CRUD API with a side effect where if a tag saved object did not exist for a tag name, then a tag saved object would be created for the tag name. APIs should not have side effects like this. This PR updates dashboard CRUD API read `attributes.tags` as an array of tag ids and write `attributes.tags` as an array of tag ids to avoid breaking the link between tag saved objects. The PR also removes the ability for the dashboard CRUD APIs to create tag saved objects. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
…n array of tag saved object ids (#233541) Part of #216346 #214788 updated dashboard CRUD API read `attributes.tags` as an array of tag names and write `attributes.tags` as an array of tag names. Returning `attributes.tags` as an array of tag names breaks the link between the tag saved object. Instead, `attributes.tags` should be an array of tag ids. #214788 updated dashboard CRUD API with a side effect where if a tag saved object did not exist for a tag name, then a tag saved object would be created for the tag name. APIs should not have side effects like this. This PR updates dashboard CRUD API read `attributes.tags` as an array of tag ids and write `attributes.tags` as an array of tag ids to avoid breaking the link between tag saved objects. The PR also removes the ability for the dashboard CRUD APIs to create tag saved objects. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
…n array of tag saved object ids (elastic#233541) Part of elastic#216346 elastic#214788 updated dashboard CRUD API read `attributes.tags` as an array of tag names and write `attributes.tags` as an array of tag names. Returning `attributes.tags` as an array of tag names breaks the link between the tag saved object. Instead, `attributes.tags` should be an array of tag ids. elastic#214788 updated dashboard CRUD API with a side effect where if a tag saved object did not exist for a tag name, then a tag saved object would be created for the tag name. APIs should not have side effects like this. This PR updates dashboard CRUD API read `attributes.tags` as an array of tag ids and write `attributes.tags` as an array of tag ids to avoid breaking the link between tag saved objects. The PR also removes the ability for the dashboard CRUD APIs to create tag saved objects. --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com> Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
Fixes #210619
Summary
Provides a tags array on the request and response bodies of dashboards.
This allows consumers of the Dashboards HTTP API and internal RPC API to add an array of tag names to the attributes in the body of create and update endpoints. The dashboard server will be responsible for converting the tag names into references in the saved object.
If, during creation or update, a tag name does not have a matching tag saved object, a new tag saved object will be created. If the user lacks permissions to manage tags, then an error will be logged in the server and the tag will not be added to the dashboard.
The server also injects the tag references as an array of tag names in the attributes of the response body of get and search endpoints of the HTTP and RPC APIs.
For backwards compatibility in create and update endpoints, tags can alternatively be specified in the
referencesarray in the options instead of (or in addition to) theattributes.tagsin the request body. Similarly, for backwards compatibility, tag references are returned in thereferencesof the response body of get and search endpoints.Client-side tag handling is out of scope for this PR. Dashboards listing page and dashboard settings continue to use the tag references and do not use the
tagsattribute in the response.For example:
Here's how we currently create a dashboard with tag references.
With this PR, creating a dashboard with tags is much simpler.
Checklist
Check the PR satisfies following conditions.
Reviewers should verify this PR satisfies this list as well.
release_note:*label is applied per the guidelinesIdentify risks
Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss.
Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging.