Upgraded SciNote permission system for Projects

Magenta line5 min read

SciNote has upgraded the permission system for projects, which controls how SciNote users access projects, as well as the experiments, and tasks inside projects.

Don’t worry the upgrade was designed in a way that allows you to continue to use SciNote in an identical way as before. The majority of the upgrade is the first step that will allow SciNote to roll out additional flexibility and improvements in the future.

You can keep on using SciNote as you were used to, however, this upgrade is already bringing in some additional flexibility, which you can optionally take advantage of.

The upgraded permission system also meant that we had to introduce a few minor changes to the user interface.

Let’s review what those flexibilities and related improvements are.

Improved managing of project members

We’ve made managing access for project members simpler.

The redesigned “Manage access for projects” window now has a cleaner look:

Manage Project members

Granting new access to a project is now much easier:

  • Adding access to new users for a project was moved to a dedicated window, that can be accessed via “Grand new access to project”.
  • Now you can search for users to whom you would like to grant access to.
  • You can select more than one user to grant access to.
  • You can select for each individual user a user role and then grant access with a click of one button.

You can still change the role for existing project members in the same manner as before, via “Change project role”. There you will see the same default SciNote project roles as before. The roles have identical permissions as before, despite the fact that the permission system in the back was upgraded. Therefore you will have identical experience as before in what you and your coworkers can or cannot edit on projects, experiments, and tasks.

It is now possible to manage access inside projects

We added the ability to change access to users also for experiments and tasks inside projects. With this, you will be able to control the access more precisely.

For this purpose, we introduced “Manage access for experiments” and “Manage access for tasks” on experiments and tasks, respectively. They are both very similar and are based on “Manage access for projects”.

Manage access for experiments

You can access Manage access for experiments from the experiment’s card and in the table view.

Experiment access

The Manage access for experiments looks familiar to Manage access for projects. There are a few differences though:

  • You can manage access only for users that are members of the project; this approach was kept from the previous permission system, where access to a project was required in order to have access to experiments and tasks inside.
  • Following the same concept, it is not possible to remove access for a user on the experiment.
  • Essentially, on experiments, you can “only” change the role for a user via “Change experiment role”, where you can select any other role.

“Manage access for experiment” lists all project members and their roles. Why is this so? The access the user gets on a project is inherited to all experiments and tasks inside that project. This is identical to behavior from the old permission system, however, now that we are displaying the access for experiments it became even more visible.

When you change a role for a specific user on a specific experiment, you replace the role the user inherited from the parent project. You will also notice that this new role will be propagated to all the tasks inside the experiment (so inheritance works in the same way on projects and experiments).

Manage access for tasks

You can access Manage access for tasks from the task card in the canvas and from the task screen Details / Info section.

Task management access

You will see that the Manage access for tasks looks familiar as it is practically identical to manage access for experiments:

  • You can manage access only for users that are members of the project; this approach was kept from the previous permission system, where access to a project was required in order to have access to experiments and tasks inside.
  • Following the same concept, it is not possible to remove access for a user on the task.
  • Essentially, on tasks, you can “only” change the role for a user via “Change task role”, where you can select any other role.

“Manage access for task” lists all project members and their roles for the same reasons described above for experiments.

When you change a role for a specific user on a specific task, you replace the role the user inherited from the parent project or experiment. You can also change user roles for locked tasks (this was also possible in the old permission system but was probably less obvious: you could change user roles or remove access for users on projects that contained locked tasks).

Minor improvements that were necessary due to the upgrade of the permission system

With the upgrade of the permission system, we had to make some minor changes presented below.

Easier moving of experiments between projects

We simplified moving experiments between projects and made it compatible with new permission system. To move the experiment to a different project (destination project), these conditions must be met:

  • On origin: user who is moving an experiment should have edit permissions for that entire experiment including edit permissions for all tasks inside the experiment.
  • On destination: user who is moving experiment should have edit permissions in the destination project.
  • There is no more the condition that the destination Project needs to have the same or matched users.

In the destination project, the access to the moved experiment (and all its tasks) is simply inherited from the project. No access (no users and their roles) is moved along with the experiment’s content.

