For complex Synapse projects, administrators manage many folders with different sharing settings for different user groups. In this scenario, creating a permission model for the project is recommended. A permission model helps you group users together according to the level of access they require. These groups can then be managed as a whole, rather than as individual users.
When creating a permissions model for your project, 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 to modify user access?
Does any content in this project need different permissions than the whole project? For example:
Raw data vs. processed data folders shared with specific groups
Internal meeting notes in a private folder vs. methodology and SOP documents shared publicly
Using Teams for Permissions
Teams are groups of Synapse users; learn more about managing teams here. If you are working with many Synapse users on a project, and you want to allow some users to view or download data, and other users to add new data, you should consider using teams to manage your project permissions.
For example, you can create a “project administrators” team and grant that team permission to administer the project. Then 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 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 administers the project, a larger group who contributes data, and an even larger group who downloads the project contents. In these cases, we recommend creating groups for each of these permission types: an administrative team with “administer” permissions, a data curation or content creation team with “can edit” permissions, and a 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 has the permissions of the highest level granted. In other words, if you add a single user to three different teams, “administer”, “can edit”, and “download”, the user will have “administer” permissions.
Local Sharing Settings
Sometimes, users wish to create private spaces for certain groups within larger, public projects. This is possible using local sharing settings to restrict content to specific teams.
To create a private folder within a public project, 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 with then be shared only with the specific teams that the entire project is shared with, and not the general public. Removing local sharing settings on an item will assign default permissions from the parent folder or project.
Triaging Project Permissions Using Views
Creating local sharing settings for many folders, sub-folders, or other items in Synapse can become complex to manage. You or another administrator may alter local sharing settings accidentally, or you may want to audit your sharing settings periodically. One way to manage your project permissions is by creating a view with a scope set to a single project, or across multiple projects, with similar permissions models.
An important component to managing permissions is the benefactor ID, or benefactorId. This identifier is the unique set of permissions assigned to groups of items in Synapse. When you first create a project, the project itself is the “benefactor” of permissions, meaning all items within that project inherit the same permissions, and there is only one benefactor ID for everything in the project.
When you create local sharing settings on an item, there are now two benefactors; the project is still providing the permissions for most of the content, but wherever you set local sharing settings (for example, a folder) now is the benefactor for anything inside it. This folder is the new benefactor of permissions for its contents, and everything inside has the same, new benefactor ID.
The benefactor ID is useful because you can create a view of every item in the project and use it to review system metadata, including benefactor ID. This view will help you find items where local sharing settings are active, causing new benefactor IDs to appear. You can use the view to audit your permissions across the project and find, change, or remove local sharing settings.
You can use a SQL-like query to identify items that have different permissions than the parent project. The query compares the benefactor ID of each item to the project ID and displays any items where the two do not match. If the benefactor IDs are different, then the item has different sharing settings than the rest of project and might be something to check.
This example query looks for folders with a different benefactor IDs, as folders are the most common item to have different sharing settings. You can modify the query to look at at files, tables, or all content as well:
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 the Searching Tables and Views page.