O3: Address Hierarchy widget plan

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.

I discussed with @dkayiwa, @samuel34, @dagimm, @eudson, & @mayanja, and here’s our plan:

  • 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?)

Requirements Wiki page: 3.x Address Hierarchy Widget - Projects - OpenMRS Wiki

Does anyone have any feedback, thoughts or concerns?

2 Likes

Ps we will try using initializer to import the metadata for /addresshierarchy

@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.

1 Like

Update: Here’s our Requirements Wiki page: 3.x Address Hierarchy Widget - Projects - OpenMRS Wiki

Current design vision is something like this:

@mksd this comment was actually so helpful because we couldn’t figure out why the ICAP team’s previous attempts to use Iniz to support Address Hierarchy weren’t working! I kept searching the Iniz ReadMe for any additional documentation re. /addresshierarchy. I’ll add a blurb about this there now. :wink: → Done: Added explainer for Address Hierarchy by gracepotma · Pull Request #188 · mekomsolutions/openmrs-module-initializer · GitHub

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).

1 Like