I would like to upgrade to Reference Application 2.3.1, but come across the following bug:
The “End Visit” button doesn’t work while on the PatientDashboard page.
Steps to reproduce:
- Select a patient with an active visit.
- On the “Recent Visit” widget, click on the current active visit.
- Once redirected to the Patient Dashboard, click on the “End Visit” button and confirm that it nothing happens.
The HTML of the button:
VisitId is appended to the end of the script line !
The JS error:
Any idea where/why this happens ? Which code adds this
visitId to the end of the button links ?
Note: I am running openmrs-standalone-2.3.1
Thanks @dkayiwa, yes that’s what I was looking for.
@mogoodrich and @dkayiwa, why is this done that way ?
What is the action to take here to solve this problem ?
This is quite a blocker for us to upgrade to 2.3.1 Reference Application.
When the change is approved, we just need to release a new version of the module and you replace the omod in your reference application installation with the new one.
Thanks @wyclif. For now I’ve cherry-picked this commit and merged into my own fork of Coreapps (which is based on Coreapps-1.8).
Is there any chance that this commit (when approved) would be pushed back in the time to
tag 1.8 of Coreapps ?
No, it won’t be backported. The OpenMRS community does not maintain
multiple branches of any modules, only of openmrs-core.
(However if you wanted to do the work of creating this branch and tag and
doing the release yourselves, I guess it would be fine for you to push
those to the github and maven repositories, with some appropriate tag
Ok thanks @darius for the clarification.
For now we will keep maintaining our forks on our repo, since they still differ a lot from the upstream anyway.
@mksrom releasing a module is very easy, as long as the code is committed, approved and the fix has been tested to work, you’re only a click away in bamboo from releasing a new version of the module which i think is way less work than what you had to do
Yes @dkayiwa, this sounds like the same issue I ran into; RA-952.
Ack… first off, sorry, don’t know why I’m just seeing this now… Talk doesn’t seem to really alert me differently when I’m “@ed” in a ticket versus just a normal alert.
This code is a mess, can’t wait until we get away from it! But, unfortunately this fix breaks something else, at least in the PIH app, (going to try to reproduce it on devtest01).
Was going to try to hack in a fix, bu that’s never a good idea on a Friday evening… I will pick this next week (Tuesday, since it’s a long weekend). I can do a “one-click” release after I fix. Hopefully not a blocker until then.
@mogoodrich, This is a bug fix am also waiting for. I have started rolling out the reference app with this bug so if it gets fixed, that will be good. kindly update us when a new version of this module is released with this bug fix.
fyi, I’ve some new commits for this that hopefully will fix the issue without introducing the new issue. See my latest comments here:
Is there a specific CI server I can test this on?
Added the changes as described in the commit and the issue seems to be resolved but not completely.
I’m facing a new workflow related error.
Whenever user ends a visit from the patient dashboard page after navigating from clinicianfacing patient page using active visit hyperlink (1st visit in recent visit list), the end visit works properly.
But, the user is forced to reload/refresh the page in order to end visit if the user navigates to patient dashboard from clinicianfacing patient page by clicking on share/edit icon.
@dkayiwa do you think we should do “one-click” release of coreapps just to get the basic fix out there? Then we can tackle the issue that @themoonraker13 themoonraker13 is reporting?
If we release a version, will devtest01 pick it up automatically, or do we need to update the reference app distro pom?
@mogoodrich the one click release is supposed to update the version in the distro and hence devtest. But if it does not, then we shall manually update the distro. So go ahead and do the one click release.
Cool. I am just getting back to this now, but I will release coreapps tomorrow and test.
I’ve found the probable cause of the issue. I tried ending an active visit by navigating to dashboard in two ways:
- Clicking on active visit hyperlink (1st visit in recent visit list) on clinicianfacing patient page
2… Clicking on share/edit icon
I’m able to end visit when I navigate to patient dashboard using method 1 and forced to refresh the page in case I end the visit after navigating to patient dashboard using method 2.
The URLs I’m redirected to when I navigate to patient dashboard are:
Method 1: http://demo.openmrs.org/openmrs/coreapps/patientdashboard/patientDashboard.page?patientId=deb0905c-3b82-4631-88b2-b71425755cdf&visitId=170#/visits
Method 2: http://demo.openmrs.org/openmrs/coreapps/patientdashboard/patientDashboard.page?patientId=deb0905c-3b82-4631-88b2-b71425755cdf#/visits
If you see there’s a slight change in the URLs. Specifically a missing visitId parameter in URL generated for method 2 causing the issue.
Great research @themoonraker13! Can you please create a ticket for this in the RA project at https://issues.openmrs.org/browse/RA ?