So this week with the #ethiohri team (inc. @ICAPEthiopia & @UCSF), we need to create a solution for address hierarchy in 3.x. Specifically, the need is for a UI that could be inserted pretty much anywhere (though mostly in forms) to help the user specify regional specifics in cascading order of specifics. And, the labels are also specific - ET is divided into Regions, then Zones or Sub-Cities, and then Woredas.
To leverage the existing backend provided by the Address Hierarchy Module
To build this feature as an esm-app
That esm-app should be embeddable within any form. Should be able to be engine agnostic (ie. could be using the Ampath form engine or OHRI form engine). @samuel34 knows a way that the schema should be able to declare a widget within the form. (Samuel can you remind me how this is done?)
@grace it turns out that it’s not Iniz but the AH module itself that loads the content of configuration/addresshierarchy.
A bit as oddity today, but at the time (2017) @mseaton and I were pondering the idea that each module would take care of its own metadata… this was never migrated to Iniz and remained in the AH module.
This is a great idea! However, the third point here is actually pushing us to a place where we should start to make real technical decisions around both the form schema and the form engine before things diverge too far. Ideally, instead of trying to build some custom widget that can work in any form engine, we should come to an agreement on a form engine. (Any custom widget like this will likely require per-form-engine extensions to ensure it’s plugged into the form engine in a way that the form engine can understand the input into the component and correctly translate it into whatever underlying representation is necessary).
Really nice recent work on this PR by @sinte - so awesome to have this progressing and this will be leveraged by so many teams world-wide.
However changing the structure of the XML template file caused a highly impactful breaking change to all other O3 teams using the registration page. But what’s great is this helpfully exposed an API gap we had overlooked.
No. The changes were in the rest webservises module, which we can release with a click of a button on bamboo. But even before the module is released, there is nothing that prevents a developer from leveraging the new API, because it is already available at: https://dev3.openmrs.org/openmrs/ws/rest/v1/addresstemplate
Thanks Dagim! (especially since I think you submitted this while on leave yourself!)
@mksrom what’s the priority? I believe the org with the most urgency around the breakage the PR caused is Mekom. If the priority is urgent, perhaps someone at Mekom could tweak/patch that original PR work to leverage this new API endpoint?
So, at this point the O3 patient registration address is broken, so it needs to be fixed asap.
There are 2 underlying issues:
The address template was not used properly (thus the need to provide a real endpoint for this so that devs don’t misuse the address template in the future)
The commits made have removed support for non-Address Hierarchy-enabled implementations. Since many implementations are not using AH it was a mistake to merge code that breaks the standard/base address entry. AH support should be made configurable.
What we must do now is to revert/disable the current AH support and let devs fix the code and make it configurable. @ibacher had mentioned he’ll be able to do that.
→ Done: 
Wow Daniel, A+++ for turnaround time, seriously!! 