Displaying HTML entry forms based on login session in reference application

jmpango · February 19, 2016, 5:46am

How can i display HTML forms on the patient dashboard based on the selected login session?

I have tried adding the following under manage forms - show if: sessionContext.sessionLocation.uuid == ‘XXXX’ , where XXX is my location uuid but it does not work as desired. When i add it, the forms do not show under the patient dashboard.

where am I getting it wrong? @darius @dkayiwa @mseaton kindly advice

darius · February 19, 2016, 6:47pm

@jmpango I haven’t tested this myself, but I think it’s just sessionLocation.uuid == 'xyz' (i.e. you don’t need sessionContext).

Is there some documentation somewhere that led you to use sessionContext? If so we should fix that (if my suggestion works).

I looked at these two code snippets:

jmpango · February 21, 2016, 3:55pm

@darius, i have added the sessionLocaton.uuid == xyz but still it does not work.

I had looked at this https://wiki.openmrs.org/display/docs/Conditionally+displaying+Apps+and+Extensions;jsessionid=EA29157F3B1CD180EA95A0061FA5244E for the sessionContext.

Am still looking forward for any other option you will advice for me to achieve displaying the forms depending to the login session

dkayiwa · February 21, 2016, 4:27pm

@ssmusoke did you just forget to put the uuid in quotes? Can you copy and paste here the exact expression you are using?

jmpango · February 21, 2016, 7:17pm

@dkayiwa: sessionLocation.uuid==‘86863db4-6101-4ecf-9a86-5e716d6504e4’ that is the expression i have.

dkayiwa · February 21, 2016, 7:28pm

Can you try appContextModel.sessionLocation.uuid?

dkayiwa · February 22, 2016, 6:14pm

I tried to debug this and sessionLocation.uuid==‘86863db4-6101-4ecf-9a86-5e716d6504e4’ works well if i pass the session Location object to the javascript engine via javascriptEngine.setBindings(). So the reason this does not work is because session Location object is passed as a SimpleObject which is just a hash map that looks like: sessionLocation={uuid=2131aff8-2e2a-480a-b7ab-4ac53250262b, display=Isolation Ward, name=Isolation Ward, …}

Other expressions like patient.uuid work well because the actual patient object mapper is passed as: patient=org.openmrs.module.coreapps.contextmodel.PatientContextModel@43f4ef20, instead of SimpleObject.

In summary, after this line: https://github.com/openmrs/openmrs-module-coreapps/blob/master/omod/src/main/java/org/openmrs/module/coreapps/page/controller/patientdashboard/PatientDashboardPageController.java#L83 when i do something like below, all is well: contextModel.put(“sessionLocation”, sessionContext.getSessionLocation());

If i have got this right, then we need a ticket to look into it.

jmpango · February 23, 2016, 5:40am

Thanks @dkayiwa for looking into this. That was pretty smart.

darius · February 23, 2016, 2:59pm

Good research @dkayiwa. This is annoying!

The idea is that we want to have simplified JSON-equivalent context models so that they can be evaluated on either the server or client side, so we actually want to go in the direction of how session location is currently doing it.

Can you tell if there is some way to bind a JSON-equivalent object into the JavaScript engine?

ssmusoke · February 24, 2016, 6:38pm

@dkayiwa so where do we go from here?

dkayiwa · February 26, 2016, 12:43pm

@ssmusoke the easy alternative is to simply use: sessionLocation.get('uuid')=='86863db4-6101-4ecf-9a86-5e716d6504e4'

That should work well.

ssmusoke · February 26, 2016, 1:35pm

@dkayiwa Will this work in the “Show If” form metadata as that is where the rule is defined? cc @jmpango

dkayiwa · February 26, 2016, 1:55pm

@ssmusoke yes it should work.

darius · February 26, 2016, 9:00pm

I created a ticket for this bug at

@ssmusoke, @jmpango, note that when we fix this bug, “sessionLocation.get(‘uuid’)” will stop working, and you’ll need to go back to the originally-intended “sessionLocation.uuid”.

@dkayiwa, I looked into this more, and it’s very annoying. There’s no nice way to put any Map-like object in the ScriptEngine Bindings and have it be treated as a JavaScript object. (I’m surprised about this.)

Of course there are a couple of hacky workarounds:

For each contextModel property that’s a Map, we evaluate a script that defines it as a variable within the engine using json, prior to evaluating our actual script. Here is a pull request for this approach.
Use NativeObject as shown here.

The second is arguably cleaner, but we’d have to do a deep conversion of all the Maps-within-Maps to be NativeObjects, so I chose the first approach.

I’d like some feedback about this before deciding whether to apply it.

@mogoodrich FYI

dkayiwa · February 29, 2016, 7:29am

My vote is that we apply this. Thanks @darius for the pull request!

jmpango · February 29, 2016, 2:48pm

@dkayiwa, Please let me know when you merge the pull request so that I can test it out.

mogoodrich · February 29, 2016, 3:03pm

@darius:

Note that we have been using the sessionLocation.get(‘uuid’) approach (and similiarity things like user.get(‘fn’).hasPrivilege(‘View Patients’)), so this change will break these, and the following downstream tests in appui (I assume):

github.com

openmrs/openmrs-module-appui/blob/master/omod/src/test/java/org/openmrs/module/appui/simplifier/UiSessionTest.java

package org.openmrs.module.appui.simplifier;

import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

import java.util.Arrays;

import org.junit.Before;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.openmrs.Location;
import org.openmrs.Privilege;
import org.openmrs.Role;
import org.openmrs.User;
import org.openmrs.api.context.UserContext;
import org.openmrs.module.appframework.context.AppContextModel;
import org.openmrs.module.appframework.domain.Extension;
import org.openmrs.module.appframework.service.AppFrameworkServiceImpl;

This file has been truncated. show original

I don’t mind changing things on our (PIH) end, because this does seem like a better approach, but I’ll need to coordinate, and I don’t know if anyone else has been building “require” expressions using this model? (probably not?)

darius · February 29, 2016, 3:20pm

I vote that this gets changed in coordination with the Reference Application 2.4 release that should happen this quarter.

(I’m not in a position to do the coordinating though!)

mogoodrich · February 29, 2016, 3:34pm

From a PIH perspective, coordination = just let me know when this change gets merged in.

darius · March 1, 2016, 11:33am

In that case…I just merged it. And I’ll release a version of AF with this for use in the refapp 2.4 release.