Introduction
Flywheel roles and permissions give you granular control over what data users have permission to view and edit.
This article explains:
-
An overview of the roles and permissions structure in Flywheel.
-
The how to edit a user's Site, Group, or Project role
-
What actions a user can take with each role
See our article to learn how to create your own custom role.
Flywheel users can see, edit, or delete data based on their roles and permissions.
-
Permission: Enables or disables the ability to perform a specific action in Flywheel. For example, adding notes to a Project is a specific permission.
-
Role: A group of permissions that are assigned to a user. For some roles you can edit the permissions.
There are three (3) levels of the hierarchy in Flywheel that can be assigned a role at the Site, Group, and Project level where all users have a role assigned at each of these levels:
-
Site Role: These roles are broad and assigned when you create a new user. In general, these roles match what the user is doing in Flywheel at a high level. Site roles are Site Admin, Developer, and User. Pair these basic site roles with the more granular roles assigned at the Group and Project level.
-
Group Role: Group roles give users broad permissions for what they can do within a Group. For example, do you want users to be able to add other users to the Group? Should the user be limited to just viewing information about the Group? Group roles are Admin, read-write, and read.
Note: Assigning a Group role does not automatically add users to Projects in that Group.
-
Project Role: By default, Projects have Admin, read-write, and read-only permissions. However, Site Admins can create customized project roles for each project. Custom project roles give you the flexibility to only give users access to the data they need. included with the default Project role. Go to our other article to learn how to create custom roles.
Note: If you only want a user to see certain projects under a Group, you can assign the user a role in the Project without giving the user a Group role. To give the user access to a Project, but not the Group associated with the Project, add them from the Permissions screen of the Project.
One must be a Site Admin to assign site roles to users. When you create a user, the site role can be assigned and site roles can be edited. To learn how to edit, see below:
-
Go to Users > choose a user
-
Select the Information tab
-
Next to Role, select a role from the dropdown.
The Site Admin has the highest site-level permissions. Site Admins can create new Users and Groups, and modify user roles and permissions site-wide. You can think of this as a superuser role.
Developers have site-wide permission to upload gears, and restrict their availability to specific projects or users. Admins must assign Developers permissions to Groups and Projects to be able to see data.
These permissions apply to Flywheel Groups. By default, Group permissions also apply to Projects within that Group (you can configure this setting so projects do not automatically inherit Group permissions).
Note: Assigning a Group role does not automatically add users to Projects in that Group.
To give a user permission to a Group:
-
Go to Users > choose a user
-
Select the Permissions tab, and click Add
-
From the dropdown menu, select a Group and select either Admin, Read-Write, Read.
Below is some highlights for what each role can do in Flywheel. See the table below for more information on the permissions included with these roles.
Admin:
-
Manage Group Permissions
-
Create New Project
-
Delete Project
-
Add Users to Group
- Manage Project Settings
- Copy Projects
Read-Write:
-
Manage Group Permissions
-
Delete Projects
Read:
-
View Projects
Project roles allow one to control who can view, edit, and delete data within their Project. They must be an Admin for the Project or a Site Admin to edit Project Roles.
Note: If you only want a user to see certain projects under a Group, you can assign the user a role in the Project without giving the user a Group role. To give the user access to a Project, but not the Group associated with the Project, add them from the Permissions screen of the Project.
Custom roles: One can also create custom roles
To give users permissions to a Project:
-
Navigate to the Project
-
Select the Permissions tab.
-
From the dropdown menu, select user.
Select a permission level for the user. See the table below for more information on the permissions.
Tip - Create a project template to standardize roles and permissions
Project templates allow Site Admins to manage the project's default roles and permissions when creating a new project. See our article to learn more about how to create project template.
Table 1. Compare Project Roles and Permissions
Permission |
Read-only |
Read-Write |
Admin |
Required |
---|---|---|---|---|
Container Hierarchy (Subject/Session/Acquisition) |
||||
View Metadata View metadata on projects, subjects, sessions, and acquisitions |
x |
x |
x |
x |
Create Hierarchy Create new Subjects, Sessions, and Acquisitions Required when containers are added to the Project via moving or importing. This does not give user ability to create a Project or copy subjects, sessions, or acquisitions into another project. |
x |
x |
||
Modify Metadata Includes Project metadata |
x |
x |
||
Delete, including Files This includes: Files attached to the deleted container and its children Moving Subjects, Sessions, Acquisitions from a project There are special considerations for deleting Device data. See the considerations below for more detail. |
x |
x |
||
Delete Project |
x |
|||
Copy Project |
x |
|||
Analyses |
||||
View Metadata |
x |
x |
x |
|
Create via SDK “Ad-hoc Analyses” includes the ability to upload files to an Analysis |
x |
x |
||
Create via Job Creates an Analyses via Job/Gear |
x |
x |
||
Modify Metadata |
x |
x |
||
Delete Analyses Includes Files |
x |
x |
||
Files |
||||
View Metadata |
x |
x |
x |
x |
View File Contents |
x |
x |
x |
|
Download File |
x |
x |
x |
|
Create/Upload files |
x |
x |
||
Modify Metadata |
x |
x |
||
Move Files |
x |
x |
||
Delete, Non-Device Data For example, files that originated from running a gear. . |
x |
x |
||
Delete Device Data For example, deleting images uploaded directly from an MR scanner. |
x |
x |
||
Tags |
||||
View Tags |
x |
x |
x |
x |
Create, modify, and delete Tags |
x |
x |
||
Notes |
||||
View Notes |
x |
x |
x |
x |
Create, modify, and delete Notes |
x |
x |
||
Project Permissions |
||||
View Project permissions |
x |
x |
x |
x |
Manage Permissions and Services Create, modify, and delete Project permissions |
x |
x |
||
Project Settings |
||||
View Project Settings |
x |
x |
x |
x |
Manage Project Settings |
|
|
x |
|
Data views |
||||
View Data View and results |
x |
x |
x |
x |
Create, Modify, and Delete Data Views |
x |
x |
||
Session Templates |
||||
View Session Templates and results |
x |
x |
x |
x |
Create, modify, and delete Session Templates |
x |
x |
||
Gear rules |
||||
View Gear Rules |
x |
x |
x |
x |
Manage Gear Rules Create, modify, and delete gear rules |
x |
|||
Jobs- Gear runs |
||||
View jobs Includes job metadata, configuration, and logs |
x |
x |
x |
x |
Run and cancel jobs Applies only to utility jobs |
x |
x |
||
Cancel any Job Includes other users and system jobs |
x |
|||
Reader Task Admin |
||||
View reader task Create/View All/Modify/Delete Reader Tasks |
x |
|||
Annotations |
||||
View Annotations |
x |
x |
x |
x |
View Other Annotations View other users' annotations |
|
|
x |
|
Edit Other Annotations Modify/Delete other user's annotations |
|
|
x |
|
Form |
||||
View Form Create/Modify/Delete Forms |
|
|
x |
|
View Own Form Create/View/Modify/Delete form responses |
|
x |
x |
|
View Others Form View Other Users' form responses |
|
|
x |
|
Edit Others Form Modify/Delete other users' form responses |
|
|
x |
|
Data Transfer |
||||
Manage Imports Data import storage and operations |
|
|
x |
|
Manage Exports Data export storage and operations |
|
|
x |
|