Skip to content

[Dashboard] Inject / extract tag references #214788

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 18 commits into from
Mar 31, 2025

Conversation

nickpeihl
Copy link
Member

@nickpeihl nickpeihl commented Mar 17, 2025

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 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.

  • Unit or functional tests were updated or added to match the most common scenarios
  • The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines

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.
  • ...

nickpeihl and others added 7 commits March 18, 2025 16:27
…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 TinaHeiligers self-requested a review March 24, 2025 14:46
@nickpeihl nickpeihl marked this pull request as ready for review March 24, 2025 15:14
@nickpeihl nickpeihl requested review from a team as code owners March 24, 2025 15:14
Copy link
Contributor

@TinaHeiligers TinaHeiligers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Core-related changes (test fixtures) LGTM.

@nickpeihl nickpeihl added the Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas label Mar 25, 2025
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-presentation (Team:Presentation)

Copy link
Contributor

@ThomThomson ThomThomson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

@@ -138,6 +138,8 @@ export const getSerializedState = ({
{ embeddablePersistableStateService: embeddableService }
);

// TODO Provide tags as an array of tag names in the attribute. In that case, tag references
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have a followup issue for this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -37,7 +37,7 @@ export const serviceDefinition: ServicesDefinition = {
...serviceDefinitionV1?.create?.in,
data: {
schema: dashboardAttributesSchema,
up: (data: DashboardCrudTypes['CreateIn']['data']) => attributesTov3(data),
up: (data: DashboardCrudTypes['CreateIn']['data']) => attributesTov3(data, [], () => []),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we pass a blank references array here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, those are now optional parameters. The content management up transforms do not supply references so we only transform the attributes. Fixed in ff8e17a.

@@ -171,6 +172,153 @@ export default function ({ getService }: FtrProviderContext) {
expect(response.body.item.attributes.panels).to.be.an('array');
});

describe('create a dashboard with tags', () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
@dominiqueclarke
Copy link
Contributor

Will this require updating to a new version of the content management api? We're currently using version 3.

@nickpeihl nickpeihl enabled auto-merge (squash) March 31, 2025 14:20
@nickpeihl nickpeihl merged commit c4f7c64 into elastic:main Mar 31, 2025
10 checks passed
@elasticmachine
Copy link
Contributor

💛 Build succeeded, but was flaky

Failed CI Steps

Test Failures

  • [job] [logs] Jest Tests #4 / TemplatesList renders template details correctly

Metrics [docs]

✅ unchanged

History

cqliu1 pushed a commit to cqliu1/kibana that referenced this pull request Mar 31, 2025
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 <[email protected]>
@nickpeihl nickpeihl added backport:version Backport to applied version labels v8.19.0 and removed backport:skip This commit does not require backporting labels Apr 8, 2025
@kibanamachine
Copy link
Contributor

@kibanamachine
Copy link
Contributor

@kibanamachine
Copy link
Contributor

💔 All backports failed

Status Branch Result
8.x Backport failed because of merge conflicts

You might need to backport the following PRs to 8.x:
- [Dashboard] Remove mSearch from content management (#210709)
- [Dashboards] Provide a method for fetching dashboards on the Dashboard server plugin contract (#209678)

Manual backport

To create the backport manually run:

node scripts/backport --pr 214788

Questions ?

Please refer to the Backport tool documentation

1 similar comment
@kibanamachine
Copy link
Contributor

💔 All backports failed

Status Branch Result
8.x Backport failed because of merge conflicts

You might need to backport the following PRs to 8.x:
- [Dashboard] Remove mSearch from content management (#210709)
- [Dashboards] Provide a method for fetching dashboards on the Dashboard server plugin contract (#209678)

Manual backport

To create the backport manually run:

node scripts/backport --pr 214788

Questions ?

Please refer to the Backport tool documentation

nickpeihl added a commit to nickpeihl/kibana that referenced this pull request Apr 8, 2025
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 <[email protected]>
(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
@nickpeihl
Copy link
Member Author

💚 All backports created successfully

Status Branch Result
8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation

@kibanamachine kibanamachine added the backport missing Added to PRs automatically when the are determined to be missing a backport. label Apr 9, 2025
@kibanamachine
Copy link
Contributor

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.

nickpeihl added a commit that referenced this pull request Apr 9, 2025
# 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":"[email protected]"},"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
<[email protected]>","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
<[email protected]>","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
<[email protected]>","sha":"c4f7c649b12b8189f1b7a00d4857c1372acc8755"}},{"branch":"8.x","label":"v8.19.0","branchLabelMappingKey":"^v8.19.0$","isSourceBranch":false,"state":"NOT_CREATED"}]}]
BACKPORT-->
@kibanamachine kibanamachine removed the backport missing Added to PRs automatically when the are determined to be missing a backport. label Apr 9, 2025
nickpeihl added a commit that referenced this pull request Apr 10, 2025
…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.
nickpeihl added a commit to nickpeihl/kibana that referenced this pull request Apr 11, 2025
…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
nickpeihl added a commit that referenced this pull request Apr 15, 2025
…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":"[email protected]"},"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-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:version Backport to applied version labels release_note:enhancement Team:Presentation Presentation Team for Dashboard, Input Controls, and Canvas v8.19.0 v9.1.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Dashboards as code] Handle tag references on the server
6 participants