...
Old role | New role | Description |
|---|---|---|
DEVELOPER | DEVELOPER, APP SCOPE | |
RESEARCHER | RESEARCHER, APP SCOPE | |
ADMIN | ADMIN, APP SCOPE | |
STUDY_DESIGNER | DEVELOPER, STUDY SCOPE | Create this role for every study currently sponsored by the account’s organization |
STUDY_COORDINATOR | RESEARCHER, STUDY SCOPE | Create this role for every study currently sponsored by the account’s organization |
PI_AGENT, STUDY SCOPE | ||
ORG_ADMIN | ADMIN, ORGANIZATION SCOPE | |
MEMBER, ORGANIZATION SCOPE | Create 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. | |
SUPERADMIN | ADMIN, SYSTEM SCOPE | |
WORKER | WORKER, SYSTEM SCOPE |
The steps would be:
Add the permissions table, service, APIs, completely separate from existing security so they are completely functional;
Create bridge code so that organization memberships are mired in the permissions table (only needs to be one way);
Create bridge code so that role changes create the counterpart permissions (only needs to be one way);
Migrate all existing account roles to the new permissions tables;
Annotate our controllers with the new permissions;
Switch over external tools to use permissions apis rather than account APIs to manage permissions;
Remove roles and bridge code from accounts.
Multiple organization membership
Once we have a permissions table, we can implement accounts being in multiple organizations. The utility of this construct will be lessened (because people can be permitted to act directly against a study) but it may still be important for the future.
...