Now that users can log in and a user gets created in the database, it's time to add the concept of "spaces" to the app. A space is a collection of functionality surrounding a project, or more specifically a representation of someone's job duties. The spaces should fit into current Advancement employees' roles.
For example, it is common for CMSes to have the same admin areas for all sorts of user roles. The page then has to decide what content to show the user... which sounded very complicated to build so I decided users can be part of multiple "spaces" that resemble their job duties as a whole.
Funds have the most amount of content on the current Giving site, but it's not true that the current fund edit page caters to just one type of user. In reality, a "fund admin" is needed to be able to correct any automation errors and administer all funds. Some users only need to interact with funds a "fund admin" user would assign them as "fund managers".
What is the point of sending those users to the same UI? I will split it up to allow for the same components to be rendered for both "/spaces/fund-admin/content/fund/[id]/edit" as "/spaces/fund-manger/content/fund/[id]/edit" but the title and brief description will be read-only for the "fund manager".
With this pattern, all the permission system needs to know is the active space, via the route, and if the user ID is included in the space.
It might be worth it to create a custom React Hook that uses useSession from next-auth and can be used in the spaces routing. I guess it is fine to copy/paste things now, but some pattern should emerge.
It is also important to keep "meta-administration" out of the Spaces. This issue will likely add admin users, set up via an env var, that can administer all spaces, including inviting users. Hard-coding the few super admins will help with keeping auth simple and allowing users in Spaces full access.
Required
What area of the codebase does this involve?
This will touch authentication, and all routes need that now.
Will this impact CI/CD procedures?
No.
Relate To Security?
Yes...need a label.
Acceptance Criteria
[x] Space model is added to Prisma schema.
[x] Migration captured for setting up database.
[x] "/admin/spaces/create" can assign current users to spaces.
Now that users can log in and a user gets created in the database, it's time to add the concept of "spaces" to the app. A space is a collection of functionality surrounding a project, or more specifically a representation of someone's job duties. The spaces should fit into current Advancement employees' roles.
For example, it is common for CMSes to have the same admin areas for all sorts of user roles. The page then has to decide what content to show the user... which sounded very complicated to build so I decided users can be part of multiple "spaces" that resemble their job duties as a whole.
Funds have the most amount of content on the current Giving site, but it's not true that the current fund edit page caters to just one type of user. In reality, a "fund admin" is needed to be able to correct any automation errors and administer all funds. Some users only need to interact with funds a "fund admin" user would assign them as "fund managers".
What is the point of sending those users to the same UI? I will split it up to allow for the same components to be rendered for both "/spaces/fund-admin/content/fund/[id]/edit" as "/spaces/fund-manger/content/fund/[id]/edit" but the title and brief description will be read-only for the "fund manager".
With this pattern, all the permission system needs to know is the active space, via the route, and if the user ID is included in the space.
It might be worth it to create a custom React Hook that uses
useSessionfromnext-authand can be used in the spaces routing. I guess it is fine to copy/paste things now, but some pattern should emerge.It is also important to keep "meta-administration" out of the Spaces. This issue will likely add admin users, set up via an env var, that can administer all spaces, including inviting users. Hard-coding the few super admins will help with keeping auth simple and allowing users in Spaces full access.
Required
What area of the codebase does this involve?
This will touch authentication, and all routes need that now.
Will this impact CI/CD procedures?
No.
Relate To Security?
Yes...need a label.
Acceptance Criteria