...
Use Case | |
|---|---|
| (if cached they need to be separate from the session) |
New admin account created with a sandbox in which studies can be created/edited that are not visible to others | |
“Sandbox” can be converted to real study, with additional users in specific roles for that study | |
Study is extended by creating a new study | |
Add someone to a study’s administration team | |
Remove someone from a study’s administration team | |
Create similar authorization model for assessments | We should be able to expand it to other things than studies, because it seems likely we’ll encounter something else that needs finer-grained authorization. |
Secured objects/scopes
Organizations
...
“Teams” in Synapse impart an identical set of permissions to a project for a set of users. “Organizations” in Bridge are a scope for manipulating users, since our app is multi-tenanted. The roles related to organizations:
...
Note that membership in an organization is also directly modeled in the database right now via the Account.orgMembership field, and will be moved to an associative table. We may not need a “member” role though it may be more convenient.
Studies
...
Individuals can be given specific roles vis-a-vis a study.
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. |
App/System
Other. These are legacy roles but there are still many APIs that require one of these roles, particularly around configuring an app:
...