Support granting of permissions for users in the context of organizational entities #1250

slifty · 2024-10-14T15:00:40Z

We want to support more granular permissions (per #1093) and the first step to being able to do this is to support relationships between users and our three types of organizational entity (Funder, ChangeMaker, and DataProvider).

For this issue those associations won't actually impact permissions in terms of viewing data yet.

This issue will include logic that allows users associated with a given organization to be able to add other users to their organization. As mentioned in #1093 we may eventually want to support the concept of an admin user, but for MVP we can stick with a higher trust model.

slifty · 2024-10-14T15:10:29Z

Since this is going to create relationships with what we currently call Organization I'd like to knock out #1117 first (otherwise we'll just be immediately changing some of what we write for this issue)

slifty · 2024-10-14T20:15:05Z

I'm going to be so bold as to add a user_role column to the relationship table, because it is pretty simple to implement now.

CREATE TYPE user_role AS ENUM (
  'administrator',
  'editor',
  'viewer',
)

These roles seem straightforward and universal. It may be that we want owner as well but I'm also comfortable adding that later if the use case becomes a priority.

Users in our system can be associated with the three types of organization in the PDC (changemakers, funders, and data providers). These associations will allow them access to perform various actions in the context of those organizations. For instance, reading data, writing data, or managing other user associations. This list of abilities may change in future. We explored the concept of `user_roles` with foreign keys to different organization types (similar to the sources table) but decided to have three separate tables because they are slightly distinct concepts. For instance, there will probably be certain access types that only apply to certain types of organization in future. Another design decision was to have the permissions in terms of granted access type rather than higher level role. For instance, instead of roles like "administrator" and "editor" we have action oriented roles like "read" and "manage". This provides more granularity and is also more explicit about what a given role / access type actually allows. Issue #1250 Support associations between users and organizational entities

slifty · 2024-10-28T14:19:21Z

Some decisions we made which I want to lock in here:

We want endpoints that look like this...

-- PUT /users/{userKeycloakUserId}/roles/funders/{shortCode}/accessType/administrator => {}
-- GET /users/{userKeycloakUserId}/roles/funders/{shortCode}/accessType/administrator
-- DELETE /users/{userKeycloakUserId}/roles/funders/{shortCode}/accessType/administrator

Users in our system can be associated with the three types of organization in the PDC (changemakers, funders, and data providers). These associations will allow them access to perform various actions in the context of those organizations. For instance, reading data, writing data, or managing other user associations. This list of abilities may change in future. We explored the concept of `user_roles` with foreign keys to different organization types (similar to the sources table) but decided to have three separate tables because they are slightly distinct concepts. For instance, there will probably be certain access types that only apply to certain types of organization in future. Another design decision was to have the permissions in terms of granted access type rather than higher level role. For instance, instead of roles like "administrator" and "editor" we have action oriented roles like "read" and "manage". This provides more granularity and is also more explicit about what a given role / access type actually allows. Issue #1250 Support associations between users and organizational entities

Users in our system can be given permission to three kinds of organization in the PDC (changemakers, funders, and data providers). These associations will allow them access to perform various actions in the context of those organizations. For instance, reading data, writing data, or managing other user associations. This list of abilities may change in future. We explored the concept of `user_roles` with foreign keys to different organization types (similar to the sources table) but decided to have three separate tables because they are slightly distinct concepts. For instance, there will probably be certain access types that only apply to certain types of organization in future. Another design decision was to have the permissions in terms of granted access type rather than higher level role. For instance, instead of roles like "administrator" and "editor" we have action oriented roles like "read" and "manage". This provides more granularity and is also more explicit about what a given role / access type actually allows. Issue #1250 Support associations between users and organizational entities