-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support source creation from consent, remove kit password #55
Conversation
…t to enable creation of a human source from a submitted consent form
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change Request: Can you check if you can change the type from array to whatever in the yaml and fix everything coming in as lists in the body?
Comment: Pick either 18-plus or 18+ and let me know which one to use in the database
Comment: Let me know what to store for deceased_parent, needs schema change and migration heuristic most likely.
@@ -278,23 +278,44 @@ def dissociate_answered_survey(account_id, source_id, sample_id, survey_id): | |||
return not_yet_implemented() | |||
|
|||
|
|||
def read_kit(kit_name, kit_password): | |||
def read_kit(kit_name): | |||
with Transaction() as t: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... I know we aren't going to have kit_password in the future, but does this break migration for existing users? Are our existing kit_name's secure enough to allow everyone to login by kit_name alone until they first register an account with us? I wonder if we need a flag in the db for old_kit or new_kit to enable this...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding was that the decision had been made to take this out, so if that is being rethought, I gotta kick this one to @wasade ....
…t all inputs as arrays. Thanks to @dhakim87 !
@dhakim87 , think we need an update on what is required before this PR can be approved. AFAIK, the form field lists issue is fixed (thanks again :) and the 18+ vs 18-plus question has been resolved (in a way that doesn't require changes to this PR). The two remaining issues I see are:
|
Fixes #27, moving the consent endpoint under account and adding a post to enable creation of a human source from a submitted consent form.
Unfortunately, those who live by the shiny new supporting library also die by the shiny new supporting library: although the openapi3 specs support allowing different media types to be passed into a single endpoint (which would have allowed us to add creating a human source from consent form data as another aspect of the /accounts/{account_id}/sources POST that already can take in json data),
connexion
doesn't currently implement the "multiple media types per endpoint" aspect of openapi3 (spec-first/connexion#655, spec-first/connexion#805 ). Therefore it was necessary to kludge a little. The new /accounts/{account_id}/consent endpoint has a GET that gets consent form html as well as, now, a POST that creates a human source from a submitted consent form (using ONLY the form data media type). I am open to suggestions for better ways to do this.Because @dhakim87 has ongoing work on
source.py
, I can't carry through the full implementation of creating a source from the consent form, but I have verified I can parse the incoming data and toss it over to the existingcreate_source
call.Note that, for some reason I can't fathom, connexion sends all form field values to the back end as lists, regardless of the input element type ... e.g.,{'age_range': ['7-12'], 'consent_child': ['Yes'], 'participant_name': ['a'], 'participant_email': ['b@c.com'], 'consent_witness': ['Yes'], 'obtainer_name': ['Me'], 'consent_parent': ['Yes'], 'parent_1_name': ['b'], 'parent_2_name': ['c'], 'deceased_parent': ['true']}
... Given this, the main thing I do with the form data is ensure each of these lists is really just a single value and then dig it out to make, e.g.,{'age_range': '7-12', 'consent_child': 'Yes', 'participant_name': 'a', 'participant_email': 'b@c.com', 'consent_witness': 'Yes', 'obtainer_name': 'Me', 'consent_parent': 'Yes', 'parent_1_name': 'b', 'parent_2_name': 'c', 'deceased_parent': 'true'}
... which is what I thought we should get anyway ...This PR also fixes #27, removing use of kit_password from the yaml api,
implementation.py
, andkit_repo.py
.