Skip to content
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

IRONN-210 allow for change of withdrawal dates #4343

Merged
merged 1 commit into from
Oct 9, 2023

Conversation

pbugni
Copy link
Collaborator

@pbugni pbugni commented Oct 6, 2023

This change allows for an update to an existing withdrawn consent. Previously, a 404 was generated if the user didn't have a valid matching consent when a withdrawal was requested.

It is required that the requested withdrawal date is:

  • greater than the last valid consent for the research study
  • less than 1 day in the future (to allow for any timezone details)

@pep8speaks
Copy link

Hello @pbugni! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

Line 879:80: E501 line too long (85 > 79 characters)
Line 883:80: E501 line too long (95 > 79 characters)

@pbugni pbugni requested a review from mcjustin October 6, 2023 20:10
@pbugni
Copy link
Collaborator Author

pbugni commented Oct 6, 2023

grr, the select for review didn't go through last night, sorry 'bout that.

@pbugni pbugni merged commit 21336dd into develop Oct 9, 2023
3 checks passed
@pbugni pbugni deleted the feature/consent-withdrawal-adjustment branch October 9, 2023 20:47
pbugni added a commit that referenced this pull request Oct 16, 2023
to an int.  This worked fine in SQL queries, but the change introduced
in PR #4343 requires an int to match research studies in looking for old
consents.
pbugni added a commit that referenced this pull request Oct 16, 2023
The withdrawal API (at /api/user/<id>/consent/withdraw) didn't cast
incoming JSON `research_study_id` value to an int. This had previously
worked fine in SQL queries, but the change introduced in PR #4343
requires an int to match research studies in looking for old consents.
pbugni added a commit that referenced this pull request Jan 23, 2024
…#4356)

When an exception is raised from any code during the use of a
TimeoutLock, it propagates to the `TimeoutLock.__exit__()` method, which
must catch and disband the exception, less it'll remain in a potential
deadlock state.

But, the code attempting to log the exception text was incorrectly
accessing the attributes from the stack. This PR corrects to generate a
stack in the log file, and move on.

This is an old issue, and has been hiding errors raised behind
TimeoutLocks from the log files for some time. Is also probably the
reason celery will occasionally behave as if it's in a locked state.

Finally found a reproduction (while working on #4343 regression issues),
and found a solution!

I should add, the code in our system protected by TimeoutLocks is
SIGNIFICANT - most all questionnaire bank work, building
OrganizationTree in memory, EMPRO state manipulation, Adherence Reports,
etc.
pbugni added a commit that referenced this pull request Mar 6, 2024
reverts bug introduced by
#4343 , which incorrectly
started using the oldest (not most recent) user_consent as last valid
consent prior to withdrawal.

includes migration to clean up problem cases. required careful
re-assessment of consent/withdrawal dates for a number of patients found
to have qb_timeline revisions after applying patch above. see
https://movember.atlassian.net/browse/IRONN-210 for more detail.

NB: #4363 merges into this branch, to be done prior to merging this PR.

---------

Co-authored-by: Justin McReynolds <mcjustin@uw.edu>
Co-authored-by: Ivan Cvitkovic <ivanc@uw.edu>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants