| Table of Contents | ||||
|---|---|---|---|---|
|
Separate participant and administrative account management
[create a diagram of the current situation]
Expanded permissions model
...
Method | URL | Description |
|---|---|---|
GET | /v1/permissions/{userId} | Get all permissions for a user. |
GET | /v1/permissions/{objectType}/{objectId} | Get all permissions for an object like organization, study, or app. |
POST | /v1/permissions | Create a permission for a specific object and user. Caller must be an admin for the object. Returns the object with a GUID. |
POST | /v1/permissions/{guid} | Update a permission (caller must be an admin for the object). |
DELETE | /v1/permissions/{guid} | Remove a permission for an object (caller must be an admin for the object). |
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 | Description | |
|---|---|---|---|
DEVELOPER | DEVELOPER, APP DEVELOPERSCOPE | ||
RESEARCHER | RESEARCHER, APP SCOPE | ||
ADMIN | ADMIN, APP RESEARCHERSCOPE | ||
STUDY_DESIGNER | DEVELOPER, STUDY DEVELOPERSCOPE | ||
STUDY_COORDINATOR | RESEARCHER, STUDY RESEARCHERSCOPE | ||
ORG_ADMIN | ORGANIZATION ADMIN | ||
ADMIN | APP ADMIN | ||
SUPERADMIN | SYSTEM ADMIN | ||
WORKER | SYSTEM WORKERPI_AGENT, STUDY SCOPE | Can move study into recruitment phase, can be made the administrator of data repository for study, must be verified Synapse user. | |
ORG_ADMIN | ADMIN, ORGANIZATION SCOPE | ||
SUPERADMIN | ADMIN, SYSTEM SCOPE | ||
WORKER | WORKER, SYSTEM SCOPE |
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.
...