While working on endTB, we’ve discovered a bug within the Bacteriology functionality, specifically around deleting an existing sample. You are able to get in an invalid state where an obs group is partially voided (the obs group parent is voided, but some of it’s child obs are not voided). Because of this, end users can run into errors when attempting to enter or edit a bacteriology form.
An overview of how to reproduce:
Go to Enter Data->Bacteriology Tab
Enter a new specimen, setting “Date of Sample Collection”, “Type of sample”, and “Sample Id”.
Save the form-if you look in the database, you will see four observation created-one for each of the above 3 fields, plus one for the obs group.
Go back to the main patient dashboard, and the “General” tab
In the bacteriology results section, click on the pencil icon to edit the sample you just created
Zero out the “Date of Sample Collection” and “Sample ID”, and uncheck the “Type of Sample” (ie clear out all information on the form)
Save the form
If you check in the database now, you’ll see that the parent obs has been voided, but the “date of sample collection” and “Type of sample” have not been voided, and still have their existing values. The “Sample ID” has been voided correctly, but a new obs has been recreated with an empty value.
Correct behavior here would be not to allow the form to be saved without Date of Sample Collection and Type of Sample, since these are required fields. The issue is that there is no other way to delete a sample… there should be more straightforward way to do this (like an explicit delete sample button).
As for the issue with the Sample ID, it sounds like, in sense this is intended behavior-when you overwrite an existing value with an empty value, it creates a new obs with an empty value to reflect this-but in this case, since we are voiding the entire obs group, not sure if this is really necessary. (Having a separate way to just delete a specimen without having to “zero out” the fields would avoid having to address this entirely).
Thoughts? Is this on anyone’s radar or is anyone working on this?
We’d like to do a new endTB release with this fix in as soon as possible, so we’ve got a few options here… ideally we’d do the 1.1 release of bacteriology app, but at minimum we’d need this version of the 1.1-SNAPSHOT with the fix deployed to https://s3.amazonaws.com/endtb-artifacts/. What do you think the next steps should be?
Hi Mark,
Can you please discuss this with David Oh in the Dev Collaboration call or just drop in a mail. He would be able to collaborate with you on this.
Thank you.
Thanks @swathivarkala! Yes I contacted him as well and we are in communication now… I couldn’t @ him here because I don’t think he has a Talk account yet…
Just to follow up on this thread: we have removed the SNAPSHOT qualifier and published version 1.1 of the bacteriology module. Thanks @mogoodrich.
For the time being the bacteriology OMOD has been uploaded as a release artefact on GitHub. This enables us to download the OMOD in setup.yml and deploy the updated bacteriology module immediately without needing to wait for it to be incorporated into an updated Bahmni RPM.
Going forward, what is the Bahmni team’s preferred approach for hosting OMODs in scenarios such as this one? Hosting OMODs on GitHub is not an existing convention for Bahmni modules, I think only RPMs are hosted publicly (on Bintray).
Is publishing OMODs on GitHub a good idea? Or should individual Bahmni implementers take responsibility for hosting any artefacts they require outside of the official Bahmni RPMs?
My opinion is that Bahmni should move to host it’s artifacts in the OpenMRS Artifactory and Bintray repositories, which is what almost everyone else in the OpenMRS community does. This would also allow the new “Add-On Index” (replacement for the module repository) to expose these modules.
I would think we definitely want to publish the jars/sources to OpenMRS’s maven repo.
As to where the omod is deployed I don’t see anything wrong with using github releases. But since Bahmni already uses bintray for other things, I think starting to publish Bahmni-maintained omods into the bahmni Bintray account makes more sense.
Bintray has a mechanism to link an artifact in another account, e.g. so something could primarily be published to Bahmni’s bintray space, and then republished by OpenMRS so it appears natively there too. (@raff have we written any docs about this yet?)
(The new Add-On index will eventually be able to index modules that are released to GitHub releases, and we could prioritize implementing that feature if need be.)
