Feature Toggles in OpenMRS - Enabling and Disabling Features

I am looking for the best practice to be able to implement and use feature toggles within an OpenMRS implementation, to transparently enable features depending on users. I am thinking:

  1. Use Global Properties to turn features on and off

  2. Use a custom module which when turned on makes the functionality available to the implementation

Any pros and cons? or an alternative option

Please consider making it a part of the Initializer module. See https://github.com/mekomsolutions/openmrs-module-initializer/blob/dev/README.md

@raff the configuration would be loaded at once into the core implementation but looking for ways to turn the features on or off… Like multi-location support, identifiers, form elements and sections etc

In the PIH-EMR we use two different methods to enable/disable features based on implementation, Feature Toggles and Components.

Feature Toggles are (generally) able to turned on/off “hot” and are used when rolling out new functionality–ie, to allow us to commit half-complete functionality to the code base, and/or to enable only on a demo server before rolling out to a production server. The main point here is that feature toggles are allowed to be “hacky” and are supposed to short-lived–once a feature is complete it will be removed. (Just for terminology, I think this is generally what a “Feature Toggle” means in industry).

Components are what we use to turn off/on different components in our implementations. They are defined as part of a “Config” functionality we built for the PIH-EMR. Generally, they are not hot-swappable and programmactically add AppFramework apps and/or extensions during start-up.

Feature Toggle support is built into the App Framework module:

Example usage can be found here:

Our PIH config functionality is implemented in our PIH Core module:

Some example configs can be fonud in our Mirebalais module here:


And you can see how the Config is used to enable components here. (Ideally, this design would be imported to be less “if/then”, but it’s worked fine for us for a few years now):

Take a look–if any of this looks interesting to you, I’d be happy to help assess migrating some of the generalizable components to a non-PIH-specific module (I haven’t looked at the initializer module that @raff mentions but it could be a possible location).

Take care, Mark

Also, note that all this functionality is designed for enabling/disabling component depending on implementation instance–if you are talking about enabling/disabling features within a single instance based on context (location, user role, etc) we have another means to do that.

Take care, Mark