From dd7fc3a55aa06cd9337672ebbfd04f031a04f369 Mon Sep 17 00:00:00 2001 From: pbugni Date: Thu, 12 Dec 2024 12:16:10 -0800 Subject: [PATCH] TN-2747 look for indefinite QNR in both v3 and v5. (#4426) Fresh error log details lead to discovering this long outstanding symptom. Users leaving an unfinished, `in-progress` indefinite QNR from an older research protocol, then returning after their organization has transitioned protocols would raise an exception, as the lookup was too specific. --- portal/models/questionnaire_response.py | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/portal/models/questionnaire_response.py b/portal/models/questionnaire_response.py index 85bfe34fd..e24ad500d 100644 --- a/portal/models/questionnaire_response.py +++ b/portal/models/questionnaire_response.py @@ -910,11 +910,16 @@ def qnr_document_id( QuestionnaireResponse.subject_id == subject_id).filter( QuestionnaireResponse.document[ ('questionnaire', 'reference') - ].astext.endswith(questionnaire_name)).filter( - QuestionnaireResponse.questionnaire_bank_id == - questionnaire_bank_id).with_entities( + ].astext.endswith(questionnaire_name)).with_entities( QuestionnaireResponse.document[( 'identifier', 'value')]) + if questionnaire_name != 'irondemog_v3': + # Another special indefinite workaround. irondemog_v3 happens to live + # in multiple questionnaire banks, thus the lookup will fail when + # restricted by QB.id, should the org have transitioned since the user + # left work incomplete from the previous protocol (TN-2747) + qnr = qnr.filter(QuestionnaireResponse.questionnaire_bank_id == questionnaire_bank_id) + if iteration is not None: qnr = qnr.filter(QuestionnaireResponse.qb_iteration == iteration) else: