[Lens] Make Lens visualizations shareable across Spaces

[nickpeihl]

As a precursor to https://github.com/elastic/kibana/issues/167901, we think it might be best to make Lens visualizations shareable across spaces. The @elastic/kibana-presentation team would like to help with this so we can get closer to Shareable Dashboards.

Lens was made "share-capable" in 8.0. To make Lens completely "shareable" we need to complete the steps in Phase 2 of the "Sharing saved objects" documentation.

However, there are a few issues not covered by the documentation.

Related objects such as data views and annotation layers are automatically shared to other spaces when sharing a Lens visualization from the Saved Objects management. However, a user can still change or add a related object (data view, for example) to an existing Lens visualization where the data view is not available in the other spaces. We have a similar issue for dashboards.

I think, ideally, we would warn the user immediately if the related object they are adding is not available in other spaces.

For data views, perhaps we prepend a warning icon to the options in the Data View picker when the data view is not shared? Or disable the option completely? @elastic/kibana-design

For annotations that are added from the library we may need a similar warning icon or disable unshared annotations.

@elastic/kibana-visualizations Are there other related objects in Lens besides Annotations and Data views that we need to consider?

[stratoula]

@nickpeihl thanx for creating the issue! This is it, Lens visualizations reference annotation groups and dataviews. Just for my information, how do we know if a dataview/annotation group is not sharable?

[nickpeihl]

...how do we know if a dataview/annotation group is not sharable?

A dataview or annotation group will not be shareable if the user editing a shared Lens visualization does not have write access to all of the spaces where the Lens visualization is shared. But in that case the user should also not be allowed to make any changes to the shared Lens visualization. 🤔

[MichaelMarcialis]

For data views, perhaps we prepend a warning icon to the options in the Data View picker when the data view is not shared? Or disable the option completely? @elastic/kibana-design

I'm not sure I'm fully understanding. How would a user find themselves in this situation, if all related saved objects are automatically shared with the originating saved object? Would this only occur if a user manually un-shares those related saved objects but continues to share the originating saved object? If so, should we be allowing users to un-share saved objects that are considered dependencies to other objects that will retain the shared status?

In any case, I'm not certain a warning on the data view selector in the unified search interface would be desirable. In a situation where a Lens visualization uses additional by-reference elements (i.e. related saved objects) that are not shared in the current space, I imagine we would indicate that at the layer-level within a Lens visualization (similar to how I assume we handle related saved objects that were accidentally deleted). For example, if it's an issue of a data view not being shared in the current space, all layers using that data view would ideally show an error on their respective data view selectors. Similarly, if an annotation group doesn't exist in the current space, I imagine we would show some kind of error for that annotation group layer.

[stratoula]

@nickpeihl yes I am also a bit confused.

How do I end up to this situation?

However, a user can still change or add a related object (data view, for example) to an existing Lens visualization where the data view is not available in the other spaces.

From my understanding when I export a visualization all the referenced SOs are also exported with it and imported. This is why I don't get it. In which scenarios the dataview that is referenced in a Lens viz won't be shared?

[nickpeihl]

Here is a scenario where we could end up in this situation. For this example, I would be using this draft PR which makes Lens visualizations shareable across Spaces.

Set up spaces, roles, and users

1. In a cluster, the superuser "elastic" installs the flights and web logs sample data in the default space.

2. Next superuser "elastic" adds two more spaces, "Space1" and "Space2".

   Expand to see the Dev Console commands

POST kbn:/api/spaces/space
{
  "id": "space1",
  "name": "Space1",
  "color": "#aabbcc",
  "initials": "S1",
  "disabledFeatures": []
}

POST kbn:/api/spaces/space
{
  "id": "space2",
  "name": "Space2",
  "color": "#ffccff",
  "initials": "S2",
  "disabledFeatures": []
}

3. The superuser "elastic" uses the Stack Management - Saved Objects page to share the "[Logs] Bytes distribution" Lens visualization to "Space1" and "Space2". The "Kibana Sample Data Logs" data view that is referenced in the Lens visualization is also shared to both spaces automatically.

Expand to see screenshot

4. The superuser "elastic" also shares the "Kibana Sample Data Flights" data view to only "Space 1".

Expand to see screenshot

5. Next the superuser adds roles that apply permissions to these spaces. Each role is also granted "view_index_metadata" and "read" permissions on the two sample data indices:
   • space1_writer: has "All" permissions on Space1
   • space2_writer: has "All" permissions on Space2
   • space2_reader has only "Read" permissions on Space2

