Epic: Permissions implementation

[fyliu]

Dependencies

• issue Discuss our requirements for permissions #150
• discussion Permissions requirements #159
• Research how permissions is implemented in Django and DRF #149

Overview

We need to research how permissions is implemented in Django and DRF, versus what we need.

This is a meta issue to keep track of the action issues.

Action Items

• compare our needs to what Django and DRF provides
• implement or research permission packages that will support our needs
• take Create Table: user permission #22 out of the ice box and make any adjustments to it
• release Make PeopleDepot locally usable for VRMS development #29 from the ice box
• close this issue as complete

Discussion

• Django comes with Group and Permission models in django.contrib.auth out of the box. If they don't match up well, then we need to evaluate existing packages and decide on one that will support our requirements best
• we need to define our requirements (what we need) for permissions
  • ex. a project lead needs to be able to update the project they are leading (row in the project table for their project), but not be able to update the other projects (rows belonging to other projects).
  • ex. a contributor needs to be able to edit their own user profile, but not the user.status field, since that data belongs to the organization, and not the other user profiles.
  • more requirements (aka acceptance criteria)

[ethanstrominger]

I researched Django permissions and it is very customizable, so it should be able to handle anything we come up with. Django uses user groups and permissions.

You can assign user groups privileges to

• add, change, delete, and view permissions for individual tables.
• set permissions on a per record basis based on values in that record or any other condition using has_permission
• create a generic role like "access api" for generic access

[PlantGirlCodes]

Up for discussion next week #150 per @fyliu next week 8/24/23