Changes tag saved object namespaceType to multiple-isolated

[TinaHeiligers]

Resolves #102870
We potentially want to make the tag type shareable in the (near?) future, we need to change its namespaceType to multiple-isolated before 8.0.

A more pressing priority is that other saved objects (dashboard, visualizations, maps and lens) can reference tags, and all SO's that can be referenced need to be converted too.

This PR only changes the namespaceType from single to multiple-isolated.

Making tags "share-capable" (changing the namespaceType) will regenerate IDs of existing saved objects to ensure that they are unique across all spaces, which is a breaking change.

Checklist

• Unit or functional tests were updated or added to match the most common scenarios (not required for this PR)

Risk Matrix

Delete this section if it is not applicable to this PR.

Before closing this PR, invite QA, stakeholders, and other developers to identify risks that should be tested prior to the change/feature release.

When forming the risk matrix, consider some of the following examples and how they may potentially impact the change:

Risk	Probability	Severity	Notes
Tag ids are stored in a Kibana URL—bookmarks to legacy tags will break in non-default Kibana Space.	Low (see #102870#issuecomment-883490811 for more details)	High (bad UX with navigation)	Should we uncover additional requirements to resolve legacy tags and aliases, we can address further changes.

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[TinaHeiligers]

@elasticmachine merge upstream

[joshdover]

@jportner Should this be backported to 7.x? I'm guessing the convertToMultiNamespaceTypeVersion makes it safe to backport.

I wonder if we should change the release note on this PR to clarify that this is only a breaking change for URLs if you have custom plugins that use tags IDs in the URLs (since no 1st party code uses tag IDs in the URL). We should also add a note about tag IDs changing on the SO API. Maybe there's a "template" of sorts we should create for the SO API release notes for each type since the guidance would largely be the same for each type that is affected by this conversion. That, or we should just have a single release note for the SO API ID changes that mentions all affected types in 8.0.

[jportner]

@jportner Should this be backported to 7.x? I'm guessing the convertToMultiNamespaceTypeVersion makes it safe to backport.

No, we have validation in place specifically to prevent convertToMultiNamespaceTypeVersion from being set to < 8.0.
convertToMultiNamespaceTypeVersion is what Core needs to know to automatically generate the correct "transform" function during index migrations.

namespaceType should only be changed to 'multiple-isolated' in the actual version matching convertToMultiNamespaceTypeVersion. I appreciate now how the naming doesn't make that very clear!

I wonder if we should change the release note on this PR to clarify that this is only a breaking change for URLs if you have custom plugins that use tags IDs in the URLs (since no 1st party code uses tag IDs in the URL). We should also add a note about tag IDs changing on the SO API. Maybe there's a "template" of sorts we should create for the SO API release notes for each type since the guidance would largely be the same for each type that is affected by this conversion. That, or we should just have a single release note for the SO API ID changes that mentions all affected types in 8.0.

I vote for a single release note. We have dozens of affected types, I don't think such repetitive release notes will be helpful.

[TinaHeiligers]

On hold pending decision on when to change all SO types to become share capable.

[TinaHeiligers]

@elasticmachine merge upstream

[rudolf]

@TinaHeiligers Joe will do a single release note for the breaking change across all saved object types, but each team is responsible for converting their own types, there won't be a single big commit, so we should go ahead and merge this.

[jportner]

@TinaHeiligers Joe will do a single release note for the breaking change across all saved object types, but each team is responsible for converting their own types, there won't be a single big commit, so we should go ahead and merge this.

Agree that we should just do a single release note.

We were waiting on this as we had some open discussions about potentially delaying the conversion past 8.0, but it looks like we hopefully won't need to do that after all. So I think we can merge this and revert it later if we absolutely have to.

[TinaHeiligers]

So I think we can merge this and revert it later if we absolutely have to

@jportner Thanks for the head's up! I'll merge once CI passes. What should I do with the release note comment and label? Adding release_note:skip.

[TinaHeiligers]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: daf5638
• Storybooks Preview

Metrics [docs]

✅ unchanged

History

• 💚 Build #140875 succeeded f509cbc
• 💛 Build #140210 was flaky 3e16b76
• 💔 Build #140149 failed a9b86a1
• 💔 Build #139923 failed 47ad06e

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[TinaHeiligers]

@jportner The PR is merged.

[kibanamachine]

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create backports run node scripts/backport --pr 106341 or prevent reminders by adding the backport:skip label.