EncounterDiagnosesElement.java contains hard-coded encounter type

Development
21

Cool, sorry, it look me a while to get there @dkayiwa… I ticketed what I think the long-term/ideal solution would be, but what we have should be fine for now.

1 Like
22

That is awesome! :slight_smile:

23

Thanks @dkayiwa, @mogoodrich for troubleshooting this!

24

Hi @dkayiwa, @mogoodrich, coreapps now has two versions of EncounterDiagnosisElement.java:

My local 2.2.0-SNAPSHOT version of OpenMRS is still invoking the pre2.2 version. How do I change this, and should the 2.2 dependency be added to the openmrs-module-coreapps/api/pom.xml file?

Thanks, Dominic

25

Is that in a unit test?

26

No, it’s getting invoked from an HTML form.

27

Correction: it actually looks like the 2.2 version is being invoked, IntelliJ debugging was bringing up the pre2.2 code by mistake.

But my questions still are: how does the html form know when to use the 2.2 version of EncounterDiagnosesElement.java, and should the api/pom.xml file be updated?

28

@dsurrao I’m not sure how this works, @dkayiwa may be able to weigh in, but I think there’s commom setup/pattern in our module structure for this.

Things do appear to be working, correct? Assumedly the pre-2.2 one is correctly getting picked up in a pre 2.2 environment, because the PIH EMR would crash when trying to save a consult otherwise.

Take care, Mark

29

@dsurrao this is what determines which resource is loaded: https://github.com/openmrs/openmrs-module-coreapps/blob/master/omod/src/main/resources/config.xml#L57-L65

30

Thanks @dkayiwa!

31

@dkayiwa, @mogoodrich, I removed the seemingly redundant code that set encounter type, and was able to save diagnoses on new encounters. The form we use is here.

I have created a new PR, could you please review?

32

@dsurrao i actually set the encounter type to fix the NPE that i was getting. So removing it will lead to the exact problem when running on platform 2.2

33

Yes, we do need to manually set the encounter type, it seemed redundant but upon further examination it wasn’t… see my post above from Oct 16th…

Take care, Mark

34

Noted, @dkayiwa, @mogoodrich.

In my instance, this statement returned null, so will need to troubleshoot further:

formEntrySession.getForm().getEncounterType()
35

@mogoodrich I’ve created a new PR which sets the encounter type only if it isn’t already. This will fix both the null encounter type exception I am getting above, and Daniel’s.

@dkayiwa could you please give this version a try?

36

Reviewed and merged.

37

Thanks @dkayiwa!