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.
@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
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.
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.
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.
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%"