Details
-
Type:
Bug
-
Status: Ready for Work
-
Priority:
Should
-
Resolution: Unresolved
-
Affects Version/s: Platform 2.4.0
-
Fix Version/s: None
-
Component/s: None
-
Labels:
-
Complexity:Undetermined
-
Development:
Description
In 2.3.x and 2.4.x, updating a Patient no longer sets the "dateChanged" property of a Patient, thought it does still update the Person dateChanged.
This appears to have been caused by TRUNK-5492.
This likely exposes a problem with our modelling of Person and Patient, and our hacky workaround to make Person and Patient maintain separate dateChanged states.
This test, which passes in 2.2.x but fails in 2.3.x and 2.4.x, demostrates the issue:
@Test public void updatedPatientShouldUpdatePatientDateChanged() throws Exception { Calendar cal = Calendar.getInstance(); cal.set(Calendar.HOUR, 0); cal.set(Calendar.MINUTE, 0); cal.set(Calendar.SECOND, 0); cal.set(Calendar.MILLISECOND, 0); Date today = cal.getTime(); Patient patient6 = patientService.getPatient(6); patient6.setAllergyStatus(Allergies.NO_KNOWN_ALLERGIES); patientService.savePatient(patient6); Context.flushSession(); Context.clearSession(); Patient updatedPatient6 = patientService.getPatient(6); assertTrue(updatedPatient6.getPersonDateChanged().after(today) || updatedPatient6.getPersonDateChanged().equals(today)); // the following assertion will fails against Core 2.3.x and 2.4.x assertTrue(updatedPatient6.getDateChanged().after(today) || updatedPatient6.getDateChanged().equals(today)); }
One solution may be to remove the auditable fields that are duplicated on both Patient and Person, and remove the ability to distinguish between a "Person" and a "Patient" when it comes to auditing.
Thoughts Daniel Kayiwa Burke Mamlin Mike Seaton?