Use Cases
Use Case | |
|---|---|
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 | |
Study recruits from existing user pool into 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. |
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 and possibly also for viewing studies created by others in the organization. “Membership” in an organization could be modeled as a role that can list studies and users for the organization. You could then have more than one of these records and we could adjust what “being a member of an organization” means through the use of other roles in an organization. An organization admin for example as an ADMIN role that can do more with the organization itself.
Implementation Considerations
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.
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:
Old role | New role | For object |
|---|---|---|
DEVELOPER | DEVELOPER | APP |
RESEARCHER | RESEARCHER | APP |
STUDY_DESIGNER | DEVELOPER | STUDY (one for every study sponsored by user’s organization; every admin user must be in an organization) |
STUDY_COORDINATOR | RESEARCHER | STUDY (one for every study sponsored by user’s organization; every admin user must be in an organization) |
ORG_ADMIN | ADMIN | ORGANIZATION |
ADMIN | ADMIN | APP |
SUPERADMIN | ADMIN | SYSTEM |
WORKER | SUPERADMIN | SYSTEM |
We’d need to update both representations of roles in both places (as part of accounts and part of permissions), move over to authorizing requests using the permissions table, and then remove the bridge code and finally, delete the AccountRoles table.
New roles
Role | For object | Description |
|---|---|---|
MEMBER | Organization | Can list all members of the organization or all studies sponsored by the organization |