[Lens][Dashboard] Improve feature visibility handling in spaces

[dej611]

Describe the feature:

When configuring a space it is possible to set a feature visibility for the Analytics group (and others of course).

The panel quote:

Set feature visibility Hidden features are removed from the user interface, but not disabled. To secure access to features, manage security roles.

The quote is a bit ambiguos but the security team clarified the initial intention as UI vs API: disabling the visibility here originally meant to hide any UI and allow only API access. So not a role configuration, just a "masking" behaviour.

Now, with Dashboard and Visualize Library things get a little bit more complex, in particular when considering by_reference and by_value visualizations. Currently the behaviour is inconsistent: configuring a Dashboard only access to a space, a user can create a Dashboard, open a dashboard, but then when in Edit mode some panels hint the user the ability to edit it, while failing (Application not found), while others won't show the edit ability. From a quick check here a partial list:

• Markdown panel will show the edit button, leading to an error page :x:
• Maps won't show the edit button
• TSVB won't show the edit button
• Lens mostly show the edit button (in some particular configuration it won't, not clear why...) ❌
• Dashboard controls can be fully edited
• It is still possible to create a visualization (via main Create or Select type or Markdown buttons) and land on an error page ❌

After some internal discussion with the @elastic/kibana-visualizations team we decided to create this issue to discuss with the @elastic/kibana-presentation team about the topic.

Few questions here to clarify:

• are Visualizations editor part of the Visualize Library? Or are they orthogonal as "library" only meant "place where visualizations are stored"?
• if a space is configured to only allow Dashboard visibility, with full role capability, should the user be able to:
  • see any visualization panel by_reference?
  • edit any visualization panel (either by_value or by_reference)?
  • how should be handled roles here (None | Read | Write) - it adds a new level of complexity but worth to discuss while here.

[elasticmachine]

Pinging @elastic/kibana-visualizations @elastic/kibana-visualizations-external (Team:Visualizations)

[ThomThomson]

The most obvious way to straighten this out would be to relate these permissions to the various types of saved objects, roughly as follows:

Dashboard permissions

• If a user has dashboard read they should have access to the dashboards listing page and individual dashboards.
• If a user has dashboard read but not dashboard write the edit mode button should be inaccessible * hidden
• If a user has dashboard read, but doesn't have Visualize Library read then by value panels should show up, but by reference panels should show an obvious permissions error
• If a user has dashboard write they should be able to open any editor and save to a dashboard by value.

Visualize Library

• If a user has library read, then they should have access to the visualize library app, and should be able to see by reference panels on a dashboard.
• If a user has library write, they should be able to save to the Visualize library library
• If a user has library write but no dashboard write, the saving options should only show the visualize library, and none of the dashboard-related options.

That said, that may not be the correct way to think about this, and I'm open to other suggestions. One major drawback of this thought process is that it requires a lot of small UI changes and introduces a lot of complexity.

Maybe instead we need to combine Visualize Library and Dashboard into one feature. Because I'm not exactly sure if users would get much use out of having one without the other, or the ability to lock down one but not the other.

[dej611]

The most obvious way to straighten this out would be to relate these permissions to the various types of saved objects, roughly as follows:

You mean completely ignore the current Space visibility feature and just use the roles configuration? Because I think that using roles it is already possible to model this otherwise.

That said, that may not be the correct way to think about this, and I'm open to other suggestions. One major drawback of this thought process is that it requires a lot of small UI changes and introduces a lot of complexity.

Maybe instead we need to combine Visualize Library and Dashboard into one feature. Because I'm not exactly sure if users would get much use out of having one without the other, or the ability to lock down one but not the other.

I agree it would make sense to merge the two together, and it would probably solve most of the conflicts in this area.

[stratoula]

I am afraid we can't merge them together because there are applications (such as cases) that allow to add on a case a visualization from a library. About the spaces we should think what each of these options mean and what should be hidden.

About the security roles I like what @ThomThomson proposes, not sure if our current roles work like that but while it might need some UI changes, I feel that this is the right path. In my mind visualize library is the listing page + the by reference visualizations that can be used by other applications across kibana (cases, dashboard, canvas etc) while by value visualizations are the visualizations that come with a specific dashboard.

[ThomThomson]

If we are in agreement on how the security roles work, we might need to book a meeting to discuss implementation details, and how it would be split up?

[timductive]

I think that the concern from a user perspective that has read permissions for dashboard and visualizations may seem to randomly work or not (because they are either by-value or by-reference) is a real one and we need to think about this. I align closer to dashboard and visualizations on that dashboard should be grouped together for permissions.

Perhaps this is a Product research topic before we go too deep on implementation. I'm curious where all the edge cases are and I suspect we are overdo to simplify this model. @ninoslavmiskovic

[stratoula]

@timductive thanx :) I added a meeting with representatives from the appex analyst xp to check the current status. I will try to gather all cases to initialize the discussion.

[ThomThomson]

@stratoula, what is the latest on this? Is it on hold due to serverless?

[stratoula]

Devon I missed this ping 🙈 It is on hold for now due to other projects.