GET: See users' data access levels

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: Josephine DiMaggio is both a tester and a team member in a workspace.

Role	Data Access Restrictions
Tester	MediumClearance
Team member	LowClearance

If you 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 restriction is inactive for leaders.>
Team member	LowClearance

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

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

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, and Tester.

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

The workspace users are:

Andrew Wiggin

Workspace	Roles
Project1	Leader, Team Member
Project2	Team Member

Josephine DiMaggio

Workspace	Roles
Project1	Tester
Project2	Viewer, Tester, Team Member

Example: Get data access for users in Project1, ID=1002

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
}

Example: Get data access for users in Project2, ID = 2001

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
}