Model Metadata Submission roles

[naglepuff]

This creates the infrastructure needed to enforce access control for metadata submissions. It is a home grown attempt to achieve this. I looked at packages like oso and casbin, but the overhead to learn those systems and be efficient developing with them was not worth it at this time. It also appears like we could use those in the future for policy enforcement, so we aren't strictly locked out of third part tools in the future. We also have some special needs due to our storage of the submission metadata as json. Our permission model actually applies the contents of a single column in our database, and it is not simply row-based permissions.

Once again, I found the Sanbox Orcid environment useful for testing changes. I could create multiple users, and do some functional testing of the permissions by adding some users as PIs for other user's submissions, ensuring that those submissions appeared on the list, etc. I am happy to help set that up for anyone who would like to try.

Summary of Changes

The changes here are strictly in backend code. Several files were touched for this PR. Some of the code added is demonstrative of intent, such as crud.py::can_read, which isn't used anywhere but shows how the permissions model can be used to implement additional permission checks at the API level.

New Model

To track permissions, the class/model/table models.py::SubmissionRole has been added. This table links a submission (via FK) to a user (via ORCID string). This way, permissions can be added for users who don't yet have a record in our user_logins table. The tradeoff is that this can lead to permissions that point to nonsense users (fake/wrong ORCID, etc). The permission levels are defined by the SubmissionEditorRole enumeration. See the permissions tab of this spreadsheet for definitions.

New Database Operations

Several new functions have been added to crud.py to be used to enforce the permissions policy defined by the roles. In the future, this kind of check could be used as a wrapper function for api endpoints, or dependencies to be injected via FastAPI.

Some routes have changed slightly

• GET /api/metadata_submission: The "get all my submissions" endpoint now used a new function which combines the check for authorship with a check for any submissions that the logged in user has a role for. Admin access to all submissions regardless of role is unaffected.
• POST /api/metadata_submission: The endpoint for creating a new submission now has the added responsibility of creating an owner role for the creator of the submission.
• GET /api/metadata_submission/{id}: The endpoint for retrieving a single submission uses the can_edit_all check. If that check fails and the user is not an admin, a 403 is returned. This can and should be modified as additional roles are added.
• PATCH /api/metadata_submission/{id}: Updating a submission is gated by the can_edit_add check as well. Additionally, change to the piOrcid will be detected and create an owner role for that ORCID.

[jeffbaumes]

I have a couple of thoughts to consider.

[mslarae13]

@naglepuff just confirming this is for edit permissions for the PI?
I just had @bmeluch & @brynnz22 test this out & Bea made Brynn the PI & she was able to view and edit the submission! Success!

[naglepuff]

Correct!