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.
That is awesome!
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?
Is that in a unit test?
No, it’s getting invoked from an HTML form.
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?
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
@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
I have created a new PR, could you please review?
@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
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
In my instance, this statement returned null, so will need to troubleshoot further:
@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?
Reviewed and merged.