...
Roles | Scope | |
|---|---|---|
Developer | Study | Can edit the configuration of the study and its schedule. |
Researcher | Study | Can list, view, edit, delete, enroll and unenroll accounts in the study. |
Governance | Study | Can move the study into a production stage, and can view the data being exported to a project in Synapse. User must be a validated Synapse user. |
Admin | Study | Can do anything related to a study or its participants, and they can change users associated to the study or their roles in that association. |
Other. These are legacy roles but there are still many APIs that require one of these roles, particularly around configuring an app:
...
We’re reimplementing a lot of the functionality of Spring Security’s authorization support. It might be desirable to switch over rather than further implementing a custom solution. We need a table of permissions that can be used to answer the framework’s authorization questions.
| Code Block | ||
|---|---|---|
| ||
class Permission {
String userId;
String role;
String objectType;
String objectId;
// Object ID may need to be compound
void setStudyObjectId(String appId, String studyId) {
this.objectId = appId + ":" + studyId;
}
} |
Migration
Existing roles can be expressed in the new permissions table in order to make the same kind of authorization checks. This can be done independently of allowing users to be in multiple organizations. For every administrative account in the system, we’d want to create entries based on their current roles:
...