Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
languagejava
public class Permission {
  String guid; // synthetic key makes create/add/update APIs easier
  String appId; // thismost alwayspermissions has to be part of the queryexcept 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}"
}

...

Old role

New role

Description

DEVELOPER

DEVELOPER, APP SCOPE

userId ∈ {app:appId developer}

RESEARCHER

RESEARCHER, APP SCOPE

userId ∈ {app:appId researcher}

ADMIN

ADMIN, APP SCOPE

userId ∈ {app:appId admin}

STUDY_DESIGNER

DEVELOPER, STUDY SCOPE

Create this role for every study currently sponsored by the account’s organizationuserId ∈ {study:studyId developer}

STUDY_COORDINATOR

RESEARCHER, STUDY SCOPE

Create this role for every study currently sponsored by the account’s organizationuserId ∈ {study:studyId researcher}

PI_AGENT, STUDY SCOPE

userId ∈ {study:studyId pi_agent}

ORG_ADMIN

ADMIN, ORGANIZATION SCOPE

userId ∈ {organization:orgId admin}

MEMBER, ORGANIZATION SCOPECreate this permission for the account’s member organization? Not sure if we want to duplicate like this. Maybe we do and drop the org membership column, allowing for an easy migration to membership in multiple organizations.

userId ∈ {organization:orgId member}

SUPERADMIN

ADMIN, SYSTEM SCOPE

userId ∈ {system admin}, in other words, appId is null

WORKER

WORKER, SYSTEM SCOPE

userId ∈ {system worker}, in other words, appId is null

The steps would be:

  1. Add the permissions table, service, APIs, completely separate from existing security so they are completely functional;

  2. Create bridge code so that organization memberships are mired in the permissions table (only needs to be one way);

  3. Create bridge code so that role changes create the counterpart permissions (only needs to be one way);

  4. Migrate all existing account roles to the new permissions tables;

  5. Annotate our controllers with the new permissions;

  6. Switch over external tools to use permissions apis rather than account APIs to manage permissions;

  7. Remove roles and bridge code from accounts.

...