Hi GoodData support, I'm working on LCM implementation, and I'm trying to allow user who has Editor role in the client workspace can edit dashboard synced from master workspace. in the https://help.gooddata.com/doc/growth/en/dashboards-and-insights/dashboards/share-dashboards/, I see this information

Editors cannot edit dashboards synchronized from LCM or dashboards that have the Only admins can edit this dashboard option enabled. These dashboards are at the top of the list and has a lock icon next to their names.

My question is "can Editor have a workaround solution so that Editor can edit dashboard synced from LCM?"

Hi Nam, Editors can certainly edit reports and dashboards, but you should tag the reports and dahsboards correctly so those changes don't get overwritten when you run the release brick next. You can find more information on the tags here: https://help.gooddata.com/doc/growth/en/workspace-and-user-administration/managing-workspaces-via-life-cycle-management/bricks/release-brick/#R[…]gs

Hello Nam Phan, you are correct that in case of GD Platform LCM, the dashboards, reports/visualizations and even the metrics coming from the master workspace get “locked” - that prevents them from modification by any other user than Administrator. As far as I know there is no way around this (apart from granting end users admin role, but I would certainly not recommend that). Editors can still create a copy of any “locked” object and modify this copy. So that would be the proper way how to manage that. There is a reason for that. Since the objects coming from the master get overwritten with every release, any changes made by editors on these would be lost.

thanks for confirmation, your words make me feel more confident when I discuss with my product manager 🙂

What exactly do you mean by "stop syncing from master workspace"? Do you mean just stop syncing those dashboards? Or stop syncing the whole workspace somehow? Probably easiest way how to stop syncing just the dashboards is to create a copy of them directly in the workspace (just open the original and perform "save as"). A new dashboard object with new ID gets created and this one won't be overwritten by rollout. But note that apart of the dashboard definition, each inisght and metric it uses is also an object synchronized from the master workspace.

stop syncing from master workspace mean that I don't want to copy them to client workspace. For example, with LCM implementation, when a new workspace is created, this workspace doesn't have these dashboards which are synced from master workspace.

I see. Let me try to elaborate: • If you modify the master workspace after the release, I believe the rollout will then deploy any changes based on this master workspace including the potential changes. The release just prepares a clean copy of the current development for this purpose. But all the “distribution magic” is in the rollout. So I don’t think this works for your case since it would distribute these copies to all the clients. • I guess you can simply do the “save as” directly in your client’s workspace - so these copies with separate IDs will only live there and won’t be in the development workspace at all and you don’t need to worry about them being distributed. • If you also wanted to hide the standard (LCM distributed & locked) versions of these dashboards in that specific workspace (not to confuse your users by having two versions), you might use the Object Rename Brick for that - apart from renaming objects based on workspace/client + object identifier it also allows you to set it to “deprecated” which means it is hidden from the UI. You might need to run this after each rollout as that would un-deprecate the standard objects again. (Or you can hide/delete them manually after each rollout)

thanks for your help Michal. I got your point and will check Object Rename Brick to see if it's suitable for our case.