New features include configurable contact hierarchies, a new default configuration, optimized form HTML generation and server-side purging. We’ve also implemented loads of other improvements and fixed a heap of bugs.
With the release of v3.7.0, users now have the ability to configure information hierarchies
This feature was created to respond to the variability in project information management needs. Large deployment sites often need three or more levels of information hierarchy, while some small sites need fewer than three levels.
A user logging into their app will see a custom set of people, tasks, reports, and analytics based on the hierarchy level that they belong to. This allows appropriate data sharing based on the role of the user in the health system.
For anyone who is new to reading the Core Framework release notes, I wanted to share some context on how to interpret the loooong list of bug fixes–56 bug fixes in this release alone. Some of these were real live bugs, and health workers will have a better experience once the technical teams supporting them upgrade to 3.7. On the other hand, many of the bugs in this list have never been encountered in a real live deployment. That may sound counter-intuitive, but there’s a good reason for it if you understand the release process.
When a Core Framework developer adds a new feature (1 in this release), improvement (18 in this release), performance fix (11 in this release), or addresses another technical issue (14 in this release), these changes to the code base sometimes unintentionally break something else. As this blog post on testing at Medic Mobile explains, there’s technical infrastructure and a bunch of organizational practices in place to catch these accidental problems, which are called regressions. When a new regression is identified, we create a new issue to describe it, label it as a bug, and make sure someone fixes it before the new code is ever released.
What does this all mean for the user experience? Basically, it would be a mistake to look at a long list of bugs in the release notes, and conclude that so far health workers were experiencing all of these bugs. In practice, we are catching and fixing some real live bugs with each new release. But more often, a long list of bug fixes is an indicator that we’re making significant changes to the code base, and that the testing process is thorough enough to catch issues before they ever make it into production.
