[WARNING]
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is java.lang.NullPointerException
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:978)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:857)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
.
.
.
Caused by: java.lang.NullPointerException
at org.openmrs.module.visitdocumentsui.obs.ValueComplex.(ValueComplex.java:30)
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.
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.
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.
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.
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.
vdui_view-details class is creating problem. There should be a check if the encounter.encounterType.name==‘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 encounter.encounterType.name==‘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:
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.
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’);
@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.
@mksd that advisor just makes custom encounter types editable by setting the editable property to true, hence exposing a bug in the visitdocumentsui module.
I thought you would just fix the NPE in the visitdocumentsui module.
I thought you would just fix the NPE in the visitdocumentsui module.