...
The permission model will be permission-based, assigning a role vis-a-vis a specific target model (aka a “permission”);
These new permissions will still be assigned to a user (not modeled as an association between an Account record and any other record in the system…this is easier to implement but it means that permissions won’t be cascade deleted when the target objects are deleted, only when the account is deleted);
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, a user will at least have the auditor role for all studies sponsored by all of their organizations (this is the only transitively assigned role we’ve identified at this time and even that is optional);
Bridge roles are hierarchical. Generally a user should have only one role vis-a-vis a model object. For example, being a study designer
STUDY_DESIGNERimplies that you can read information about studies, like the auditor role. Every study designer does not also have to be an auditor.PI_AgentAGENTcould be an example of an exception to this.Currently an app-scoped developer, researcher, or admin can operate on any model in the app that requires that role (or its scoped counterpart, like study designer). DO WE WANT TO AXE THIS?
...