CUCentralAdvancement / giving-backend

Home of CMS that powers giving.cu.edu amongst other Central Advancement content needs.
MIT License
1 stars 0 forks source link

Add Spaces Model And Basic Authorization #72

Closed alexfinnarn closed 3 years ago

alexfinnarn commented 3 years ago

Users can be associated to "owning" content in several different ways. The traditional way is to add a "role" to the user. However, the role usually amounts to a string of text and nothing more. In theory, there is no difference between having a "fund manager" role or being part of the "Fund Manager" team, but a team constitutes more data and behavior.

For instance, to have a user "own" a role doesn't make sense, but if a user owns a team...or is "captain" of the team, then semantically it makes more sense.

I'm going to keep with the campy "Space Cadet" theme and name things in that realm...cause it's fun and can tangentially relate to the work CU does with space.

Acceptance Criteria

Next Steps:

alexfinnarn commented 3 years ago

I now think Pundit is a way better authorization gem since it has less magic and does not seem to conflict with the friendlyid gem. The load_and_authorize controller helper uses the regular ID and not the slug so they tell you to add an initializer that caused several errors I didn't want to sort through.

The plot thickens with adding multi-tenancy to authorization, https://github.com/CUCentralAdvancement/giving-backend/issues/24.

Based on https://github.com/varvet/pundit#additional-context, I thought you would need to do that with a subdomain or whatever to determine which tenant/account to authorize based on, but I guess that would be available under user.account. Users can only have one account since it's a belongs_to relationship.

...I guess I just need to write this out to gather my thoughts since I'm learning a lot of tangential concepts that all need to be implemented together.

I think it all comes down to scopes and the default_scope which Rails uses to scope any query. For example, Funds.all should return all funds under the default scope, which can be scoped to the user's tenant ID. This is similar to Drupal's way of owning the content and how "edit_own" user permissions can work.

However, then you have the case where multiple users will want to have control of a group of items...I think the tenant ID can be a space and include multiple spaces with a comma-separated list. When you enter a space, everything gets that default scope. So you can have "fund_managers" and "denver_fund_managers" both include funds from the Denver campus.

alexfinnarn commented 3 years ago

I now have basic authentication and authorization working, and I learned quite a bit about all sorts of things in the process. I now need to write Cypress tests to confirm this works, write a bit of documentation, and then close this issue.

I still am thinking of how to scope the listing pages.

I feel like starting with the Pundit scopes makes the most sense vs. changing the default paths for resources. Also, you'd have to do more with nested resources, which all wouldn't be available per Space.

alexfinnarn commented 3 years ago

welp, my side trip into trying to stand up a 404 page doesn't work. Really confused how Rails is so popular but searching for how to handle a 404 took me down a rabbit hole of rescuing exceptions and getting "double render error". I think I found another method to try, but I will forgo adding anything other than standard errors for now.