Through OpenMRS 1.9, the user interface for OpenMRS got little attention. The majority of the user interface comprised administrative functions and a tabbed patient dashboard. As of OpenMRS 2.0, a new and more contemporary UI was introduced via a UI framework and the legacy UI was kept around for administrative functions that were not yet implemented in the new UI. While we plan to retire the legacy UI by the end of the summer 2015, there are many implementations and modules that still rely on it. In order to maintain backwards compatibility, we want to move the legacy UI functions into a module that these implementations can install until they are able to migrate away from it. Since most of the implementations of OpenMRS around the world are running OpenMRS 1.9, there will be dozens (if not hundreds) of implementations around the world thankful for this module.
If you visit demo.openmrs.org (username: admin, password: Admin123):
These pages (legacy patient dashboard, patient search, dictionary, reporting, and administration) and the extension hooks they provided represent the majority of OpenMRS' legacy UI. Looking under the hood, you would find that several of these (patient dashboard, dictionary management, and reporting) are already hooking into a legacy home page that provides the basic structure used by all of these pages and is hidden (replaced with the new home page) in OpenMRS 2.0+. Creating a module that includes the legacy home page structure and supports the legacy approach to web page extension points will be the bulk of the work involved in this project. Once that is achieved, then you should be able to migrate most of the code for the legacy UI into it without making major changes to the code.
JIRA project alloted here.
- Good Java skills
- Familiarity with J2EE web programming (e.g., JSPs)
- Familiarity with Spring Framework will help
- Identify the key components of the legacy UI (e.g., administrative functions and patient dashboard) as listed above, including the technical requirements (e.g., legacy approach to web and module extension points).
- Migrate these features into a Legacy UI Module.
- Allow modules written for OpenMRS 1.9 to be installed into OpenMRS 2.2+ by installing your module into OpenMRS 2.2+ to provide the hooks and UI features expected in OpenMRS 1.9.
- Provide an app (or apps) within OpenMRS 2.2+ to serve as entry points into the legacy modules – i.e., if someone made a whirligig module for OpenMRS 1.9, give them an easy way to expose that legacy module as an app within OpenMRS 2.2.
- Demonstrate the most popular legacy modules running within OpenMRS 2.2.