AppFramework: Custom template ends up supporting all encounter types (instead of just a single one)

Development
1

Hi @darius,

Could you shed some light here. In VDUI we are hooking one more extension to the existing "org.openmrs.referenceapplication.encounterTemplate" extension point like this:

{
 "id": "visitdocumentsui.encounterTemplate",
 "extensionPointId": "org.openmrs.referenceapplication.encounterTemplate",
 "type": "fragment",
 "extensionParams": {
  "templateId": "complexObsEncounterTemplate",
  "templateFragmentProviderName": "visitdocumentsui",
  "templateFragmentId": "complexObsEncounterTemplate",
  "supportedEncounterTypes": {
   "5021b1a1-e7f6-44b4-ba02-da2f2bcf8718": {
    "icon": "icon-paper-clip",
    "deletable": "false"
   }
  }
 }
}

Everything behaves nicely when we add VDUI on top of the Ref App. However after installing XForms (see this other thread from here), things get screwed. At first I thought that XForms was changing something but in fact it just suddenly triggers the actual display of what the App Framework really makes out of the above extension configuration. This is what I get out of my debugger for the above extension at runtime:

{  
 templateId=complexObsEncounterTemplate,
 templateFragmentProviderName=visitdocumentsui,
 templateFragmentId=complexObsEncounterTemplate,
 supportedEncounterTypes = {  
  5021b1a1-e7f6-44b4-ba02-da2f2bcf8718 = {
   icon=icon-paper-clip,
   deletable=false
  },
  e22e39fd-7db2-45e7-80f1-60fa0d5a4378 = {
   icon=icon-file-alt,
   editable=true
  },
  10c20ebf-1af2-4ddf-bdaa-219fe8ff930b = {
   icon=icon-file-alt,
   editable=true
  },
  49e7bc6c-bfbd-40dc-8164-45d82c55b5f9 = {
   icon=icon-file-alt,
   editable=true
  },
  ...
 }
}

Basically all encounter types are marked as being supported by the template. Would you have any idea why the App Framework associates all the other encounter types to visitdocumentsui/complexObsEncounterTemplate despite the above configuration that only intents to associate one (and only one) encounter type with it?

I really can’t spend more time on this now, I was hoping that you would know something from the top of your head.

Perhaps could you help @hpardess find his route to troubleshooting this and get a PR together if there is indeed a fix in sight? Or if the issue lies in VDUI, let us know how to have our custom template support one and only one encounter type.

Thanks in advance.

2

Thanks @mksd for the debug details. They were enough to show me that the problem came from the xforms module. @hpardess can you use the current snapshot version of the xforms module to check if it fixes the problem in your local installation?

1 Like
3

Thank you @mksd and @dkayiwa. The overlap between XForm and VDUI modules are fixed now with XForm v4.3.12