[Saved objects] Create URL aliases during "Copy on save"

[drewdaemon]

Background

Users create or install dashboards in a single space. They often want to have those dashboards available in other spaces. Our answer today is the "Copy to spaces" action in the saved object management page:

However, because saved object IDs change during import to another space, "Copy to spaces" breaks weak links—that is, links that hard-code the IDs of other saved objects.

Weak links can be added via markdown, via URL field formatters, via TSVB tables, via Vega, etc. They are currently quite common.

Users of our integrations hit this issue especially consistently:

• Metrics system overview dashboard redirects to a 404 Dashboard not found page in Kibana #175072
• Links in the dashboards from elastic agent integration are not working in a multi space environment integrations#6691
• Not fixed in 8.9.1 / Integrations in multiple Kibana Spaces #164243
• https://discuss.elastic.co/t/imported-dashboard-and-their-sub-dashboards-does-not-work-in-kibana/346096
• For a fuller discussion on Fleet's space support, see [Fleet] Known limitations with Fleet/Integrations in multi-space environments #175831

Eventually, we plan to allow dashboards to be shared between spaces. Strategically, this is the obvious answer! And we want to do it. But it’s a large project. In the meantime....

The ask

Let's

1. validate that creating URL aliases during copy-to-spaces preserves weak links
2. add an option to the UI to create URL aliases when users invoke "Copy to spaces"

The switch could go somewhere in here:

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[legrego]

Thanks for taking the time to open this, @drewdaemon, and for the detailed ask and impact.

This sounds very similar to the work we did for import/export recently:

• Importing saved objects can break "weak links" #123550
• Support generating legacy URL aliases for objects that change IDs during import. #149021

For better or worse, "Copy to Space" leverages import/export behind the scenes, so the level of effort to introduce this will hopefully be less than what was required for #149021, as we can build on top of it.

The UX for this experience is already quite option-heavy, so I do worry about adding yet another toggle. That's something we can work with the design team on though, should we decide to pick this up.

I'd also be remiss if I didn't cross-link to #144358, as this will be yet another way to proliferate legacy url aliases.

[drewdaemon]

Thanks for the comments @legrego . As you say, I don't think this is a technically difficult task since the import API already supports this option.

Placing it behind a toggle was an idea from @azasypkin to reduce the overall number of URL aliases created—I would leave it up to your team to decide the specifics as either approach is okay with the other stakeholders (including Fleet).

I opened this issue because it seems like a reasonable step to evaluate, but I wouldn't consider it ready to schedule until we make sure that creating aliases during copy-to-spaces improves the situation—so far the discussion has not included an actual PoC.

[drewdaemon]

A PoC

I installed assets from the System integration and copied a set of weak-linked dashboards to a non-default space, setting compatibilityMode to true. The links work and keep me within the assets in the non-default space, so I think this is indeed a valid solution 🎉

Screen.Recording.2024-02-13.at.3.10.30.PM.mov

A couple other notes

Surprisingly—I then copied the assets from that second space to a third space and the links continued to work. I expected them to break since the new URL aliases would be mapping the IDs from the second space to the new IDs in the third, while the links would still reference the original IDs found in the default space. However, if the URL aliases are global, it may be performing a two-step redirect.

It's worth noting that if some linked-to assets are not copied to the new space, the weak links will still be broken. They don't direct you to the assets in the original space.

I also don't understand why these copy options are included here...

No matter what I'm going to get objects with new IDs because we enforce that across spaces. Also, there won't be conflicts for the very same reasons.

Conclusion

Anyway, I think we can consider this issue a valid tactical solution to the common problem of weak-links across spaces.

[azasypkin]

Surprisingly—I then copied the assets from that second space to a third space and the links continued to work. I expected them to break since the new URL aliases would be mapping the IDs from the second space to the new IDs in the third, while the links would still reference the original IDs found in the default space. However, if the URL aliases are global, it may be performing a two-step redirect.

Correct, it's expected to work, but there are no two-step redirects or anything like that. The reason it works is that when you copy an object without regenerating the ID, it retains the original ID as the originId Saved Object field. This field is always retained, no matter how many times the object is copied. The legacy URL alias simply maps the original ID to a new ID within a specific space. So, in your case, you have two legacy URL aliases that map the same origin ID to different IDs in the second and third space:

"legacy-url-alias": {
  "sourceId": "6604aa8b-a22b-45de-a838-d06eeadb4b4e", <--- origin ID
  "targetNamespace": "space-a",
  "targetId": "1c601f67-99b9-4780-9b50-8f2a69a78c5a" <--- new ID in Space A
},
"legacy-url-alias": {
  "sourceId": "6604aa8b-a22b-45de-a838-d06eeadb4b4e", <--- origin ID
  "targetNamespace": "space-b",
  "targetId": "3bb6dbb-46af-4a8c-a734-8dc3ef50b4d9" <--- new ID in Space B
}