Permissions

There are four object types in Flow for which access is limited based on who the user is - data, executions, samples and projects.

Flow defines four levels of access:

• Read access: the ability to see that an object exists and access its attributes and other data.
• Edit access: read access, plus the ability to modify the object.
• Share access: edit access, plus the ability to share the object with others.
• Ownership access: full access - share access, plus the ability to do things like delete the object.

Private and Public

Data, executions, samples and projects all have a private attribute which, when false, means that the object is public.

If an object is public, it means that everyone has read access to it - every user on Flow, and every logged out user too. There are no restrictions on read access at all (though editing/sharing is still restricted in the normal way).

These public objects comprise the public dataset of Flow, and as such certain limits are placed on what samples can be made public - they must have certain metadata attributes filled in.

Ownership

Each of these objects has either a user owner, or a group owner. Objects can be transferred to a different owner if required.

A user owner has full rights on the object, and unless the object is made public (see above) or shared with anyone else (see below), they will be the only one with those rights. They can access, edit, share, and delete the object with no restrictions.

If there is a group owner, every member of that group will have ownership rights on the object - except for deletion and ownership transfer, for which you must be a group admin.

Specific Sharing

In addition to the object owner, other users and groups can be given access by creating links. There are user links and group links for each of the four object types referred to above, which confer a specific right. For example, these are the attributes for data-user links:

The other seven link object types work in exactly the same way.

For example, creating a data-user-link with permission 2 will grant edit access on a data object to a specific user. Creating a sample-group-link with permission 3 will grant share access to a sample to everyone in a specific group.

Permission Inheritance

The four object types discusses here form a hierarchy - data objects can belong to the execution which produced them, which can be associated with a particular sample (or project), which can be part of a project. In general, permissions flow down this hierarchy - any permission on a project will also apply to its samples etc.

The exception here is the way executions inherit permissions from the sample/project it is part of. Executions have a dependent field which determines whether they inherit permissions - if true they do, if false they don't. Because executions can be made part of samples and projects automatically based on inputs - inputs whose sample/project the user may not even be thinking of, the default behaviour is for this to be false if the inout data belongs to someone else, true if it is the user's own data.

The full list of permission flows is as follows:

Data inherits permissions from:

• The execution that produced it (and anything it inherits permissions from).
• The sample it initialised (and anything it inherits permissions from).
• The sample that the process execution that produced it is associated with (and anything it inherits permissions from).
• The project the data is directly associated with.

Executions inherit permissions, when 'dependent', from:

• The sample it is associated with (and anything it inherits permissions from).
• The project it is associated with.

Samples inherit permissions only from the project they are in.