Support organizational roles

[slifty]

This PR adds internal support for the creation of role / access grants to users for our three organizational entity types.

It does not yet provide endpoints for creation and deletion of those roles, nor does it apply the roles when determining whether or not a user is allowed to perform a given action. These will come in a future PR.

Related to #1250

[codecov]

Codecov Report

Attention: Patch coverage is 94.64286% with 3 lines in your changes missing coverage. Please review.

Project coverage is 87.51%. Comparing base (446042a) to head (07da57a).
Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
...issions/createOrUpdateUserChangemakerPermission.ts	90.00%	1 Missing ⚠️
...ssions/createOrUpdateUserDataProviderPermission.ts	90.00%	1 Missing ⚠️
...rPermissions/createOrUpdateUserFunderPermission.ts	90.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1284      +/-   ##
==========================================
+ Coverage   87.33%   87.51%   +0.17%     
==========================================
  Files         172      182      +10     
  Lines        2258     2314      +56     
  Branches      298      305       +7     
==========================================
+ Hits         1972     2025      +53     
- Misses        261      264       +3     
  Partials       25       25              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bickelj]

I was able to lint, build, and test:ci this PR locally, great!

It is not clear to me if this change implements role-based access control or access control lists. In other words, I cannot tell if Changemaker in ChangemakerRole is the subject or the object. The word Role to me connotes subject. If Changemaker there is truly a subject, then I think the object is missing in the entity. If Changemaker there is the object, then I think the word Role is inappropriate. Perhaps ChangeMakerAccessControl or something like that would be more appropriate.

I think at least one application of the access control and an associated test would help clarify.

[slifty]

@bickelj you asked to show an example of using this in code but I think that's premature since there's no way to grant access via API in this PR (I can add it all to one PR but the PR will get much bigger!)

That said, one example of an application of this would be that a user with edit access to a foundation would be allowed to create proposal versions for any proposal associated with that foundation's opportunities, or add new proposals to an opportunity.

[slifty]

@jasonaowen we talked about taking out view but I am confident that I'll be prioritizing the implementation of the view permissions in the next two weeks so I'd prefer to keep it in and avoid the nearly immediate migration / enum change.

[bickelj]

@bickelj you asked to show an example of using this in code but I think that's premature since there's no way to grant access via API in this PR (I can add it all to one PR but the PR will get much bigger!)

That said, one example of an application of this would be that a user with edit access to a foundation would be allowed to create proposal versions for any proposal associated with that foundation's opportunities, or add new proposals to an opportunity.

This helps. I thought of another clarifying question. Does a row in the [Yada]Changemaker[Yada] table imply membership in that Changemaker or is it exclusively access to that Changemaker's stuff? For example, can I as an OTS team member have rows for my user in [Yada]Changemaker[Yada] and that not be misinterpreted as my membership of that Changemaker?

[bickelj]

Maybe I actually want the group membership thing to be modeled somewhere. That would be one more level of indirection. Right now it looks like User to Changemaker relationships where the relation indicates access to that Changemaker's objects. But nowhere can I declare "this User is a member of that Changemaker" and then bind that Changemaker to have access to objects. What I just mentioned gives up simpler modeling in the software to gain simpler management for customers in the long run. If Groups or Keycloak Roles are granted permissions to objects instead of Users, adding a User to a Group or Role gives that User all the permission needed straightaway.

To support my suggestion above, I see this text in the OP for #1250:

This issue will include logic that allows users associated with a given organization to be able to add other users to their organization.

[slifty]

If Groups or Keycloak Roles are granted permissions to objects instead of Users, adding a User to a Group or Role gives that User all the permission needed straightaway.

Agreed this could be (is!) interesting.

What do you think of sticking with this simpler model (direct permissions on users) for this PR, but exploring the potential of moving to a more advanced (and Keycloak) driven one as a future iteration?

[bickelj]

Yes, use this as a first increment. I think it can be adapted pretty easily to fit whatever we do in Keycloak.

[bickelj]

OpenAPI spec needs an update to use "Permission" language but otherwise skimming over this it looks great!