Migrating emrapi module from GlobalProperties to metadata mappings

Hi @mogoodrich, I have a couple of questions. I assume that the metadata mapping module doesn’t have a UI using which the properties can be changed. If a site wants to change these properties going forward, what is the way? Will it always use metadata deploy?

Also, just curious to know when you are planning to complete the changes. We are almost at the end of a release - planning to release in 2 weeks. We are thinking if you can move this work to the next release. But we need 1.20 to be released as there is one defect as part of it.

If so, we can release emrapi 1.20 now and also revert this commit and move it to the next release. We are thinking of medium term fix instead of a short term hack and we are buying more time by reverting this and making it part of next release.

What do you think?

@mogoodrich, I don’t see any issues with assigning and storing a UUID of the set.

It seems we missed to add retireMetadataSetMember to the service. You can still do this by calling setRetired on the member and saving it. I wanted to enforce retiring instead of deleting as it is easier to track changes that way and move metadata around between servers. It is also to make sure that if anything relied on that particular set member it is still there, but can be reported as retired.

@bharatak, there’s a UI built as OWA. Please see http://int02.openmrs.org:8080/openmrs/owa/metadatamapping/index.html#/ (can be accessed from home page -> configure metadata -> manage mappings) We’re very much interested in doing a proof of concept of incorporating it in Bahmni UI by overwriting UI elements like header to fit in Bahmni. It is to open a way for more OWAs to be used by Bahmni and of course Bahmni writing OWAs. Let me know if you think it is feasible.

I’m fine with doing 1.20 release in a way that doesn’t interfere with other devs like @mogoodrich, who are already picking up the 1.20-SNAPSHOT. You could do the release either from a branch or a master. In the latter approach you should do revert, release, reapply within hours to prevent blocking anyone from committing to master.

@raff, We’ll definitely try it out. Its a good idea to see how it looks with Bahmni.

For the 1.20 release, we prefer to quickly revert the commit and do a release on the master. We will ensure that all of this happens in less than 30 mins. I hope this is fine. Also, we will add the commit back on the master i.e. 1.21-SNAPSHOT

We released 1.20 and the commit is available on master (1.21-SNAPSHOT).

Meanwhile in Bahmni, we will work on fixing the global properties as part of the next release. Thank you all for the support.

1 Like

This should work for me… I’ve made very few changes in EMR API anyway, it’s mainly new additions to Metadata Deploy. I hope to push up my changes by the end of the week.

Take care, Mark

Just a quick update/note that I’ve started a related thread here:

I’ve actually put on hold my work for adding support to metadata deploy to set up metadata mappings, because after chatting with @darius and @mseaton I was thinking it was a bit overkill, and rather the metadata mapping module itself should provide utility methods for setting/updating a mapping… see my comments on the other thread.

Thanks! Mark

Just brining this back up, we are running into alot of errors in UgandaEMR due to the fact that the global properties are not longer accessible from emrapi. The first one was emr.primaryIdentifier and now emr.atFacilityVisitType.

Is there a concrete list of GPs that have been migrated so that we can make a change across all of them rather than run into the issues one at a time.

cc @carapai

Just translate the ones you override to metadata mappings. The ones you do not touch are automatically taken care of.

When you upgrade, all migrated GPs will have the value of “This global property had been migrated…” so this SQL should list you all migrated properties: select property from global_property where property_value like "This global property had been migrated%"

@raff How do I upgrade? since I do not see any of the GPs migrated in my test database

By upgrade I mean if you used RA 2.5 (or older) and upgraded it to RA 2.6.

@raff Yes we are upgrading to use the RA 2.6 modules, does this include reference-application & reference-metadata 2.6 also?

@dkayiwa @raff

I have upgraded reference-application, reference-metadata and provider management versions to 2.6.0.

So now my module starts and I see the metadata mappings in the metatada_term_mapping table though no global properties are migrated.

When I go to create a past visit I get this error which also breaks the patient dashboard https://gist.github.com/ssmusoke/48554b6faf5665b71d861ea1b7beeec1 despite the visit being created

Which version of the serialization.xstream module are you using?

@dkayiwa Finally got it to work. Now a question, how does one access the mappings on the UI since this OWA seems to be broken https://qa-refapp.openmrs.org/openmrs/owa/metadatamapping/index.html

@raff I found that emr.primaryIdentifier and emr.extraPatientIdentifierTypes were moved to the metadatamapping term table but the GPs were not moved.

Could you please clarify a bit more? Do you mean there are some places in code where we still rely on GPs and not metadatamapping terms?

@raff

  1. I did not see the migration message in the GP so was wondering what is up.

  2. I am unable to see what values the mappings have since this page https://qa-refapp.openmrs.org/openmrs/owa/metadatamapping/index.html is broken

@raff do you have any idea why https://qa-refapp.openmrs.org/openmrs/owa/metadatamapping/index.html is not working?

It must be some issue in the OWA module. I’ll look into that.