Expand to see the Dev Console commands

``` PUT kbn:/api/security/role/space1_writer { "metadata": { "version": 1 }, "elasticsearch": { "cluster": [], "indices": [ { "names": [ "kibana_sample_data_logs", "kibana_sample_data_flights" ], "privileges": [ "view_index_metadata", "read" ], "allow_restricted_indices": false } ] }, "kibana": [ { "base": [ "all" ], "feature": {}, "spaces": [ "space1" ] } ] } PUT kbn:/api/security/role/space2_writer { "metadata": { "version": 1 }, "elasticsearch": { "cluster": [], "indices": [ { "names": [ "kibana_sample_data_logs", "kibana_sample_data_flights" ], "privileges": [ "view_index_metadata", "read" ], "allow_restricted_indices": false } ] }, "kibana": [ { "base": [ "all" ], "feature": {}, "spaces": [ "space2" ] } ] } PUT kbn:/api/security/role/space2_reader { "metadata": { "version": 1 }, "elasticsearch": { "cluster": [], "indices": [ { "names": [ "kibana_sample_data_logs", "kibana_sample_data_flights" ], "privileges": [ "view_index_metadata", "read" ], "allow_restricted_indices": false } ] }, "kibana": [ { "base": [ "read" ], "feature": {}, "spaces": [ "space2" ] } ] } ```

6. Finally the superuser adds two users:
   • Bob: has the space1_writer and space2_reader roles
   • Alice: has the space1_writer and space2_writer roles

Expand to see the Screenshots

User perspective

Bob opens the shared "[Logs] Bytes distribution" Lens visualization on Space1 where he is a writer. Bob decides to add another Layer to the visualization that uses the "Kibana Sample Data Flights" data view. Bob saves his changes to the visualization.

Later, Alice opens the shared "[Logs] Bytes distribution" Lens visualization on Space2. Unfortunately, she receives an error because the visualization now includes a reference to the "Kibana Sample Data Flights" data view, but that data view is not shared to Space2.

Concerns

Here are the issues that I'm seeing:

• Bob has write access to only Space1, but by design, he is allowed to make changes to the shared saved object even when he does not have the "all" permission in the other spaces.
• Editing an shared existing visualization does not automatically share any new related objects to the other spaces.
• Lens could add some logic during "Save" to verify all the related objects are also available in the other spaces.
• Unfortunately, in this scenario, Bob can not share a saved object to Space2 since he only has "read" permission. In this case, Lens would probably need to catch this and not allow Bob to save his changes to the shared visualization. Perhaps Lens would suggest instead saving as a new visualization in "Space1"?

[stratoula]

Thanx for the very well written example @nickpeihl!

Ok this is very complicated and I am not sure about the user experience so these are just my thoughts:

Bob has write access to only Space1, but by design, he is allowed to make changes to the shared saved object even when he does not have the "all" permission in the other spaces.

If the point of sharing a visualization/dashboard/saved search etc is that the changes a user makes to space1 must be reflected to spacec2, if a user doesn't have write permissions to all spaces (that this visualization is shared) should not be allowed to edit this visualization imho.

Lens could add some logic during "Save" to verify all the related objects are also available in the other spaces.

In the visualization dataview picker, we should see only dataviews that can be used (meaning only dataviews that are shared to the spaces that the visualization is shared). Same for annotation groups etc.

[nickpeihl]

If the point of sharing a visualization/dashboard/saved search etc is that the changes a user makes to space1 must be reflected to spacec2, if a user doesn't have write permissions to all spaces (that this visualization is shared) should not be allowed to edit this visualization imho.

If/how we decide to allow editing of shared saved objects is probably best done holistically rather than per application. I think it would be confusing to restrict Bob from editing a Lens shared object, but permit him to edit a shared Data view.

Here is another suggestion for this problem. In this case, Bob may still be able to make changes to the shared visualization. And when Alice opens the viz in Space2 she is given a better error message with a suggestion on how to fix the missing reference. Unfortunately, this puts the burden on Alice to fix the issue inadvertently caused by Bob.

Perhaps saved objects shared across Spaces are meant to be collaborative? In that case, it would be acceptable that Bob (with his "all" access to Space1) can change a saved object that also exists in Space2 (where Bob has only "read" access). If we add another user, Alan, who belongs to a "space1_reader" and "space2_reader" role, then Alan would not be able to edit the shared visualization. I wonder if this is by design, @elastic/kibana-security?

