Role

A role defines permissions and data scope for a user within a repository, project and/or site. A user of Collective Minds is given a role for a specific project and is therefore a member of that project.

When a repository is created in Collective Minds Research, two default roles are created:

Repository Owner
Project Owner

Those roles can be renamed according to your needs. Also their permissions can be changed freely. Any new project that it is created will have a first member (the creator) which will be assigned the Project Owner role.

In addition to these default roles, you might want to build a new set of roles to suit your organization or your clinical trial setup. The following permissions and data scopes are available in the system which can be used to build up those, which in turn are assigned to users to interact with the projects as members:

Scopes

Scopes defines the “data scope” to which the role is limited

Site: can only interact with data and subjects generated from the assigned sites
Project: can only interact with data and subjects generated from the project where the user holds a role and is therefore a member.
Repository: can interact with all data generated within the whole repository.

Permissions

Permissions control which actions a user can perform. Please note that view permission entails run permission.

Repository permissions

Repository

Repository view: allows the user to see the list of projects available for them and the repository task list
Repository edit: can edit the repository metadata (future implementation)
Repository edit: can delete the repository metadata (future implementation)

Repository member

Member view: can view the members of the entire repository.
Member edit: can edit the role and project assignments to users.
Member delete: can de-activate and activate a repository member.
Member approve: approves (signs) the changed access for the repository. However a user cannot approve access assigned to or by oneself.

Role permissions

Role view: can view the list of roles in the repository.
Role edit: can edit the role metadata, scopes and permissions in the repository.
Role delete: can delete a role (only if not in use).

Repository site permissions

Site view: can view the repository site database and configure a customized visualization.
Site edit: can edit the site database and the site metadata.
Site delete: can delete a site (only if not in use).

Form permissions

Form view: can view the form library and preview the forms.
Form edit: can edit and create forms and configure them.
Form delete: can delete forms (only if not in use).
Form approve: can sign draft forms for live usage in pipeline events.

Tool permissions

Tool view: can view the tool library and preview/test-run the tools.
Tool edit: can check-in new tools (future implementation).

Audit log permissions

Audit log view: can view, filter and download the Repository audit log.

Project permissions

Project view: can view the dashboard in a project.
Project edit: can edit the project metadata, labels and quick access button. In combination with scope repository, can create new projects.
Project delete: can delete the project (future implementation).

Pipeline permissions

Pipeline view: can view the entire pipeline. Events can be view/run depending on the Event view permission (see below). In any case, if the pipeline has any event configured to be run by the member's role, then they will be able to view/run that event. The scope controls which data and subjects the user can see in the pipeline:
- Members with a site role only can see subjects from their site/s.
- Members with a project role can see all the subjects.
Pipeline edit: can edit the pipeline metadata, such as stages and their names. Can add new stages and events to the pipeline. However, in order to edit event metadata, modules and configuration the member will need Event edit permission.
Pipeline approve: can approve the pipeline which moves the current version from design to live mode and locks all objects in the pipeline (events, forms, tools).

Event permissions

Event view: can view all event screens in the pipeline. Can run and sign events. The scope controls which subjects can be loaded on these screens.
- Members with a site role only can see subjects from their site/s.
- Members with a project role can see all the subjects.

Event edit: can edit the metadata, modules and configuration of the events. In combination with scope Project, can create events.
Event delete: can delete an event.
No event permission: can still view, run and sign events where the user’s role is assigned, within the user’s scope

Project site permissions

Site view: can view the project site DB and configure a customized visualization. Scope controls which sites can be viewed:
- Members with a site role only can see their site/s.
- Members with a project role can see all the sites.
Site edit: can edit the site metadata and status for sites within the user’s scope.
Site delete: can delete a site (only if no subject exist associated to this site)

Subject permissions

Subject view: can view the subject listing and subject screen for subjects within the user’s scope:
- Members with a site role only can see the subjects associated to their site/s.
- Members with a project role can see all the subjects.
Subject edit: can edit the subject metadata and create new subjects according to the user's scope.
- Members with a site role only can associate new subjects to their site/s
- Members with a project role can freely associate subjects with any site

Result permissions

Result view: can view, export (ad-hoc download) and deliver (auditable download, future implementation) the results.
Result edit: can edit the structure and metadata of the results table.
Result approve: can approve (sign) a result to lock down the current version, map it towards a planned delivery and enable it for delivery (auditable download, future implementation).

Project member permissions

Member view: can view the members of the project.
Member edit: can add project members, edit the role and site assignments to users.
Member delete: can de-activate and activate a repository member.
Member approve: approves (signs) the changed access for the current project. However a user cannot approve access assigned to or by oneself.

Audit log permissions

Audit log view: can view, filter and download the audit log for the project (future implementation)