Hello! I have a parent workspace with full access on db and with a WDF defined (the parent workspace itself is not being filtered by it) I have several child workspaces inherit from the parent, where I have set data filters. 1. Based on the above settings, is it possible to delete the data filters of a specific child workspace, and this child to have full access on the db as the parent? 2. When I render the dashboard components of a child workspace, I see that there are some actions in each dashboard (Share as new, share and export). How can I set this to be only the export available? These are the permissions of the child workspace:

GET /api/v1/layout/workspaces/workspace-id/permissions
{
    "hierarchyPermissions": [
        {
            "assignee": {
                "id": "user-id",
                "type": "user"
            },
            "name": "MANAGE"
        }
    ],
    "permissions": [
        {
            "assignee": {
                "id": "user-id",
                "type": "user"
            },
            "name": "MANAGE"
        }
    ]
}

Hi Danai, 1. I do not think this is currently possible. The WDF is inherited via the hierarchy and if there is inherited WDF but there is no corresponding WDF Setting (value) no data should be shown for security reasons (to avoid leaking of all data in case someone forgot or removed the WDF Setting. But if this is what you want, I think you might set slightly different hierarchy to allow this: • “very parent” workspace (with just the structure but no WDF) ◦ parent workspace for workspaces with WDFs (where the WDF is defined, no other changes, “very parent” is its parent) ▪︎ client1 workspace (with WDF setting and WDF applied) ▪︎ client2 workspace (with WDF setting and WDF applied) ▪︎ … ◦ parent workspace for workspaces without WDF ▪︎ clientX workspace ▪︎ clientY workspace (or maybe you can even make the “very parent” workspace be the parent to your unfiltered client workspaces directly). EDIT: But actually, since the WDFs also has to be marked in the Logical Data Model (which is also inherited), I think for this to work you would need to modify the Logical Data Model of the “parent workspace for workspaces with WDFs” via API by referencing the WDFs there. To do so, you would need to use the

datasetExtensions

part in the setLogicalModel API call: https://www.gooddata.com/docs/cloud/api-and-sdk/api/api_reference_all/#operation/setLogicalModel The datasetExtensions allows you to append a WDF to the existing (inherited) dataset which did not have it.

Hi Michal, thank you! 1. Do I always need to have a parent workspace? Is it possible to have: ▪︎ parent workspace for workspaces with WDFs (where the WDF is defined, no other changes • client1 workspace (with WDF setting and WDF applied) • client2 workspace (with WDF setting and WDF applied) • … ▪︎ workspace for workspaces without WDF 2. If I set the permission EXPORT using the endpoint

api/v1/layout/workspaces/workspace-id/permissions

and body

{
  "hierarchyPermissions": [
    {
      "assignee": {
        "id": "89a323aa-ca56-4d98-bb89-85d0f3b1b8a3",
        "type": "user"
      },
      "name": "EXPORT"
    }
  ],
  "permissions": [
    {
      "assignee": {
        "id": "89a323aa-ca56-4d98-bb89-85d0f3b1b8a3",
        "type": "user"
      },
      "name": "EXPORT"
    }
  ]
}

when rendering the dashboard components i get the error

AN UNEXPECTED ERROR HAS OCCURRED

What am I doing wrong here?

1. You do not need to have always parent. Not having a parent will make these workspaces independent - they will not inherit any data model or metric/dashboard definitions. So you will need to put the model/metrics/dashboards there (probably using the layout API) and if you introduce some changes to the parent workspace and want to keep it in sync with the other ones, you will need to propagate those changes there as well. But since the whole workspace definition is serializable with the layout API, it should be possible. 2. I am not sure what is wrong there. Do you happen to have some error_id or request_id? (they might be visible in the browser console. But if I would have to guess, I would think it might be one of these: • I am not sure if setting both

hierarchyPermissions

and

permissions

for the same user is all-right • If the user no longer has

Workspace.MANAGE

permission, it can happen they do not have access to that specific dashboard. By default users with lower permissions than Workspace.MANAGE can only see dashboard explicitly shared with them or dashboards shared with all workspace users. See the dashboard permissions. (I would expect better error message in such case).

thank you Michal. For 2, the error in the console i get is :

{
  "detail": "The requested endpoint does not exist or you do not have permission to access it.",
  "status": 404,
  "title": "Not Found",
  "traceId": "a2728674951812e2c89f46713d43c951"
}

Thank you, Danai. In the internal logs, I can see a bit more info under this traceId: >

source: EVALUATION, objectExist: true
> Operation is not granted dashboard: aac431ab-421e-477b-a8fc-caba9d05100a

So I believe this is really the case with user not having permission to the specific dashboard anymore after removing the workspace.MANAGE permission.

Thank you, Michal. The issue is fixed with the appropriate permissions!