Reporting Bugs

Is it really a bug?

We appreciate your efforts to report a potential bug with OpenMRS. Before you do, please ask yourself the following:

• Am I running the latest version of OpenMRS?
  • If using an older version, is it still supported?
  • Check the Unsupported Releases (EOL) page to find out.
  • It is OK to report a bug in an older unsupported version, but it will not be fixed in that version. You will need to upgrade.
• Has the bug been reported already?
  • Search the various OpenMRS sites to see if anything similar has been reported or discussed in the past. You should also search for any specific error messages you are seeing, if applicable.

Reporting Security Issues

If the issue that you want to report is a security exploit, you should not publicly disclose the details, since that would tell attackers how to exploit OpenMRS production servers in the field. Report any security vulnerabilities to security@openmrs.org (a private list of long-time OpenMRS developers) giving details about the exploit, and someone will follow up via email.

File a bug report

If you know the problem is related to the function or performance of a specific add-on module you are running, please consult the Module Repository and that module's documentation about how to get support. If you believe the problem is with OpenMRS itself, or if you're honestly not sure, you can file the bug report in the OpenMRS Trunk project in JIRA. You'll need to have an OpenMRS ID to do so.

Regardless of whether you're reporting the bug to the OpenMRS core team or to a module developer, to help those developers understand the problem, please include as much information as possible:

1. A clear description of how to recreate the error, including any error messages shown.
2. The version of OpenMRS you are using.
3. The type and version of the database you are using, if known.
4. If you are using any additional modules, custom templates, stylesheets, or messages, please list them.
5. If applicable, please copy and paste the full Java stack trace.
6. If you have already communicated with a developer about this issue, please provide their name.

What happens next?

For OpenMRS bugs, our core development team will review your new bug report, attempt to verify it, and prioritize it. Once verified, they will be classified as "ready for work" at which point a developer can start working to resolve the issue. As the bug reporter, you will receive e-mail notifications from JIRA (unless you opt-out) with updates.

Once a developer has fixed the bug, it will be reviewed, tested, and included in an upcoming release of OpenMRS. You can follow the progress of the issue in the tracking system to determine what release fixes the bug.

How is priority determined?

We use the following definitions when prioritizing tickets:

1. Blocker
   Blockers are issues that must be addressed before the milestone (or possibly development) can proceed. Blockers may delay all other issues, and it is worth assigning multiple developers to a blocker issue to get it resolved as quickly as possible.
2. Must
   Critical issues must be addressed for their assigned milestone. Critical issues are those that have been attached to (and possibly help define) a particular milestone and the milestone should not proceed until they are addressed. If critical issues are falling behind, then we will direct resources to them as needed. Unresolved critical issues may delay a milestone.
3. Should
   Major issues should be addressed for their assigned milestone; however, if resources are not available, then the issue may get moved to another milestone instead of delaying the assigned milestone. Unresolved major issues typically will not delay a milestone.
4. Could
   Minor issues could be addressed for their assigned milestone, but only if resources permit. For major and minor releases of OpenMRS, we try to ensure that at least ten minor issues are being addressed if not many more. Unresolved minor issues will not delay a milestone.
5. Non-essential
   Trivial issues are generally only assigned to a milestone if someone has volunteered the resources to move them along. Unresolved trivial issues will not delay a milestone.
6. TBD
   To Be Determined issues have not yet been prioritized. This is the default prioritization for new issues until/unless the issue has been prioritized.