Versions Compared

Version Old Version 46 New Version 47
Changes made by

Alx Dark

Alx Dark

Saved on

Key

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

...

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

  2. Create bridge code so that organization memberships are mired 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 tables;

  5. Annotate our controllers with the new permissions;

  6. Switch over external tools to use permissions apis rather than account APIs to manage permissions;

  7. 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 futureInitially we modeled this as an object relationship in the database. I’m struggling to figure out why this can’t just be modeled in the permissions table. The value of organizations is also decreased since it’s just a construct to limit who you can see working in an app (which we must to support studies as isolated tenants in a single app). However if we need to, we can introduce a Membership associative table between Accounts and Organizations.