Feature/import data pdp
Fixes #261 (closed), #203 (closed), #254 (closed)
Also important commit that must be merged (or at least cherry picked) since it fixes and error on the Voucher Tables: 5e979b18
I think it's done unless we need to make more changes to the data itself, like, adding the flags etc. Which we can do on the website instead of using the program, unless we want a more general program for importing information. Right now I would consider the program basically ad-hoc for this specific case. Since some information must be hardcoded like the VouchersTypes or the format of the Voucher References to get the issue date and voucher type.
Added excluded property to studySubject model. Regarding this, I saw a comment which says: "Marking a subject resigned or deceased cannot be undone.". Why not? and, should resigned option have the same behaviour?
Merge request reports
Activity
added 1 commit
- 45c9f15c - added signals to Subject and StudySubjet. These signals fire after an instance…
I just added a commit for issue #203 (closed) adding signals to Subject and StudySubject models. These signals fire after an instance is saved (
post_savebut could also bepre_save) and check if the subject is excluded, resigned or dead and then call the methods that finish all the appointments and visits. I think is safer than doing it on the forms or other parts of the code.I guess it could be useful to clean up the other places where the methods mark_as_resigned, mark_as_excluded and mark_as_deceased are called since these signals replace that behaviour.
Regarding your comment. Signals could have some side effects please check this "bug": #195 (closed). It shouldn't happen in this case though.
assigned to @piotr.gawron
-
Added default location. Some fields from studySubject not added during the import:
datetime_contact_reminder screening_number mpower_id referral_letter health_partner_feedback_agreement screening diagnosis year_of_diagnosis information_sent pd_in_familyEdited by Carlos Vega -
Added excluded property to studySubject model. Regarding this, I saw a comment which says: "Marking a subject resigned or deceased cannot be undone.". Why not? and, should resigned option have the same behaviour?
In the long run it should be possible to undo it, but the problem that I was facing at the time is that when subject is marked as deceased/resigned visit are closed and appointments are canceled. And the thing is that after returning subject to life we should probably restore appointments visits. However those appointments visit might be in the past or might not be valid anymore ...
-
I see. I vote for removing the visits or mark them as closed so they should add a new visit etc. It's costly for the user but a frequent use case that the subject is excluded/resigned and comes back. Not to say if it's dead...
Should I change the signal syntax from
post_save.connect(set_as_deceased, sender=Subject)to@receiver(post_save, sender=Subject)? I think it's more intuitive and clean. And is how the visit signal is done.Regarding your comment. Signals could have some side effects please check this "bug": #195 (closed). It shouldn't happen in this case though.
Regarding the visit signal, I think the signal could check if there are any previous visits and resort the
visit numberreplacing the number so that they are sort in chronological order. BTW, what is thisvisit numberused for? added 1 commit
- 1cbd6cb5 - WIP. Trying some clean ops before install with apt-get to avoid unauthenticated errors
added 1 commit
- e1660436 - WIP. Added --allow-unauthenticated apt-get to avoid unauthenticated errors
mentioned in commit c566f950