Page Comparison

...

...

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 roleaccessLevel; // "admin", "developer"
  String permissionTypeentityType; // "study", "organization", "app", "system"
  String objectIdentityId; // "studyId", "orgId", "appId"
  
  // Suggested toString() descriptor (implicitly scoped to an app):
  // "2rkp3nU7p8fjUTDVIgjT6T ∈ {organization:sage-bionetworks admin}"
}

// Each type relates to a specific entity and its ID (indicated in the constructor)
public enum PermissionType {
  ASSESSMENT (ASSESSMENT),
  STUDY (STUDY),
  ORGANIZATION (ORGANIZATION),
  SPONSORED_STUDIES (ORGANIZATION),
  MEMBERS (ORGANIZATION),
  ASSESSMENTS (ORGANIZATION), // ASSESSMENT_LIBRARY?
  STUDY_PI (STUDY),
  PARTICIPANTS (STUDY);
}

...

...

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

2. Create bridge code so that roles and organization membership changes are mirrored in the permissions table (but not vice versa?);

3. Migrate all existing account roles to the new permissions tables. Changes made at any time after the migration should also make it to the permissions tables, which still cannot be used;

4. Annotate our controllers with the new permissions;

5. Remove old code checking permissions;

6. Switch over to use the new permissions apis rather than account APIs to manage permissions (probably by throwing errors if roles are changed on an account).

7. Remove bridge code;

8. Remove roles from accounts;

9. Remove code that is granting permissions to studies as a result of organization membership, which is a large external change that will need to be documented and supported in existing tools.

Role to Permission Mapping

This mapping is necessary for steps 2 and 3 in migration. Each role needs to be mimicked by permissions.

Roles manage access to studies and assessments through organization membership. The “sponsored studies” and “assessment library” permissions similarly grant access to studies and assessments based on organization. So the individual “study” and “assessment” permissions should be unnecessary for migration.

The “participant” permission is more complicated because it is handled by individual study. Developers and Study Designers only have access to test accounts. Researchers and Study Coordinators have access to participant data. So mimicking the role means granting “participant” access to each study in their organization.

Multiple organization membership

...