If I understand correctly, Object level security would allow users apply more restrictions on saved objects (shared or not). But that feature is not on the near term roadmap.

[stratoula]

If/how we decide to allow editing of shared saved objects is probably best done holistically rather than per application. I think it would be confusing to restrict Bob from editing a Lens shared object, but permit him to edit a shared Data view.

@nickpeihl got it. I thought that we are discussing how this will work holistically but it seems that the behavior has been decided. 👍

The other solution you propose also makes sense. But imho makes things more complicated. My biggest concern is the scenario where Alice can't make the missing reference shareable in space2 (let's say she doesn't have this permission). In that case she will most possibly try to assign a dataview that exists in space2 or contact the administrator to share the missing dependency. So she is possibly stuck or messing up with Bob's visualization. Of course if we assume that this feature is meant to be collaborative the above concerns are edge cases.

But I think that for adding dataviews/annotations in Lens the cleanest way is the one I propose here.

In the visualization dataview picker, we should see only dataviews that can be used (meaning only dataviews that are shared to the spaces that the visualization is shared). Same for annotation groups etc.

So the user can edit a visualization (even if he doesnt have all permissions in all spaces) but they can't mess up with it. Is it something we can do technically?

[teresaalvarezsoler]

Thanks for the discussion on this @stratoula @nickpeihl @MichaelMarcialis, I think all the points raised make sense.

However I would prefer not to make any decision until we know more about object-level security project otherwise we risk having a spaguetti UX and undoing the changes later on. I will catch up with @arisonl on this and provide an update. Worst-case scenario, we can live with the consequences of Alice seeing a not very self-explanatory error as a temporary state until we can look at the UX more holistically together with the security team.

[nickpeihl]

@stratoula

But I think that for adding dataviews/annotations in Lens the cleanest way is the one I propose here.

In the visualization dataview picker, we should see only dataviews that can be used (meaning only dataviews that are shared to the spaces that the visualization is shared). Same for annotation groups etc.

So the user can edit a visualization (even if he doesnt have all permissions in all spaces) but they can't mess up with it. Is it something we can do technically?

I agree with this. Bob can edit the saved object because he has permission in at least one space. However, he can not share a related object (such as a data view) to another space because he needs permissions in the destination space. So it would make sense to hide data views that are not already shared or that Bob can not share.

@teresaalvarezsoler

However I would prefer not to make any decision until we know more about object-level security project otherwise we risk having a spaguetti UX and undoing the changes later on. I will catch up with @arisonl on this and provide an update.

Thanks. I think this is the best course of action.

[legrego]

Perhaps saved objects shared across Spaces are meant to be collaborative? In that case, it would be acceptable that Bob (with his "all" access to Space1) can change a saved object that also exists in Space2 (where Bob has only "read" access). If we add another user, Alan, who belongs to a "space1_reader" and "space2_reader" role, then Alan would not be able to edit the shared visualization. I wonder if this is by design, https://github.com/orgs/elastic/teams/kibana-security?

Yes, this is by design. The fact that a saved object is shared does not change the fundamental authorization model, which permits/denies actions based on your privileges within your current space.

If I understand correctly, https://github.com/elastic/kibana/issues/39259 would allow users apply more restrictions on saved objects (shared or not). But that feature is not on the near term roadmap.

Correct, OLS would provide a more robust solution.

[arisonl]

Here is a little more context, hoping that it will "decipher" the made decisions on the platform security level:

The current authZ model must be respected. This has two consequences:

1. A user with all in this space, can edit the object in this space, regardless of their privileges in other spaces where this object is shared (i.e. what Larry mentioned). If this was not the case, the act of sharing may cause other users to have their privileges effectively downgraded.
2. If a user has read in this space-A, they cannot share the object to space-B where they have all access. Here is why: If they were able to do so, they could share to space-B and edit the shared object there. Effectively this would mean that with the act of sharing they gave themselves all in space-A too, where they had read. As a result, users need to have all in both spaces in order to be able to share objects between them (it is more obvious why they cannot share to space-B in the inverse scenario where they have read in space-B and all in space-A).

