GET: See users' data access levels (Enterprise Edition)

The GET operation can be used to see if users have data access restrictions, and what the restrictions are.

Overview

After setting up data access control for the shared space, you can use the REST API to see which workspace users have data access restrictions and what the restrictions are.

Data access restrictions are role-based.

Listing data access restrictions for users with multiple roles

If a user has multiple roles, the REST API shows the union of all the user's restrictions.

Example: Let's look at Josephine DiMaggio, who is both a tester and a team member in a workspace: 

Role Data Access Restrictions
Tester MediumClearance
Team member LowClearance

If we GET Josephine's data access, both MediumClearance and LowClearance are returned.

If a user has multiple roles and one of these roles does not have any data access restrictions, the REST API shows that the user does not have any data access restrictions.

Example: Let's look at Andrew Wiggins, who is both a leader and a team member in a workspace. Leaders do not have any data access restrictions. Team members do. Since Andrew is a leader in this workspace, he is unrestricted.

Role Data Access Restrictions
Leader <Data access is disabled for leaders.>
Team member LowClearance

If we GET Andrew's data access, no restrictions are returned.

Back to top

URI

Use the following URI to GET data access restrictions: 

GET .../api/shared_spaces/<space_id>/workspaces/<workspace_id>/workspace_users?fields=data_access,data_access_enabled,name,first_name,last_name

Back to top

Examples

The following examples are based on this information:

  • There are two workspaces: Project1 (ID 1002) and Project2 (ID 2001).

  • Three data access levels are defined: Regular (ID 1002), Contractor (ID 1003), Guest (ID 1001)

  • One role does not have any data access restrictions: Leader.

    There are three roles with data access restrictions: Viewer, Team member, Tester:

    Role Data Access
    Viewer Guest (ID 1001)
    Team member Regular (ID 1002)
    Tester Contractor (ID 1003)
    Leader <No restrictions>

  • The workspace users are: 

    Workspace User Workspace Roles
    Andrew Wiggin Project1 Leader
    Team Member
    Project2 Team Member
    Josephine DiMaggio Project1 Tester
    Project2 Viewer

    Tester
    Team Member

The GET list all workspace users and specifies the relevant fields.

Let's look at the response: 

  • Data access is enabled for Josephine, and her data visibility is 1003, which corresponds to Tester.

  • However, data access is not enabled for Andrew. He has no restrictions on data access even though one of his roles in Project1 is Team Member, which has Regular data access. This is because he is also a Leader, which has no restrictions. This role overrides any other restrictions he obtains from other roles.

*** Request ***

GET .../api/shared_spaces/<space_id>/workspaces/2001/workspace_users?fields=data_access,data_access_enabled,name,first_name,last_name 

*** Response ***
{
    "total_count": 2,
    "data": [
        {
            "type": "workspace_user",
            "data_access_enabled": false,
            "name": "andrew.wiggin@softwarecompany.com",
            "last_name": "Wiggin",
            "id": "2001",
            "first_name": "Andrew"
        },
        {
            "type": "workspace_user",
            "data_access_enabled": true,
            "name": "josephine.dimaggio@softwarecompany.com",
            "last_name": "DiMaggio",
            "id": "2002",
            "data_access": {
                "total_count": 1,
                "data": [
                    {
                        "type": "data_visibility",
                        "id": "1003"
                    }
                ]
            },
            "first_name": "Josephine"
        }
    ],
    "exceeds_total_count": false
}

Back to top

We use the same GET as the previous example, but we just change the workspace ID number.

Let's look at the response: 

  • Data access is enabled for Josephine. She has three roles and therefore three data access restrictions. They are all listed.

  • Data access is now enabled for Andrew because he is not a Leader in this workspace. He has the data visibility of the Team Member role (1002).

*** Request ***

GET .../api/shared_spaces/<space_id>/workspaces/2001/workspace_users?fields=data_access,data_access_enabled,name,first_name,last_name 

*** Response ***
{
    "total_count": 2,
    "data": [
        {
            "type": "workspace_user",
            "data_access_enabled": true,
            "name": "andrew.wiggin@softwarecompany.com",
            "last_name": "Wiggin",
            "id": "2001",
            "data_access": {
                "total_count": 1,
                "data": [
                    {
                        "type": "data_visibility",
                        "id": "1002"
                    }
                ]
            },
            "first_name": "Andrew"
        },
        {
            "type": "workspace_user",
            "data_access_enabled": true,
            "name": "josephine.dimaggio@softwarecompany.com",
            "last_name": "DiMaggio",
            "id": "2002",
            "data_access": {
                "total_count": 3,
                "data": [
                    {
                        "type": "data_visibility",
                        "id": "1001"
                    },
                    {
                        "type": "data_visibility",
                        "id": "1002"
                    },
                    {
                        "type": "data_visibility",
                        "id": "1003"
                    }
                ]
            },
            "first_name": "Josephine"
        }
    ],
    "exceeds_total_count": false
}

Back to top

See also: