create, read, update, delete endpoints for `data_requests`

[maxachis]

Part of #256

• [x] Update data_requests schema with new specifications
• [x] Add column permission configuration to database via https://github.com/Police-Data-Accessibility-Project/prod-to-dev-migration/tree/main/relation_access_permissions
• [x] Read/Get
  • show all fields except submitter_contact_info and internal_notes
• [x] Update/Put
  • admins can edit any field that's not auto-generated
  • the user who submitted the request can edit anything that was submittable on the form
  • the user who submitted (or an admin) should be able to hit a "withdraw request" and enter a withdrawal_reason
  • no one else can edit
• [x] Ensure Swagger documentation programmatically lists all columns which can be edited/viewed for different permission levels

Supporting Issues

• [x] #405
• [x] #355
• [x] #398
• [x] #399
• [x] #397
• [x] #391

[maxachis]

VIEW AND EDIT PERMISSIONS

@josh-chamberlain, does this format look to be what you would expect in terms of view, edit permissions? It may be useful to migrate this to the data dictionary so as to have a singular source of truth which my code can then derive from.	COLUMN	STANDARD	OWNER	ADMIN
submission_notes	VIEW	EDIT	EDIT
request_status	VIEW	VIEW	EDIT
submitter_email		EDIT	EDIT
location_described_submitted	VIEW	EDIT	EDIT
archive_reason		VIEW	EDIT
date_created	VIEW	VIEW	VIEW
date_status_last_changed	VIEW	VIEW	VIEW
coverage_range	VIEW	EDIT	EDIT
data_requirements	VIEW	EDIT	EDIT
record_types_required	VIEW	VIEW	EDIT
github_issue_url	VIEW	VIEW	EDIT
internal_notes			EDIT
target_date	VIEW	EDIT	EDIT
pdap_response	VIEW	VIEW	EDIT
id	VIEW	VIEW	VIEW
creator_user_id		VIEW	VIEW

[josh-chamberlain]

@maxachis I made some edits, adding VIEW in a couple places.

• removed record_type
  • not sure where it came from, but it's redundant with data_requirements and record_types_required
• removed volunteer_contact as it's redundant with project management in github
• renamed github_issue to github_issue_url in data dictionary and airtable to match this
• renamed submitted_contact_info to submitter_email to match the future intent (emails are wayyyy more useful to us than phone numbers)

Is there any way to have this kind of thing live in the swagger API docs?

[maxachis]

Is there any way to have this kind of thing live in the swagger API docs?

Indeed it can! I tried it out right now, using the same formatting as in the comment above, and got it to work!

We could even, as I discuss in #391, incorporate these permissions programmatically, and then have those configurations also inform the markdown. That'd require more code, but it would help ensure things stay up to date.

[josh-chamberlain]

(my edits from before didn't stick/save, but I edited again)

[maxachis]

@josh-chamberlain Two points!

1. I added creator_user_id and volunteer_can_contact_requestor provided what I figured made sense as view/edit permissions, but feel free to modify.
2. If we have creator_user_id, do we need submitter_contact_info?

[josh-chamberlain]

@maxachis

1. creator_user_id sounds great; I'm removing volunteer_can_contact_requestor. We're removing that column, it is no more! In v2, progress made on requests will be visible to everyone, and the requestor can speak up if needed. If we do create this concept in future, it would be a user-level property.

2. Yes, I think we do—and it should simply be submitter_email. We will still allow requests for people who are not signed in. We may infer one from the other.