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:
Use Global Properties to turn features on and off
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:
https://github.com/PIH/openmrs-module-mirebalais/tree/master/api/src/main/resources/config
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