Closed maxachis closed 3 weeks ago
@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 |
@maxachis I made some edits, adding VIEW
in a couple places.
record_type
data_requirements
and record_types_required
volunteer_contact
as it's redundant with project management in githubgithub_issue
to github_issue_url
in data dictionary and airtable to match thissubmitted_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?
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.
(my edits from before didn't stick/save, but I edited again)
@josh-chamberlain Two points!
creator_user_id
and volunteer_can_contact_requestor
provided what I figured made sense as view/edit permissions, but feel free to modify.creator_user_id
, do we need submitter_contact_info
?@maxachis
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.
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.
Part of #256
data_requests
schema with new specificationssubmitter_contact_info
andinternal_notes
withdrawal_reason
Supporting Issues