Hello 👋 I think we have a bug to report. We have the following setup: 2 workspaces A and B, where A is the parent of B. There are dashboards in A. We have a user who has MANAGE permission to the workspace B. With that workspace permission, the user is actually able to list the dashboards that B inherits from A, however, the user is not able to view the dashboard. In other words, the request to

/api/v1/entities/workspaces/B/analyticalDashboards

returns the dashboards inherited from A, but the request to

/api/v1/entities/workspaces/{workspaceId}/analyticalDashboards/{dashboardId}

returns 404. Once you give the user the VIEW permission for the dashboard using the

/managePermissions

endpoint, the user can load the dashboard. However, the user can see the edit and share buttons, but in reality, the user cannot save changes or share the dashboard. We think the user shouldn’t be able to see the dashboards in the list, nor the edit or share buttons, when they don’t have the rights to do that.

Hi Tomáš, I’ve been unable to replicate this so far. Could you please specify the permission in workspace A assigned to the user who cannot load the dashboards in workspace B? Please also provide more details about your GoodData environment and hierarchies

Sure. This is the setup. Workspace A permissions:

{
  "hierarchyPermissions": [],
  "permissions": []
}

You have a dashboard X in A, with 0 permissions:

// GET /api/v1/actions/workspaces/A/analyticalDashboards/X/permissions
{
  "userGroups": [],
  "users": []
}

Workspace B (child of A) permissions:

{
  "hierarchyPermissions": [],
  "permissions": [
    {
      "assignee": {
        "id": "manage",
        "type": "userGroup"
      },
      "name": "MANAGE"
    }
  ]
}

The user is assigned to

manage

group. If you make a request, with the user’s token to

/api/v1/entities/workspaces/B/analyticalDashboards

, you get X in the response.

When creating a dashboard the users that can view, edit and share them include those with

Workspace.MANAGE

hierarchyPermission to the workspace where the dashboard is native to, or to its parent workspace (if the workspace is part of a workspace hierarchy). If you’re working with an old version of GoodData CN, it is recommend to updgrade it to avoid issues like this. I have reached out to you via DM to gather more details

We’re on the latest GoodData CN version a hierarchy workspace permissions are not the issue here.

@Tomáš Gajdoš I’ve gone over the example. I set up a child workspace and reproduced the behavior you’re describing. It is definitely a bug, as the user with workspace.MANAGE should be able to see and access all dashboards, including the inherited ones. Regarding the visible Edit buttons: This I cannot reproduce. Could you confirm for me whether it also happens in the native UI? From the video, you’ve got a custom UI going.

Thanks a lot, Jan! Yes, we are on 2.3.0. We’ll try the patch. I think in the native UI it correctly displays “save as new” button instead of the edit button, so it must use better heuristic than what the

selectCanEditDashboardPermission

selector offers. The native UI also shows the share button and

selectCanShareDashboardPermission

returns true, but trying to share results in an error. But I presume that would be fixed in the patch. I’ll report back once we upgrade. Thanks again!

👌 I will wait for your findings.

Hi! We’ve just updated the container, so I’ll take a look at it today again and let you know. Thanks!

User/userGroups with workspace.MANAGE see everything in the workspace by design, inherited or not. May I ask why you’re using that permission in particular? Perhaps a different combination of workspace and dashboard permissions could fulfill the same purpose without that downside. @Petr Dolejsi @Matyáš Kandl Could either of you comment about the

selectCanEditDashboardPermission

selector? I am not sure what the intended behaviour here is or if there’s a better way.

The use case is this: We have a parent workspace, where we built default dashboards for customers. Each costumer’s workspace is a child of this workspace. We wanted to be able to create different sets of these default dashboards and control which set or sets the customer can see based on group membership. Now, a Manage user in customer’s workspace always gets to see all sets of dashboards.

Have you considered controlling the visibility of these dashboards using the dashboard.SEE permission from the parent workspace?

yes, that’s what we’re doing, but it breaks for the Manage user. in essence, we would need a permission that’s somewhere between Analyze and Manage, because we need users that are allowed to edit Metrics (which Analyze user cannot, afaik)

Right, I understand. Let me get the feedback of our product team on that and get back to you.

🎉 New note created.

@Tomáš Gajdoš Regarding the selector, here’s what I got from our SDK team: I think you need to use combination of the selectors: 1/ selectCanEditDashboardPermission (to check for permissions) 2/ selectDashboardLockStatus (to check whether the dashboard is inherited) If selectDashboardLockStatus returns true, then the dashboards is locked === inherited.

Thanks Jan for all the info!