Visit Documents UI module (VDUI) v1.1 throws NullPointerException, also failed to attach a document to a finished visit

@mksd, @mksrom: I have downloaded the VDUI v1.1 but i get error while i open the clinical note of a visit.

[WARNING] org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.NullPointerException at org.springframework.web.servlet.FrameworkServlet.processRequest( at org.springframework.web.servlet.FrameworkServlet.doGet( at javax.servlet.http.HttpServlet.service( . . . Caused by: java.lang.NullPointerException at org.openmrs.module.visitdocumentsui.obs.ValueComplex.(

Also, I can not add a document to an old visit.

Regards, HPardess

Hi @hpardess,

I would need the full stack trace to understand why this NPE was thrown, could you paste the entirety of it in a paste bin? Also, does this failed fetching happen only on the patient dashboard? What happens for instance when you access the visit documents page for the same patient, do you observe the same problem? It would also be helpful to know the exact steps that you took to end up uncovering this bug.

At first sight it looks as if VDUI was trying to render obs from the Visit Note encounter (instead of fetching only those from the Upload Document encounter).

Also, what version of the Ref App distro are you using, and in particular which version of the Core Apps module?

Regarding adding documents to past visits, this has already been implemented but is still currently being tested. It will be part of VDUI 1.2 that should be released within two weeks or so.

Hi @mksd,

I setup OpenMRS again with core modules and VDUI. The error is not generated again. I feel it was due to HTML Entry forms i used to upload the files. If i face the same issue again, i will post the complete stack trace of the error.

Besides, I used the dev copy of VDUI 1.2 but i can not open/download the excel or zip files.

Regarding the Excel or zip files, could you attach somewhere a failing file so that I can test it on my end. That’d be really helpful.

Keep in mind that our dev branch represents an alpha version of the module. You can play around with it as much as you want of course. Anyway, as I said earlier, version 1.2 will be released very soon.

Thank you.

@mksd: I have attached an image to an active visit. but when i open the visit not, i get same error as reported early. Check the below link:

Well actually VDUI should not be on qa-refapp, I suspect that something is not quite right with the way extensions configurations are intertwined on that one. You should install VDUI on a clean release of the Ref App distro (2.3, 2.4 or 2.5) and it should be ok.

You can use the SDK to do this in minutes. See ‘SDK: Help with setting up server using installed MySQL’.

Exactly there is kind of issue with other modules.

I have tested around and I found that this issue is with XForm.

@dkayiwa, @bwolfe: Could you please look for this issue? and solve the overlap between modules (XForm with VDUI).

@hpardess could you tell me the exact steps for reproducing this?

here the module : Visit Documents UI 1.1 when you attach a file in a visit using this module. then try to expand and see the visit notes then you will see the error which is already reported in my post.

During testing, i found that when i removed the XForms module. Everything was working good as normal without error. Therefore, XForms has overlap with VDUI module.

Assume that i have never used this module, what are the exact steps for reproducing locally?

If you do not use VDUI module, then XForms works fine, and vise versa. both modules can not be used together. I feel it is the obs type used in VDUI which overlaps with XForms.

if you upload the Visit Documents UI module then upload a file in an active visit. then this issue will be created.

Open the below link then see the visit notes.

@hpardess how does one upload a file in an active visit? (Assume i have never used this module)

Here is the screen shot to upload a file to a visit using VDUI module.

@mksd: I have investigated the issue of why VDUI module overlaps with XForms module.


  • ${ ui.message("coreapps.patientDashBoard.showDetails")} ${ ui.message("coreapps.patientDashBoard.hideDetails")}
  • vdui_view-details class is creating problem. There should be a check if the‘Visit Document Upload’ then and only add vdui_view-details class else add view-details.

    or it will be even more better to apply the template only to those encounters that has‘Visit Document Upload’ and leave other encounter types to be handled as default.

    Interesting… that the issue is coming from this nightmarish template-based patient dashboard. Thanks for looking into it, you are likely looking in the right direction.

    A few remarks:

    The reason for this VDUI prefixed class name ‘vdui_view-details’ is precisely that: avoid collisions when the encounter template is processed:

    $(document).on('click','.vdui_view-details.collapsed', function(event) {

    It would be great if you could keep investigating as I really can’t look into that now. Moreover this collision only happens with XForms which is really weird as I believe that XForms doesn’t touch all this at all (cc: @dkayiwa).

    Another remark, whatever filtering you would wish to happen based on the encounter type must be made based on its UUID and not its name (such as ‘Visit Document Upload’). This is simply because those names can always be changed later on.

    Till the point I have investigated and I found that following line of code causes the problem when we have VDUI and XForms module:

    In attached image you will see that each encounter type is listed two times in JavaScript code First time the “defaultEncounterTemplate” template is set for that encouter type second time the “complexObsEncounterTemplate” template is set which is VDUI template

    Finally, for all encounters “complexObsEncounterTemplate” template is rendered with causes this issue.

    Here is the example: encounterTemplates.setTemplate(‘e22e39fd-7db2-45e7-80f1-60fa0d5a4378’, ‘defaultEncounterTemplate’); encounterTemplates.setParameter(‘e22e39fd-7db2-45e7-80f1-60fa0d5a4378’, ‘icon’, ‘icon-signin’); encounterTemplates.setParameter(‘e22e39fd-7db2-45e7-80f1-60fa0d5a4378’, ‘editable’, ‘true’);

    encounterTemplates.setTemplate(‘e22e39fd-7db2-45e7-80f1-60fa0d5a4378’, ‘complexObsEncounterTemplate’); encounterTemplates.setParameter(‘e22e39fd-7db2-45e7-80f1-60fa0d5a4378’, ‘editable’, ‘true’); encounterTemplates.setParameter(‘e22e39fd-7db2-45e7-80f1-60fa0d5a4378’, ‘icon’, ‘icon-file-alt’); < /per> cc: @mogoodrich , @raff , @wyclif

    @dkayiwa,I think I have found the culprit in XForms: AppFrameworkServiceAdvisor. This AOP advisor was added fairly recently and seems to interfere with Core Apps’s PatientDashboardPageController when it invokes getExtensionsForCurrentUser(..) here.

    Could you have look?

    @mksd that advisor just makes custom encounter types editable by setting the editable property to true, hence exposing a bug in the visitdocumentsui module. :wink: I thought you would just fix the NPE in the visitdocumentsui module.

    Indeed, it seems that the problem is not within XForms. However installing XForms brings an actual issue to light all of a sudden.

    I have followed up with this specifically in a new topic: ‘AppFramework: Custom template ends up supporting all encounter types (instead of just a single one)’.

    @hpardess, the issue was solved here by @dkayiwa. You have to clone, build and use the latest SNAPSHOT of XForms to make the problem go away.