Regarding OLS: This is less of a decision but it is the most natural path to consider: it is far more likely that the path that we will pursue is private objects (objects that are owned by their creators and can stay private to them) rather than OLS of any other form. If that development materializes, users will be able to share a private object "publicly" when they choose and once they do so, it is natural to imagine that we would apply the "respect the model" principle again. I.e.: from that point on, the said private object is made "publicly" available in a space and all current rules apply (the other users can now access it depending on their privileges in that space).

cc @stratoula @nickpeihl

[MichaelMarcialis]

Tossing in my two cents here, based on the comments from @nickpeihl and @stratoula above.

• Editing an shared existing visualization does not automatically share any new related objects to the other spaces.

But can we automatically share new dependency saved objects? Or do we not because it is a security concern to have users trigger the automatic sharing of dependencies in a space where they only have read-only privileges?

If we could support this sort of automatic sharing behavior (while also properly notifying users along the way) that would certainly help to solve the core problem presented here. If it is a security concern, would adding an opt-in mechanism during the share workflow to allow privileged users to make that decision themselves alleviate any of that concern? Either way, I feel this automatic sharing behavior is less of a read-only user getting conditional write privileges, but more of our attempting to honor the original privileged user's wishes (only triggered by the read-only user).

• Lens could add some logic during "Save" to verify all the related objects are also available in the other spaces.

Assuming we are able to automatically share dependencies as described above, if a user makes a change that requires dependencies to be added to one or more spaces, I could see it being useful to notify users of that fact during the save workflow (but still performing the share automatically for the sake of a good user experience).

• Unfortunately, in this scenario, Bob can not share a saved object to Space2 since he only has "read" permission. In this case, Lens would probably need to catch this and not allow Bob to save his changes to the shared visualization. Perhaps Lens would suggest instead saving as a new visualization in "Space1"?

As mentioned above, is there a way we could allow for the share to happen automatically, even if the user that added the dependency it doesn't have write permissions for the other necessary space(s)? Seeing as the visualization was already shared to those spaces by a privileged user, I personally don't see it as a violation to allow the automatic sharing of dependencies across those spaces, even if I don't have privileges to write in one or more of them, assuming the parent saved object was shared by a privileged user. If I'm in the minority and others see it as problematic, then perhaps the opt-in idea suggested above is a viable alternative (before we start hitting users with error messages or asking them to create forked visualizations).

If the point of sharing a visualization/dashboard/saved search etc is that the changes a user makes to space1 must be reflected to spacec2, if a user doesn't have write permissions to all spaces (that this visualization is shared) should not be allowed to edit this visualization imho.

This is an interesting proposal as well (a sort of inversion of my auto-sharing suggestion). If a saved object is shared across spaces that a user don't have write access to, and auto-sharing is not viable from a technical or security perspective, perhaps they shouldn't be able to edit that saved object. Instead, users should be given the lowest level privilege based on their role for all spaces that object is shared with, regardless of what space they currently occupy.

Is either direction viable? With Stratoula's direction, we restrict user privileges to prevent causing the dependency issue. With the direction I propose above, we sort of extend user privileges to prevent causing the issue. In either case, it puts up guard rails to prevent these shared saved objects from breaking due to dependency privilege issues, which I quite like. Thoughts?

[mwtyang]

cc @teresaalvarezsoler @ninoslavmiskovic

[stratoula]

Personally I agree with @MichaelMarcialis.

In either case, it puts up guard rails to prevent these shared saved objects from breaking due to dependency privilege issues, which I quite like.

My thoughts exactly ++

[teresaalvarezsoler]

We have been discussing this with the presentation team and we have a proposal which will fix the issue, provide a good UX for the users, respect the current permission model and it can be implemented across all apps. I organized a brief meeting because this thread has become too long and messy. We will go over the problems, the alternatives mentioned here and our recommendation. I will include the conclusions of that meeting here later on.

[arisonl]

I think that we need to make this UX as guided and clear as possible.

A working assumption: If the viz is not already shared and you don't have the access to share it either, maybe there is a good reason for that, and so maybe you should not be adding it onto a shared dashboard in the first place (the loading errors on the dashboard are not the end UX intentionally, but they are also a "feature", not a bug).

The user intention is important at this point, and it may be (at least) two things: Is it primarily shared edits or is it primarily to reuse (perhaps as a "template") and enhance the dashboard in current space?

