Page Comparison

...

• The authorization model will be rolepermissions-based, assigning a role list, view, and/or edit permissions vis-a-vis a specific target model (we’ll call this a “permission”);

• These new permissions will be a separate table, not an association to an Account or any other record in the system…this is easier to graft onto the existing system, but it does mean that permissions won’t be deleted by the database when their associated user or model object is deleted (due to the use of non-SQL databases, this is often true in our system);

• Organizations will principally be a means to communicate who can see whom in a multi-tenanted application. Accounts will be assignable to multiple organizations. Migrated accounts will be given permissions to the sponsored studies of that organization, and then going forward, further permissions will have to be added on a case-by-case basis;

  • Another option: a person who is a developer in an organization can create a study, which is automatically sponsored by the organization.

  • A person creates a study and owns it and absolutely no one else can see it until it is sponsored or shared with others.

  • Organizations continue to transitively give their members a role that allows them to see the organization’s sponsored studies. They could then ask to have more specific roles vis-a-vis one of those studies.

• Bridge roles are hierarchical (in behavior, not in implementation). Generally a user should have only one role vis-a-vis a model object. For example, being a STUDY_DESIGNER implies that you can read information about studies, like the AUDITOR role. Every study designer does not also have to be an auditor. PI_AGENT could be an example of an exception to this.. With some Hibernate sorcery, we can ensure that foreign key relationships are maintained and permissions are deleted when users and objects are deleted;

• Permissions can be on objects (LIST, VIEW, or EDIT assessments, studies, organizations) but also on associations (VIEW or EDIT study sponsors, organization members) and rarely, on verbs (EDIT allowing for study launch). For example, the owner of an organization would have EDIT permission for the Organization and EDIT permission for the organization members. A member could have VIEW permissions over an organization’s sponsored studies. The permission to launch a study is very specific to that transformation of the state of the study.

• Organizations will principally be a means to communicate who can see whom in a multi-tenanted application. Accounts will be assignable to multiple organizations. Migrated accounts will be given permissions to the sponsored studies of that organization, and then going forward, further permissions will have to be added on a case-by-case basis;

• We may need to maintain ADMIN, WORKER, DEVELOPER, and RESEARCHER roles for our older APIs that are role-based, but all newer v2 APIs should use this new permission structure, and the Roles STUDY_DESIGNER, STUDY_COORDINATOR, and ORG_ADMIN should be removed as part of this refactor. In addition

  • App-scoped developer and researcher should will no longer have study-scoped permissions;

  • App-scoped admins can still probably do anything within their app;

  • System-scoped admins and workers can still do anything in any app;Otherwise, objects do not have any hierarchy (roles over an app do not imply roles over a study).. (Workers are always system-scoped.)

Use Cases

...