...
ld
We have been looking at three related pieces of work:
...
Model/Association/Verb | Permission | Meaning |
|---|---|---|
Organization | userId ∈ {organization:orgId view} | Can view information about the organization. |
userId ∈ {organization:orgId edit} | Can edit the organization | |
userId ∈ {organization:orgId admin} | Can edit permission for the organization | |
SponsoredStudies * | userId ∈ {sponsoredstudies:orgId list} | Can see the studies sponsored by the organization |
Members * | userId ∈ {members:orgId list} | Can see the members of an organization |
userId ∈ {members:orgId admin} | Can create/add/remove members | |
Assessments * | userId ∈ {assessments:orgId list} | Can view the assessments of an organization |
Study | userId ∈ {study:studyId view} | Can view a Study (not its participants). |
userId ∈ {study:studyId edit} | Can view or edit the Study | |
userId ∈ {study:studyId admin} | Can edit permissions for the Study | |
Study PI * | userId ∈ {studystudypi:studyId piedit} | Can move the study from design to recruitment. |
StudyParticipants * | userId ∈ {participants:studyId list} | Can view a list of AccountSummaries in this study |
userId ∈ {participants:studyId view} | Can view StudyParticipant | |
userId ∈ {participants:studyId edit} | Can view or edit StudyParticipant | |
userId ∈ {participants:studyId admin} | Can create accounts and enroll/withdraw them from the study. | |
Assessment | userId ∈ {assessment:guid view} | Can view an assessment |
userId ∈ {assessment:guid edit} | Can view or edit an assessment | |
userId ∈ {assessment:guid admin} | Can edit permissions for the assessment |
Here’s the old table
...
Model
...
Role
...
Organization
...
Administrator
...
Can list, view, add and remove people from an organization.
Can they edit an account in the organization
Can list studies sponsored by the organization
...
Organization
...
Member
...
Can list people in the organization
Can list studies sponsored by the organization
Note that it imparts no roles vis-a-vis other models, including studies
...
Study
...
Auditor
...
Can read information about the study and its schedule. Cannot edit anything and can’t see people.
...
Study
...
Developer
...
Can read and edit the configuration of the study and its schedule.
...
Study
...
Researcher
...
Can list, view, edit, delete, enroll and unenroll accounts in the study.
...
Study
...
PI_Agent
...
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. Can delete a study.
...
Study
...
Admin
...
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.
...
Assessment
...
Assessments are owned by organizations, not studies. Study members can read them, who can work with assessments?
...
App
...
Developer
...
Can access many APIs for the configuration of an app and related resources like app configs.
...
App
...
Researcher
...
Can see all accounts in the system regardless of organization or study boundaries.
...
App
...
Admin
...
Can call any API in the scope of the account’s app.
...
Global
...
Worker
...
Can access APIs that specifically allow the worker to call across app boundaries without switching applications first.
...
Global
...
Admin
...
Can do anything in any app, study, or organization (superadmin)
Note that membership in an organization is also directly modeled in the database right now via the Account.orgMembership field. If we continue to model this in the database, it'll become an associative table and that association could specify the roles you gain as a member of the organization—however no one is asking for this so I don't intend that we will do it.
Implementation
We will introduce a flat table of Permission records that can be easily retrieved by user or by target model object:
...
| language | java |
|---|
...
Implementation
We will introduce a flat table of Permission records that can be easily retrieved by user or by target model object:
| Code Block | ||
|---|---|---|
| ||
public class Permission {
String guid; // synthetic key makes create/add/update APIs easier
String appId; // most permissions except system-wide, and usually implicit
String userId;
String role; // "admin", "developer"
String objectType; // "study", "organization", "app", "system"
String objectId; // "studyId", "orgId", "appId"
// Suggested toString() descriptor (implicitly scoped to an app):
// "2rkp3nU7p8fjUTDVIgjT6T ∈ {organization:sage-bionetworks admin}"
}
public enum ObjectType {
ASSESSMENT(ASSESSMENT),
STUDY(STUDY),
ORGANIZATION(ORGANIZATION),
SPONSORED_STUDIES(ORGANIZATION),
MEMBERS(ORGANIZATION),
ASSESSMENTS(ORGANIZATION),
STUDY_PI(STUDY),
PARTICIPANTS(STUDY);
} |
For APIs that have to display permissions, the appId/userId can be replaced with an AccountRef object, similar to the EnrollmentDetail object.
...