Versions Compared

Version Old Version 70 New Version 71
Changes made by

Alx Dark (Unlicensed)

Alx Dark (Unlicensed)

Saved on

Key

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

...

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)

...

  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 memberships membership changes are mired mirrored 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 tablesbut not vice versa?);

  5. 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;

  6. Annotate our controllers with the new permissions;

  7. Remove old code checking permissions;

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

  9. Remove bridge code;

  10. Remove roles and bridge code from accountsfrom accounts;

  11. 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.

Multiple organization membership

...