If the first, then you should be made aware that adding a non-shared viz is not one of the possible edits that can be made by you (and that's fine because of the assumption above). A proactive UX would warn you early (once you attempt to add). If you are not warned early, you should be given a clear path to save the rest of your edits, i.e. any other edits that you may have done, excluding the addition of the non-shared viz (because your primary intention was shared edits), as an alternative to cloning which does not work well for this intention.

If the latter, things are happier: cloning works well and there is no share-vs-copy confusion (because your primary intention was reuse, not shared edits).

[teresaalvarezsoler]

Thanks Aris, I think your assumptions are correct and I like the solutions you are proposing. Some comments:

If the first, then you should be made aware that adding a non-shared viz is not one of the possible edits that can be made by you (and that's fine because of the assumption above). A proactive UX would warn you early (once you attempt to add).

I agree it would be the best UX. But we will need to consider all the possible scenarios in which a user could add a non-shared object to each saved object which seems a very high effort to me. @nickpeihl @cqliu1 ?

If you are not warned early, you should be given a clear path to save the rest of your edits, i.e. any other edits that you may have done, excluding the addition of the non-shared viz (because your primary intention was shared edits)

I like this idea and it seems less effort than the previous proposal, but I'm not sure if it is technically feasible and how much effort it implies @nickpeihl @cqliu1 ?

If the latter, things are happier: cloning works well and there is no share-vs-copy confusion (because your primary intention was reuse, not shared edits).

I agree we should still give the option of cloning to save all the changes in your current space.

[nickpeihl]

Thanks Aris, I think your assumptions are correct and I like the solutions you are proposing. Some comments:

If the first, then you should be made aware that adding a non-shared viz is not one of the possible edits that can be made by you (and that's fine because of the assumption above). A proactive UX would warn you early (once you attempt to add).

I agree it would be the best UX. But we will need to consider all the possible scenarios in which a user could add a non-shared object to each saved object which seems a very high effort to me. @nickpeihl @cqliu1 ?

Agree that this is a high effort. The API calls for determining permissions are similar, but each application (Dashboard, Lens, Maps, etc) would need to add the appropriate UX and UI to warn the user.

Additionally, any application that embeds by-value panels into Dashboard would need probably need to handle a property passed from the shared dashboard to know to which spaces the dashboard is shared.

If you are not warned early, you should be given a clear path to save the rest of your edits, i.e. any other edits that you may have done, excluding the addition of the non-shared viz (because your primary intention was shared edits)

I like this idea and it seems less effort than the previous proposal, but I'm not sure if it is technically feasible and how much effort it implies @nickpeihl @cqliu1 ?

I think this is the easiest path. Most applications use the a shared content management API which is called when the user clicks the "Save" button. Content management could make the calls to the spaces APIs to determine permissions and warn the user if they lack permission to share related objects.

If the user lacks permission, then we could offer them to save a new copy. ⬇️

If the latter, things are happier: cloning works well and there is no share-vs-copy confusion (because your primary intention was reuse, not shared edits).

I agree we should still give the option of cloning to save all the changes in your current space.

[teresaalvarezsoler]

If the user lacks permission, then we could offer them to save a new copy.

@nickpeihl Aris was also proposing to offer users the chance of saving only the changes that they are allowed to make. E.g. if a user is trying to save a by-value panel (panel A) and a non-shared by-ref panel (panel B) at the same time to a shared dashboard and she has not write permissions in all spaces, we can offer her to save the panel A but not the panel B. Not sure how the UX would look like though or if this is very complex to implement. Maybe this can be phase 2 of this project and we just offer the cloning option for now.

[stratoula]

@teresaalvarezsoler

If the viz is not already shared and you don't have the access to share it either, maybe there is a good reason for that, and so maybe you should not be adding it onto a shared dashboard in the first place

This is what I think is the best experience. With this way you are certain that you are not going to mess up the dashboards for other users. I personally don't think that this will be an edge case. And if a user edits a dashboard panel and selects a non shared dataview then this dashboard will break on all other spaces. The other users won't have any escape hatch. But I agree that there are many points where we should make these checks so as you said correctly this makes this task quite big

If you are not warned early, you should be given a clear path to save the rest of your edits, i.e. any other edits that you may have done, excluding the addition of the non-shared viz (because your primary intention was shared edits)

I am not sure how the UX will look like here. So if I understand the proposal correctly I save the things that have nothing to do with the non-shared viz but not the things connected to the non-shared viz. This sounds tricky to me and complicated taken under consideration the tree of dependencies among our SOs. Unless I interpret this wrongly

Our permissions system in general is not great. Try to play with them and check how the dashboards and visualizations work for the different settings. I am afraid that we are going to add another system which is confusing for the users (and us). Our SOs are very nested. Are we ready for giving the sharing capability to our dashboard? Maybe we need to think more about it. Which is the best experience for all users? It might require a lot of work and we might decide to not prioritize it now but at least we will have a good plan.

cc @timductive

[nickpeihl]

@nickpeihl Aris was also proposing to offer users the chance of saving only the changes that they are allowed to make. E.g. if a user is trying to save a by-value panel (panel A) and a non-shared by-ref panel (panel B) at the same time to a shared dashboard and she has not write permissions in all spaces, we can offer her to save the panel A but not the panel B. Not sure how the UX would look like though or if this is very complex to implement. Maybe this can be phase 2 of this project and we just offer the cloning option for now.

Sorry, I missed that. I agree with Stratoula that rolling back edits that can not be shared would be quite difficult. Our editing applications do not have a great edit tracking system. And trying to determine which edits can and can not be persisted at save is likely tricky and prone to bugs.

[MichaelMarcialis]

If the viz is not already shared and you don't have the access to share it either, maybe there is a good reason for that, and so maybe you should not be adding it onto a shared dashboard in the first place

This is what I think is the best experience. With this way you are certain that you are not going to mess up the dashboards for other users. I personally don't think that this will be an edge case. And if a user edits a dashboard panel and selects a non shared dataview then this dashboard will break on all other spaces. The other users won't have any escape hatch. But I agree that there are many points where we should make these checks so as you said correctly this makes this task quite big

++ For what it's worth, based on all the information I now have and the discussions we've had regarding this scenario, I strongly agree with @stratoula and @arisonl's take here.

If you are not warned early, you should be given a clear path to save the rest of your edits, i.e. any other edits that you may have done, excluding the addition of the non-shared viz (because your primary intention was shared edits)

I am not sure how the UX will look like here. So if I understand the proposal correctly I save the things that have nothing to do with the non-shared viz but not the things connected to the non-shared viz. This sounds tricky to me and complicated taken under consideration the tree of dependencies among our SOs. Unless I interpret this wrongly

I share the same fears as @stratoula. This direction can get very messy very quickly, no matter how much UX polish and UI we throw at it. If we don't go about preventing the issue from happening proactively (as per the direction above), then we are opening up the experience to significant risk of confusion and putting a large burden on the user. Let's run through a rough scenario:

1. You makes changes to a dashboard that is shared across multiple spaces. One of those changes includes adding a visualization that either isn't shared in those same space, you don't have access to one or more of those other spaces, or both.
2. You attempt to save your dashboard changes.
3. You're informed that you can only save some of your changes to the dashboard, but not all of them because of a permissions issue (that you're likely not familiar with or not interested in). Do you want to save only the subset of changes that you are allowed to share?
4. Ok, shareable changes are saved. Now what about the rest of your dashboard changes that couldn't be shared (due to that permission issue)? Do you want to save those changes too?
5. You're informed that we can save those unsharable changes, but only in the form of a cloned/duplicated dashboard. Are you OK with that?
6. You're also informed that this new cloned/duplicated dashboard won't be shared to the same spaces as the originating dashboard (again, due to the aforementioned permissions issue).
7. Are you confused yet? 🤪

I feel pretty strongly at this point that the best, safest, and most user friendly path forward is to simply not allow users to get into such a tangled mess.

[teresaalvarezsoler]

Thanks @MichaelMarcialis, we all agree that if users have no permissions to share objects to other spaces, they shouldn't do that. But restricting edition doesn't consider the use case of customers wanting to save changes "locally" in the current space (as @arisonl was pointing out). For this use case, cloning will be the best option.

I agree that saving only part of the changes can be a bit messy and we need to think through it a bit more. Maybe for a phase 2 or 3 of this project.

I think that giving users the ability to clone fixes the issue of saving the changes to the current space while it respects the current permission model. We can improve this UX in the future by warning users in advance. I'm contacting multiple customers that requested sharing dashboards in the past to get their feedback on this solution and the other decisions we are making for this project. Please lmk if you want to participate in these sessions.

[MichaelMarcialis]

Please lmk if you want to participate in these sessions.

Sure, I certainly wouldn't mind listening in on those sessions.

[nreese]

Closing, issue iceboxed in https://github.com/elastic/kibana/issues/188573