Hi there, my team has created child pages from a parent workspace, but is unable to edit the child pages despite having being part of the admin group. Is this a bug or is it not possible to adjust child pages to be different than the parent?

Hi Chris, thanks for reaching out, happy to help. Firstly allow me to confirm if you’re referring to child workspaces in this case. If so, I recommend managing workspace permissions for each workspace. This is because in GoodData Cloud, user groups and permissions are not automatically inherited from parent to child workspaces. Even if you're an Admin in the parent workspace, that does not grant admin or edit access to child workspaces by default. You need to manually assign roles or groups to each child workspace: Here are some links to our documentation you can refer to on this. https://www.gooddata.com/docs/cloud/workspaces/permission-hierarchies/ https://www.gooddata.com/docs/cloud/manage-organization/manage-permissions/set-permissions-for-workspace/ Please let us know if this helps.

Also, if you are talking about GoodData Cloud workspace hierarchy with parent and child workspaces, even if you are admin in the child workspace, you can not modify the objects that are inherited from the parent workspace there. That is by design. Those inherited objects are available in read-only mode. You can add new objects, create copies of the inherited objects and modify the copies, but not directly modify the inherited objects. Those can be only modified in the parent workspace itself and those changes will reflect in all the child workspaces.

@Michal Hauzírek @Yvonne Changamuka So in this case, if I have created a child workspace from a parent, I will not be able to modify the child workspace at all? My end goal is to use the parent workspace as a base template, and then build several child workspaces from it with additional, different, visualizations

You can for sure add objects to the child workspace and use the parent as a tenplate. That is the most typical use casem You just can not modify the objects in child that are inherited from a parent. So if in parent you uave dashboards A and B, they will be available in a child workspace. And you can add dashboards C and D to the child workspace. A and B will be read-only in the child workspace and C and D will be editable.

@Michal Hauzírek Thanks for the response! For the example you provided, I was hoping to be able to modify A and B in the child workspace, but it seems that's not possible. Is there a way to easily duplicate workspaces? I believe duplicating the parent workspace will help me achieve this goal since I would be able to modify A and B in the new parent workspace

Hi Christian, you should be able to modify A and B used in the example after applying the workspace permissions using the information we shared earlier in this thread. Regarding your question about duplicating workspaces, it is possible to clone workspaces via APIs. Please refer to our declarative API documentation section which explains how to do so in GoodData Cloud: https://www.gooddata.com/docs/cloud/create-workspaces/declarative-interface/#WorkspaceDeclarativeAPIInterface-CloneaWorkspace Let us know if this helps.

I see so I assume you do not want to use the objects from parent directly but really use them as an editable template? The downside of this approach could be a long term maintenance and manageability. If you let your end users somehow modify the core objects (those that are shared) you might face an issue if you later want to release new version of them - fix a bug in a metric or add new feature to the dashboard etc. If each object can be modified in child workspace, you would either overwrite the customizations with your release or your users would be stuck on whatever version they started with. Or you would need to somehow resolve conflicts for each object workspace by workspace. And the objects are used in cascade - dashboards use visualizations and visualizations use metrics (and metrics can use other metrics). So if everything can be modified, it can become quite complex to deploy a change to such system with many customized workspaces. With read-only inherited objects, there is clear distinction and separation between core and workspace-specific custom objects and deploying a change to the core is much easier. But it is possible to use separate workspace copies without hierarchy, if that is what you need. As Yvonne pointed out, you can use the declarative API to create a full disconnected copy of the workspace. Just note that without the hierarchy you might not be able to use the Workspace Data Filters that depend on the hierarchy. You can also combine the approaches - i.e. use the parent workspace just for logical model, metrics and some basic visualizations (those would be read only in childs) but without any dashboards and copy the dashboard definitions with API directly into the child workspaces. That way all the dashboards would be editable in childs and you would still have (read-only) core of model, metrics and visualizations that can be upgraded easily. To copy the dashboarda you can either use the declarative API for that or for individual dashboards also the entiry API - create individual dashboard + its filterContext.