Changes to “All team members” project visibility 

Up to now, projects had an additional visibility control setting: projects could be set to be visible to “Project members only” or to “All team members”. The setting was accessible when creating new projects or editing existing ones. The “All team members” option granted view access to the project and its content to all current and future team members without them being listed in the Manage project access.

With an upgraded permission system we are no longer allowing access to projects, experiments, and tasks without that access being granted and listed via “Manage access for projects”. We introduced the following modifications, that essentially keep the functionality in place:

  • The “Visible to” section was replaced with “Make this project visible to all team members” setting, which is analogous to the old “All team members” setting.
  • When this setting is enabled, a role can be selected for all team members; This is new flexibility – before the view access was granted by default, now you have the flexibility to choose the appropriate role.
  • After this setting is applied, all current (and all future team members) are granted access with the selected role to the project and are listed in the Manage access for projects window. As some teams can have quite a lot of users, projects with this setting will end up having long lists of users in Manage access for projects window. We are going to simplify this view in one of the upcoming releases and group such users together.
  • In case a user already had specific access to the project before “Make this project visible to all team members” setting was enabled, the specific access takes over. The same is true if the specific access is added to a user after “Make this project visible to all team members” setting was enabled.

Difference between “Assigned users to tasks” and task access

There is no difference in behavior when it comes to “Assigned users to tasks”. But it is important to understand the difference between “Assigned users to tasks” (an existing functionality) and task access (added with permission upgrade).

To help distinguish the difference between the two we renamed „Assigned users to tasks“ to „Assigned to“. With this change, we are stressing that tasks (that represent pieces of work) are assigned to users and not the other way around.

For the same reason, we redesigned the appearance of users to which the task is assigned. Now they resemble tags. From now on the task can be assigned to the users only directly from the task screen, in much the same way the tags can (and no longer from the task cards on the canvas).

To summarize the main difference:

  • The fact that a task is assigned to one or more users means that these users are contributing to the content of the task or are in charge of the task. Effectively, these users are subscribing to notifications that are informing them of major changes in the task.
  • The access to the task granted via Manage access to projects/experiments/tasks has to do only with access to the task. Of course, users who actually contribute to task content have to have appropriate access to do that. In addition, users such as supervisors, reviewers, or even management also need access because of their positions inside an organization, even though they are not contributors to task content. This access can be changed over time, e.g. when users have moved away from the project, or perhaps even leave the organization.

Assigning items to Downstream tasks in workflows is slightly different

When users are assigning inventory items to tasks, they also have the option to assign inventory items to downstream tasks (tasks connected in workflow). Items will only be assigned to tasks for which users have edit permissions (so not necessarily to ALL tasks).

Changes to received notifications

All notifications that users received when they had access to an object (e.g. a task) will stay listed in their Notifications inbox after they lose access. However, the links to objects (e.g. tasks) inside the notifications will work only if users have access to them. Otherwise, a no access error will be returned.

Changes to how Team administrators view projects

Up to now, Team administrators had the privilege to view all projects in their team and all of the project content (experiments and tasks) even if they were not specifically granted access to the project.

From now on, Team administrators retain the privilege to see just the “surface” of the projects (project cards and projects listed in table view) and no longer have default view access to all experiments and tasks inside the projects. However, they do retain a privilege to grant themselves access to a concrete project or grant other users access to the project via the regular access management functionality. For this reason they also no longer have the  „Add me as owner“ option, but rather have to use the conventional manage access functionality.

On a related note, Organization administrator roles also lost „Add me as owner“ option for projects. They will need to be enrolled into a Team as any other user, in order to have access to projects, experiments, and tasks.

Changes to API

These changes will affect only SciNote API users:

  • Due to the upgrade of the permission system, we changed a payload on the Project users endpoint to make it compatible with our new permission system. The only change to the payload is the ‘type’ field, which is changed from ‘experiment_user_assignments’ to ‘user_assignments’. The rest of the payload and URL stays the same.
  • Because the upgraded permission system brings the ability to change user roles on experiments and tasks (this was not possible before), we added new API endpoints to Experiment users and Task users. API documentation was updated, accordingly.