-
Notifications
You must be signed in to change notification settings - Fork 8.1k
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
Read-only UI behaviour for system managed dashboards installed as part of fleet packages #140364
Comments
Pinging @elastic/kibana-presentation (Team:Presentation) |
One piece of this that might require some changes in the saved object system, and should be figured out first is how we determine which objects are read only / system managed. I don't believe there is any system in place that we could extend to support this. Once we can Figure out some way to store that information, accessing it and changing the UI to limit edits / guide users to clone the dashboard will be fairly straightforward. |
Although there isn't any read-only capability, today fleet packages use a tag to indicate that a saved object is "system managed" and discourage users from editing it. This tag has a fixed ID which could make it somewhat simpler to detect it's presence https://github.com/elastic/kibana/blob/main/x-pack/plugins/fleet/server/services/epm/kibana/assets/tag_assets.ts#L22 The other option would be to have a new @elastic/fleet Do you have an opinion on what might be the best way to persist a dashboard's read-only status? |
some background context: the presentation team recently added the ability for dashboards to have a read-only UI that hides the edit button. So if we can agree on the best mechanism for fleet packages to indicate that they prefer this read-only UI the presenation team thinks it would be trivial to hook that up. |
Currently on Fleet we use
From a saved objects perspective I can see why we might want something generic like |
@hop-dev All fleet package installed saved objects get the managed tag right? But does it mean that we want to prevent users from editing all these saved objects? There is a sense that if I edit a managed dashboard I could break it. But maybe for some packages we might want to encourage users to modify a dashboard whereas others we really want to avoid them touching it. |
Also to clarify this is purely a UI feature. "readonly" won't prevent a user from editing a dashboard through the API or by importing it. But it could protects against casual users accidently changing something that's critical for an integration. |
Yes that's right
Definitely for dashboards the aspiration is that the user has to copy them to edit them as discussed in #70461. I can't think of an asset type where we wouldn't want to have this approach, but dashboards are the ones most likely to be edited by the user.
I can't think of an existing package where this would be the case.
Understood 👍 |
Am I understanding correctly, that the information for which saved objects are managed / read-only is already present? Either in the managed tag, or in this |
@ThomThomson - Fleet does include the kibana/x-pack/plugins/fleet/server/services/epm/kibana/assets/tag_assets.ts Lines 85 to 109 in c2c9cab
Fleet also includes kibana/x-pack/plugins/fleet/server/services/epm/elasticsearch/meta.ts Lines 14 to 33 in c2c9cab
Let me know if this is enough to answer your questions above! |
That's great that the information is present! @rudolf, is there any chance we could add a simple method to saved objects, or even the saved objects client that can return a boolean like |
I agree that a standardised It would make the most sense for the |
We discussed this in our team meeting. The managed tag has the nice advantage of automatically being visibily across most of the UI as a clear sign to a user. But it comes with some disadvantages like needing different tag ids per space which then makes it complex to determine if a saved object is really managed. It seems to us like a better "contract" between fleet and other plugins' Apps might be if we add a new root level property to all saved objects like We wouldn't provide an API method / sugar around this property, probably just documenting the purpose of the property is enough so that the dashboard app can just read the value and change it's behaviour accordingly. |
+1. This is something that we have been considering part of the long-term roadmap for the Content Management project. Will get something together for when Vadim is back to talk about if the 'managed' property should be part of that effort. |
Plan:
|
If priorities allow for it (and we still need to do the work), I can pick this up after returning to the office near the end of March. Please note that changes to the saved objects repository are needed too and those may have higher priority. I'll be OOO from 13 to 20 March. |
@ThomThomson, @joshdover FYI, I'm working on #140364 (comment) in #154515 and will follow up with a second PR to finish those parts off. |
@TinaHeiligers, amazing, looking forward to it! |
@ThomThomson, @joshdover, the PR for importing objects as managed is |
@elastic/kibana-presentation do you want to use this issue to continue with the UI work or will you open a new issue for that? |
I have added this question to your team sync discussion notes. It will be a few days before we reply with an answer |
@TinaHeiligers we discussed as a team and would like to track presentation effort with this issue. So please keep this open for us |
@nreese I'm adding your name to the issue for visibility. |
Correct me if I'm wrong, but I think the scope of the Fleet ask is larger than dashboards. Integrations can include
I happened upon this issue and have created a similar one for the visualization editors, but I would expect all the relevant Kibana content editors to respect managed content. I'm wondering if there's room for a meta issue for this? |
@drewdaemon You are right that the scope is larger. I think the thinking here was that Dashboards are the most commonly used asset type and the one users are most likely to customize so we'd start there. I could be wrong, but my assumption was also that with the move to viz-by-value that fixing this for dashboards covers most integration viz's.
We only have 7 integrations that contain maps today so I think this is low prio.
We actually want users to be able to modify some parts of Data views, such as runtime fields. See #120340. Any input you have there could be helpful as well.
Yeah we should probably prioritize this one 👍
Security rules have their own flow for handling this that supports 3-way merge of user-modifications with the updated rule on package upgrade. |
In #70461 the fleet team asked for the ability to mark saved objects installed as part of a fleet package as "system managed" and for such saved objects to have special behaviours. Although this could apply to many types of saved objects the primary ask was for dashboards (and any references it could have to visualizations, data views, searches etc).
The request could be broken down into two parts:
Since (2) will have to be application specific and does not need to be blocked on (1) I created this separate issue so that we can track these as separate concerns.
The text was updated successfully, but these errors were encountered: