Manage Organization Permissions

Organization permissions enable users to manage the GoodData deployment, including aspects like user management. The MANAGE organization permission gives users access to all actions and resources throughout the entire GoodData platform, making it crucial for administrators.

Supported Permissions

The following permissions are applicable to the organization object:

  • MANAGE

    Gives the user access to any protected action or resource. This permission should be reserved for administrators.

  • SELF_CREATE_TOKEN

    Gives the user the right to create their own API access tokens. Users without this permission can still delete any of their pre-existing API tokens. Note that to create API access tokens for other users, you still need the MANAGE permission.

Permissions limit who can create new tokens, but they do not block the utilization of pre-existing tokens, whether generated by an admin for the user (if applicable) or older tokens (e.g., if the user previously had the permission, which was subsequently revoked).

Set Permissions for an Organization

Permissions for an organization are set using the /api/v1/layout/organization declarative API endpoint. You need the Organization.MANAGE permission to change the organization layout.

Note that there always has to be at least one user with the MANAGE permission in an organization. API calls that would result in an organization having no users with the MANAGE permission are not valid.

Steps:

Follow these steps to update your organization permissions through an API call:

  1. Fetch the Current Organization Layout

    Execute the following API call to retrieve the current json definition of your organization layout:

    curl -H "Authorization: Bearer $API_TOKEN" \
        -H "Content-Type: application/json" \
        -X GET \
        $HOST_URL/api/v1/layout/organization
    
  2. Modify the Permissions in the JSON File

    In the returned organization layout json file, locate and update the permissions section as needed:

    {
      "organization": {
        ...,
        "permissions": [
            {
                "assignee": {
                    "id": "<user_id_or_user_group_id>",
                    "type": "<user_or_userGroup>"
                },
                "name": "MANAGE"
            }
        ]
      }
    }
    
  3. Update the Organization Layout

    Update the organization layout with your modified json file using the following API call:

    curl -H "Authorization: Bearer $API_TOKEN" \
      -H "Content-Type: application/json" \
      -X PUT \
      $HOST_URL/api/v1/layout/organization -d @<your_updated_organization_layout>.json
    

Permissions JSON Structure

  • Object

    The object (organization in the example above) contains the permissions definition, establishing the relationship between the object, its permissions, and the assignees.

  • Permissions Definition

    The type of permissions you want to assign to users. Keep it as permissions if you are assigning organization permissions, but in case of workspaces, you can also use the hierarchyPermissions definition. See the Manage Workspace Permissions section for details.

  • Assignee

    An assignee refers to either a user or a user group, identified by their id and specified by type within the permissions setup.

  • Name

    The permission name (e.g. MANAGE) within this structure dictates the level of access, mapping to specific actions that are otherwise restricted.

Example

In a practical deployment scenario, the permissions definition for an organization object might look like this:

{
    "organization": [
        {
        ...,            
        "permissions": [
            {
                "assignee": {
                    "id": "john_doe",
                    "type": "user"
                },
                "name": "MANAGE"
            },
        ],
        ...
        }
    ]
}

In this scenario, the user john_doe is promoted to organization admin.