Update Consent Documents #615
Conversation
Merge Master in to Working Branch
AmandaBirmingham
left a comment
AmandaBirmingham
left a comment
There was a problem hiding this comment.
By the way, I called the number given for Rob and found that when it picks up, there's no indication of whom you reached nor any voicemail instructions--it just immediately beeps, which I assume means "start your message", but who knows ... However, I suspect setting up the voicemail is low priority :)
| @@ -0,0 +1,79 @@ | |||
| -- This update to the consent documents serves three purposes: | |||
| -- 1) Update the contaxt information in all consent documents. | |||
There was a problem hiding this comment.
I believe there is a typo: "contaxt" for "contact"?
There was a problem hiding this comment.
Thanks for catching that, fixed.
|
|
||
| -- First, we'll create a new version of the documents that are a clone of the last version (v2, created in database patch 0147.sql) | ||
| INSERT INTO ag.consent_documents (consent_type, locale, date_time, consent_content, reconsent_required, account_id, version) | ||
| SELECT consent_type, locale, NOW(), consent_content, 'true', account_id, 48 |
There was a problem hiding this comment.
So am I correct in understanding that 48 is the version of the IRB protocol, and that is why we are jumping from 2 to 48 instead of 3?
There was a problem hiding this comment.
Correct. When we set up the versioning system in the database, I was not aware that the IRB maintained version numbers for each set of amendments, nor that we should be showing the IRB version on the document that the participant sees. While it's not strictly necessary for our internal version to match, I think it will minimize future confusion to make the jump now and maintain parity going forward.
| SET consent_content = REPLACE( | ||
| consent_content, | ||
| 'If you have questions or research-related problems, you may reach us by emailing our help account [email protected] or Rob Knight at 858-246-1184.', | ||
| 'If you have questions or research-related problems, you may contact:<ul><li>Rob Knight at 858-246-1184 or</li><li>The research team (phone: 858-246-3234, email: [email protected])</li></ul>' |
There was a problem hiding this comment.
I am not going to request this as a change, but I do want to ask it as a question: if there are future cases like this, would you consider assigning the new text to a SQL variable so that it isn't typed out (or I assume pasted) multiple times, especially for the spanish versions (where in this case all four cases appear to be the same text)? I realize this patch is a one-time fix, so one can definitely argue it wouldn't be worth it, but I've developed a special horror of text that is supposed to be identical being defined in multiple places. If it were me, I'd probably even do the same with the new version number.
There was a problem hiding this comment.
Absolutely, I agree that would be cleaner approach and will use that going forward for similar database patches where we're using the same string multiple times.
|
Commenting for visibility: Automated workflow broke for reasons entirely unrelated to the contents of this PR (updates to pip are incompatible with our existing code base). I'm pinning the version of pip and wrapping it into this PR for the sake of expediency. It has no impact on our production environment, and this choice - pinning the package version and deferring on any major changes - is in line with guidance from project leadership. |
There are three items in this database patch: