Synopsis

Need 2.0 to look generic, but much of the UI and code is country specific. The stop-gap solution for 2.0 is to implement a feature toggle mechanism, where a property would be set during build time to toggle on or off the country-specific code. The property setting is in the gradle.properties file, called toggleOnCustom.

This toggle setting is set for all custom code, not for each country-specific project. So there is no toggleOnVIMS, toggleOnJSI, toggleOnMoz, etc.

The actual toggling functionality will use the existing permissions framework to toggle features on or off. Most of the UI is hidden or shown based on if the current logged in user has permission to see it. So toggling will be done by not allowing any users to have certain country-specific permissions. This is enforced by REMOVING the definitions of country-specific permissions (the rights table) at build time. The gradle build simply calls or does not call certain SQL scripts to remove (or re-add) those permission definitions to the system. The country-specific permission definitions are always removed during the build–if custom code is toggled on, then they are re-added.

With the removal of permission definitions, certain parts of the system are now hidden or changed.

UI

API/Backend

Very little has been changed on the API and backend, as it would take some research to determine what code is country-specific, and APIs that are not published are not supported. Generally the 2.0 stabilization effort is focused on the UI client.

Work TODO DONE

This work has not been done yet, as these features were added by a third party, but permissions were not fully implemented. This work will need to be done for the 2.0 release.

Adding Features to Toggle

See the docs/Feature Toggle.md file in the code to understand feature toggling in more detail and how to extend it.