Creating Permissions Models for Synapse Projects

Synapse supports several different kinds of project permissions. These are described in more detail as “sharing settings” in the article on access controls. Additionally, Synapse supports setting “local sharing settings” that allow you to make your project public while keeping some folders, files, or tables private. To do this, you would use local sharing settings. Permissions and sharing settings within Synapse are otherwise hierarchical; that is, if you set permissions on a project, everything within that project inherits those permissions until local sharing settings have been created.

...

For complex Synapse projects, administrators manage a wide variety of data that requires different permissions for different user groups. In this scenario, creating a system for managing data access with Synapse teams is recommended. This method allows you to group users together according to the level of access they require and then assign permissions to the entire team rather than to many individuals.

When creating teams to manage data access, consider the following questions:

• Who needs to be able to view this project?

• Who needs to be able to edit or add content to this project?

• Who should be in charge of changing permissions on this project, to modify either of the aboveuser access?

• Does any content in this project need different permissions than the whole project? For example:

  • Raw data vs. processed data folders shared with different permissionsspecific groups

  • Internal meeting notes in a private folder vs. methodolodgy methodology and SOP documents shared publicly

Using Teams for Permissions

Teams are groups of Synapse users; learn more about managing teams here/wiki/spaces/DOCS/pages/1985446029. If you are working with a group of usersmany Synapse users on a project, and you want to allow some users to view or download data, while and other users should be in charge of managing the project or adding to add new data, you should consider using teams to grant users permission. manage your project permissions.

For example, you can create a “project administrators” group team and grant that team permission to administer the project. Then , when you need to modify permissions on the project, you can add or remove people from the team rather than modifying the sharing settings on the entire project to grant each individual administrative permissions.

This approach is especially useful if you have more than one project that the same group of people will be working across; using on. Using teams for permissions can also help prevent administrative errors like forgetting to remove someone from a project if they leave your collaboration.

Recommended Team Types

For many collaborations, there is a small group who will administer of users administers the project, a slightly larger group who will contribute contributes data or content, and an even larger group who may have permission to view the project or contentsdownloads that data for their independent research. In these cases, we recommend creating groups for each of these permission types: an admin administrative team with “administer” permissions, a data curation or content creation team with “can edit” permissions, and a viewing downloading team with “can view/download” permissions. If you intend to make your content publicly viewable, this third team is not necessary; you can click on “Make Public” to share your project more broadly.

Because permissions are additive, a user who is in all three teams will have has the permissions of the highest permissions granted; that islevel granted. In other words, if you add a single user to three different teams and grant those teams “admin”, “edit”, “administer”, “can edit”, and “view” permissions“download”, the user in question will have “admin” user will have “administer” permissions. If you remove that user from the “administer” team, they will have “can edit” permissions.

Local Sharing Settings

Sometimes, users wish to retain create private spaces for certain groups within larger, public projects, or otherwise create sharing settings on project components (folders, tables, etc. ) that are different from the overall project permissions. This is possible using Local Sharing Settings. You can use teams for group permissions even with local sharing settings , which can help streamline administration even more.For example, to to restrict content to specific teams.

To create a private folder within a public project, you would make the entire project public using the “Make Public” button. Then, create a new folder, click on “Create Local Sharing Settings”, and click the “Make Private” button. Confirm that this removes the “All registered Synapse users - Can Download” and “Anyone on the web - Can View” from the list.The folder with click the Project Settings button, then select Project Sharing Settings. Add specific team names that should have access to all project content. Next, click Make Public and select the appropriate access levels for all registered users and anyone on the web.

Next, navigate to the new Folder, and click on Folder Tools. Select Folder Sharing Settings, then click Create Local Sharing Settings. Click on the Make Private button and confirm that fields for All registered Synapse users and Anyone on the web have been removed. Save your changes.

The folder can then be shared only with the specific user groups teams that the entire project is shared with, and not the general public. Note that creating Removing local sharing settings can sometimes alter the permissions model unintentionally; see below for how to triage your sharing settings.

Triaging Project Permissions Using Views

Sometimes local sharing settings are accidentally created, and once created, they can be somewhat tricky to detect. One quick way to triage your project permissions is by using a view with a scope set to a single project, or across multiple projects with similar permissions models. The field that you will be using below is called “benefactorId” – this is the unique set of permissions assigned to groups of thingson an item will assign default permissions from the parent folder or project.

Triaging Sharing Settings with Views

Creating local sharing settings for many folders, sub-folders, or other items in Synapse can become complex to manage as a project grows. You or another administrator may alter local sharing settings unintentionally, or you may want to audit your sharing settings periodically. One way to manage these settings is by /wiki/spaces/DOCS/pages/2011070739 to see sharing settings at a glance.

An important component to managing sharing settings is the benefactor ID, or benefactorId. This identifier is the name of the parent folder or project that sharing settings are inherited from. When you first create a project, the project itself is the “benefactor” of permissionsfor sharing settings, meaning all items within that project inherit the same settings, and there is only one benefactor ID for all the things everything in the project.

As soon as When you create your first set of local sharing settings , there are now two benefactors; the on an item, a second benefactor ID is created. The project is still providing the permissions for most sharing settings for the rest of the content, but whatever wherever you have set local sharing settings on (saya folder, a this folder ) is now is the benefactor for anything inside it; it’s the new benefactor of permissions for that sub-hierarchy, and everything inside will share the same, new benefactorId.This is useful as a query because you can set up a file/folder “view” of your entire project and look at all of the system metadata, including benefactor ID, and use it as a permissions audit. It will help you find places .

The benefactor ID is useful because you can include it in a view of every item in the project and use it to review all permissions at once. This view will help you find items where local sharing settings are set (active, causing new benefactor IDs to appear) and can help you clean them up, as views automatically update to re-query across your project each time the data changes (this can take a few moments if the update is quite large, so it is not precisely real-time, but it is automatic). You can find and remove local sharing settings entirely, which will cause permissions to then be inherited “up the chain”, so to speak.The query that will help identify things . In the example below, the folder name, benefactor ID, and the project ID for three folders are shown in a view.

...

All of the folders in this view belong to the same project, Demo_Project, and their corresponding project IDs in the third column are the same. In the second column, Folder 1 and Folder 3 are both inheriting their sharing settings from the parent project, Demo_Project. However, Folder 2 has local sharing settings applied that are different from the parent project, and the benefactor ID has changed.

For views with hundreds or thousands of rows, you can also use a SQL-like query to identify items that have different permissions than the parent project. The query below compares the benefactor ID of each thing item to the project ID . If they are different, this means that object has different sharing settings than that of the project, and might be something you want to check. This example query focuses on folders, as that is the most common thing that have different sharing settings. The query can be modified to look and displays any items where the two do not match. You can modify the query to look at at files, tables, or all content as wellin your view:

SELECT id,parentId,type FROM syn12162270 WHERE type = 'folder' AND  benefactorId <> projectId

...

For more information on how to use SQL-like queries in Synapse, see /wiki/spaces/DOCS/pages/2667642897.