Manage Permissions

Permissions in GoodData play a critical role in managing access and actions within the platform. Understanding and correctly implementing these permissions ensures security and efficiency in your workflows. This guide provides an overview of the different types of permissions and their importance.

Why Use Permissions?

Permissions are a fundamental aspect of managing access in any organization, allowing control over who can view, edit, and share various resources like dashboards, data sources, and workspaces. They play a pivotal role in maintaining data integrity, safeguarding sensitive information, and ensuring that users have access only to the tools and data necessary for their roles.

The general approach involves assigning permissions to specific objects, such as a particular workspace or dashboard. Within our documentation, permission levels assigned to objects are denoted by the notation [Object].[PERMISSION_LEVEL]. An example of this would be Dashboard.VIEW.

A best practice is creating user groups, each with permissions tailored to their organizational function. This method streamlines managing access rights, especially in larger organizations with diverse roles and responsibilities.

For example, in a company, the finance team might have EDIT permissions for financial dashboards, while the marketing team can only VIEW them. This prevents unauthorized edits while allowing necessary access.

We offer different permissions for managing Dashboards, Workspaces, Data Sources, and the overall Organization. This targeted assignment of permissions prevents unauthorized edits and facilitates the appropriate level of access for different teams.

  • Dashboard Permissions

    Permissions for dashboards determine who can view, edit, or share them. For example, without setting these permissions, access to a newly created dashboard would be limited to the creator, users with Workspace.MANAGE or Organization.MANAGE permissions, and those with specific hierarchical permissions.

  • Data Source and Organization Permissions

    Permissions related to data sources and the organization are designed to oversee the entire GoodData deployment. These are crucial for administrators.

  • Workspace Permissions

    In workspaces, permissions are defined either as permissions for a specific workspace or as hierarchyPermissions affecting the workspace and its children. They range from VIEW, allowing users to see shared dashboards, to MANAGE, which includes creating and editing logical data models and unrestricted dashboard access.

Types of Permissions

Understanding permissions in GoodData is essential for effective data management. Permissions vary depending on the object type and determine the level of access and control a user has. The following is a simplified summary of the key permissions and their general functions. For more detailed information on each permission type and specific actions they allow, refer to the related articles under this section.

Permissions in GoodData fall into several categories:

  • VIEW
  • ANALYZE
  • EXPORT
  • USE
  • SHARE
  • EDIT
  • MANAGE

Permissions enable users to perform various actions, which vary according to the object they’re associated with. Each object type, such as Dashboards or Workspaces, supports a distinct set of assignable permissions.

Permissions by Object Type

Dashboards

  • VIEW: View and interact with dashboards.
  • SHARE: Share dashboards with others, up to the View & Share level.
  • EDIT: Edit or delete dashboards and share up to the Edit & Share level.

Data Sources

  • USE: Allows listing of data source identifiers.
  • MANAGE: Enables altering of the data source, including its schema and connection credentials.

Organization Object

  • MANAGE: Grants access to all actions and resources across GoodData, ideal for administrators.
  • SELF_CREATE_TOKEN: Permits creation of personal API access tokens. Note: Deleting pre-existing tokens is possible without this permission.

Workspace Object

  • VIEW: Users can view shared dashboards.
  • ANALYZE & EXPORT: In addition to viewing, these permissions allow for creating, editing, and deleting dashboards and visualizations. ANALYZE includes LDM and metrics viewing, while EXPORT enables exporting dashboards and data.
    • EXPORT_PDF: Limited to viewing and exporting dashboards to PDF.
    • EXPORT_TABULAR: Restricted to viewing and exporting data to XLSX and CSV files.
  • MANAGE: A comprehensive permission covering VIEW, ANALYZE, and EXPORT. It includes editing the logical data model, metrics, and unrestricted dashboard access.

Permissions Hierarchy

Permissions are structured hierarchically, meaning that each higher permission level encompasses all the rights of the lower levels, with additional capabilities. For instance, having the MANAGE permission includes all the functionalities of the ANALYZE permission, plus more.

adminUser

By default, the individual who establishes the company account is assigned the adminUser status. This role comes with the highest level of permissions, granting the adminUser complete access to view and modify all GoodData projects without the need for additional permissions. Other users can be elevated to this admin status through user management functionalities.

Non-admin Users

To make your project accessible to other users, we recommend you group users into user groups and assign permissions to these groups that are appropriate for those users’ use cases.

The overall concept is based on a rule that an action controlled by a permission is granted to a user or user group with the required or greater permission only.

Permissions obey an object hierarchy. If a user is assigned a permission inside an object, the user will also get the same level of access to objects that are lower in the object hierarchy.

The object hierarchy for permissions is as follows:

Object Hierarchy

For example, suppose a user has the MANAGE permission in the organization. In that case, the user also has MANAGE permission in all dataSources and workspace objects nested under the organization, even if the user does not have the MANAGE permission explicitly defined in each nested object.

Permission-based Filtering

Entities such as dashboards and data sources are protected from unauthorized access through permission-based filtering. When these entities are listed, any that the user does not have at least read-level permission for are automatically omitted from the list. Users holding the highest MANAGE permission level can access all entities, ensuring they can access everything regardless of specific permissions.

Permissions and Includes

GoodData’s access control is primarily based on permissions, but it also incorporates a feature known as ‘includes’ for accessing interconnected data. Here’s how they work together:

Access to specific entities in GoodData relies fundamentally on user permissions. If a user lacks the necessary permission for an entity, they are unable to complete operations related to that entity.

For instance, if a user doesn’t have permission to access a particular workspace, they can’t read its details, modify it, or perform any related tasks.

Bridging Data

Sometimes, an entity might need to reference data from another entity, which the user may not have direct access to. In these scenarios, sideloads come into play.

How Sideloads Work

Sideloads allow for the return of all referenced entities, regardless of the user’s permission to read these included entities. It’s important to note that while these included entities can be read through sideloads, they cannot be modified. This inclusion mechanism is designed for flexibility and might evolve in future updates.

Restriction on Defining Relations

Users cannot create new relationships or modify existing ones to point to entities they don’t have access to. The list of includes typically comprises entities the user has or had access to or those needed by the application logic, like a parent-child workspace relationship.

Example of Includes

Consider the scenario of listing workspaces. If a user doesn’t have access to a parent workspace, they can’t access its details directly. However, when accessing a child workspace through the entities API with ‘include parents’ enabled, the user can see information like the parent workspace’s title and description. This access is as though they had read permissions for the parent workspace entity.

Organization