OpenMRS Preferred Patient Fix

Progress on the home front...
Our group has finally solved our bug. As described in my previous blogs, OpenMRS does not require that you have a preferred patient ID. Our patch now fixes that and requires that a user enters a preferred patient ID. Our fix required quite a bit of research on our parts to find how OpenMRS uses the SpringMVC framework for patient form validation. After finding out where OpenMRS had their validators placed we were able to go ahead and create a new validator and its entities in order to require that the user input a preferred patient identifier.


Plans for the future
now that we have fixed our bug we are thinking of creating a code repository, which we really didn't need before, in order to handle the changes within our group. Our next process for our bug fix is to post our patch for code review within the OpenMRS ticket system(JIRA). Right now our group has not decided on a contribution for the rest of the semester but we hope to have one chosen and a road map in place by the end of the week.

Bug Tracking OpenMRS using JIRA

Issue tracking is probably one of the most important aspects of open source software development. Evolution of open source software depends upon a community resolving problems.

OpenMRS is most certainly an open source project, and also has an issue tracker. OpenMRS uses JIRA to track all of it's issues. Issues include a bug, defect, task, improvement, incident, etc. JIRA does a great job of reporting, filtering, and designating issues. I found it very easy to navigate issue tickets and find some information that exercises in "Teaching Open Source" requested.

The oldest bug in OpenMRS:
TRUNK-330 is the oldest ticketed bug in OpenMRS that is still open. The bug is described as the following:

• audit trails for obs - can only change one attribute at a time.
• double data entry

Since I am just getting involved with the project it is hard to tell what the bug's domain and nature is. I hope to figure this out with time. My guess is that it hasn't been solved because the bug is probably insignificant to future development.

Creating a JIRA Account for OpenMRS
I was able to create a JIRA account for OpenMRS very easily and I am now ready to report or solve tickets within OpenMRS. Since our project will most likely involve fixing a minor bug, this is very important.

Reproducing a Bug
First I went into the JIRA issue tracker and picked the revision/version of OpenMRS that i have checked out:  Version 1.9.0 SNAPSHOT Build 18013.
I then searched for a bug that i felt was relatively easy to reproduce. The bug that I tried was known as TRUNK-222. The description of the bug is, "If a patient's first name is less than 3 letters, we cannot search for him without knowing his family or middle name". I thought that this would be an easy bug to reproduce so i went ahead trying.

First i went ahead and created a patient with a 2 letter name "Di":

I then proceeded to try and search for "Di" and could not produce any results, as expected.

Although this bug ticket was not well formatted, it was still easy to reproduce. Also, after reproducing it i think that this is not actually a bug but a design problem.


Bug Triage
Since I'm very new to the OpenMRS project bug triage would be very difficult at the moment. Instead, I'm just going to go through a few bugs on my own and share my thoughts on what bugs are more important than others, a part of the triage process. All of the bugs I'm going to mention are under the category from the JIRA ticket system on OpenMRS as being a "severity" of "3 or 4" (on a scale from 1-4).

Bugs:

1.  "JUnit tests fail if run independent of maven" - This bug is extremely bad. OpenMRS fails to pass the unit test's that are designed. This means that there could be an unforeseen amount of issues with the particular build (1.9.x)
2. "OpenMRS can not be installed with MS SQL Server" - This bug is also extremely bad considering some machines trying to implement the particular build could be running MS SQL Server.
3. "Change default logging levels of service methods" - This bug is import because it affects the logging of everything that happens in an OpenMRS deployment. Logging could be very important if you wanted to track information in a particular deployment of OpenMRS
4. "support names with more than 2 components when going to create patient page" - This bug is a little less important than the first 3, but still has a profound affect on any particular implementation of OpenMRS. This bug will cause the name of  a patient to display and appear to be incomplete.
5. initialsetup: OpenMRS logo text is not correct - This is a less important bug. This bug is simply a cosmetic item in a build that is very new. I think that this could be avoided until some of the tougher bugs are fixed.

This triage was simply an exercise and I hope to learn more about OpenMRS so that my triage can evolve and become better.


Conclusion:
All of these exercises were very helpful for me. They forced me into exploring deeper in to the project that I am working on. I hope to learn more and be able to contribute to OpenMRS.