Link previous mammograms to appointment instead of participant#875
Link previous mammograms to appointment instead of participant#875
Conversation
swebberuk
force-pushed
the
DTOSS-11959-appointment-mammogram
branch
3 times, most recently
from
f67dfdd to
23aaf10
Compare
swebberuk
changed the title
|
SonarQube reports duplicated code in Do we want to find a way to avoid these warnings, or instead is there a way we can ignore them for this PR? |
| from manage_breast_screening.core.views.generic import ( | ||
| AddWithAuditView, | ||
| DeleteWithAuditView, | ||
| UpdateWithAuditView, |
There was a problem hiding this comment.
Could rename this file to appointment_reported_mammogram_views.py, and also rename test_participant_reported_mammogram_views.py to test_appointment_reported_mammogram_views.py.
Didn't want to do that yet in case the renaming confused merges and code reviews, as same files have also been altered for "appointments can't proceed if previous mammogram is within 6 months".
There was a problem hiding this comment.
Not an issue if we keep the name the same 🙂
I think we should ignore all tests and all migrations. Do you want to add it the "Duplication exclusions" in general settings? |
| @pytest.fixture | ||
| def reported_earlier(self): | ||
| return ParticipantReportedMammogram( | ||
| return AppointmentReportedMammogram( |
There was a problem hiding this comment.
Sorry to be annoying, but can we keep the name as it was?
The name was originally meant to distinguish from confirmed mammograms. Even though we're now storing the appointment it was reported in, it's still the participant that reported it, and that's significant because details might be missing or inaccurate when the participant can't recall
There was a problem hiding this comment.
Okay, no problem.
Now keeping participants_participantreportedmammogram table, rather than replacing it with participants_appointmentreportedmammogram. Class names remain unchanged.
Replaced participant_id column with appointment_id column in participants_participantreportedmammogram.
There was a problem hiding this comment.
Yeah - and we let users edit and update reported mammograms, but we probably don't want to let updates happen to confirmed mammograms.
| migrations.AddField( | ||
| model_name='participantreportedmammogram', | ||
| name='appointment', | ||
| field=models.ForeignKey(default='e0a973c8-8630-4cf2-9313-333da3f3c590', on_delete=django.db.models.deletion.PROTECT, related_name='reported_mammograms', to='participants.appointment'), |
There was a problem hiding this comment.
Had to specify a default value in migration script for new appointment_id column, as is not-nullable. Used randomly generated UUID. Hoping this is okay, as don't yet have live data that we need to manage the migration of.
There was a problem hiding this comment.
The other way to do it is add it as nullable, then have a RunSQL to populate it, then make it non nullable.
Don't mind skipping that for now though. Ideally I want to squash or recreate the old migrations at some point prior to go live.
| migrations.AddField( | ||
| model_name='participantreportedmammogram', | ||
| name='appointment', | ||
| field=models.ForeignKey(default='e0a973c8-8630-4cf2-9313-333da3f3c590', on_delete=django.db.models.deletion.PROTECT, related_name='reported_mammograms', to='participants.appointment'), |
There was a problem hiding this comment.
The other way to do it is add it as nullable, then have a RunSQL to populate it, then make it non nullable.
Don't mind skipping that for now though. Ideally I want to squash or recreate the old migrations at some point prior to go live.
swebberuk
force-pushed
the
DTOSS-11959-appointment-mammogram
branch
2 times, most recently
from
9a0b8f9 to
69ba361
Compare
Replaced participant_id with appointment_id in participants_participantreportedmammogram Moved previous_mammograms from participant to appointment for seed_demo_data
swebberuk
force-pushed
the
DTOSS-11959-appointment-mammogram
branch
from
69ba361 to
dae7507
Compare
|
3 participants
Description
Details of previous mammograms are currently linked directly to a participant. Details are stored in
participants_participantreportedmammogram, which has aparticipant_idcolumn.This ticket links previous mammograms to an appointment.
Replaced
participant_idcolumn withappointment_idcolumn inparticipants_participantreportedmammogram.Updates seed data
.yamlfiles to moveprevious_mammogramsfromparticipanttoappointment.Jira link
https://nhsd-jira.digital.nhs.uk/browse/DTOSS-11959
Review notes
Review checklist