RefApp OMOD modifies existing global properties

In Bahmni, we recently tried to add appointment scheduling ui module which in turn also needs ‘referenceapplication-omod’. But when the referenceapplication-omod is started, some of the global properties’ values are modified.

For example, once the reference app is started, value of emr.concept.diagnosisSetOfSets global property is changed to '160167AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' which does not exist in our concept dictionary.

The code which changes the global property is here:

Can someone let us know the reason for adding these global properties? Also, shouldn’t we skip modify the existing global property and insert only the new global properties?

@preethi_s, you do not need to include the referenceapplication module. There are many dependencies, but this is not one of them, per the config.xml.)

In general you do not want to run the referenceapplication module with Bahmni (and you also don’t want referencemetadata). The purpose of the module is to own and control the distribution, e.g. defining the apps that are available, it manages and synchronizes content (roles and privileges, concepts), and it wires everything together by setting global properties.

Yep, we built appointment scheduling ui to use within our distro, and we don’t use any of the reference app modules. There may, however, be some appointment scheduling ui configuration required that you may want set up in a distro module of your own. If you are having issues, feel free to let us know.

@mogoodrich We are able to start appointment scheduling ui module without referenceapplication. However, the UI of appointment scheduling looks without any styling.

Also, we are getting some exceptions on navigating to ‘Manage Appointments’.

Correct me if we miss something. Do we have to do any configuration for appointmentscheduling ui to work independently?

Hmm, there are css files for the appointment scheduling ui, so not sure what is happening there… can you view the source of the rendered page and see if it is properly generating the urls for the css?

Looks like the stack trace NPE is happening when it tries to fetch the session location from the ui session context. You might not be setting that in your app–and, quickly looking at the code, I can’t remember 100% what it is used for, so I just made it null-safe (sets the value to an empty string if ui session context or session location is null). I just pushed up that change, so you can pull in the latest version of the module and test.

Take care, Mark

@mogoodrich yeah on looking at the source of the rendered page, the css file which adds the styling is ‘/openmrs/ms/uiframework/resource/referenceapplication/styles/referenceapplication.css?cache=1438194310291’. The file is missing when ‘referenceapplication-omod’ is undeployed.

Hmm, I will take a look… we don’t use the reference application, so it definitely isn’t required, and there is css styling within the appointmentschedulingui. I will see what come is happening on our end–it may be that the styling within appointment scheduling isn’t complete and requires some additional styles that, in our case comes from our “mirebalais.css” styles instead of the reference app ones.

So it looks like the appointmentschedulingui module (and perhaps all the uiframework modules) depend on some top-level styles being included. In the reference app, this is referenceapplication.css, and we use one called pihcore.css.

We wire it so that it is included in every page here:

And the css file we use is generated from this scss file:

I’d guess you’d want to steal our css and then start modifying it to fit Bahnmi style, or perhaps there is an existing Bahnmi css that would provide the styling you need?

@darius, thoughts?

I think the issue is that you need to include the uicommons styling.

At PIH this is done via the mirebalais module (and there is some sort of uiframework global resource includer) and in the refapp it is done via referenceapplication.scss.

I think you need to add a small bit of code in some Bahmni module that does the same.

Side note, I just updated the latest head of the master branch of appointmentschedulingui to depend on the latest snapshot (1.7-SNAPSHOT, I believe) of the coreapps module.

Thanks @darius and @mogoodrich. We created a bahmnicore.scss which basically just imports the uicommons default styling.

Here are things I had to do just to document my learnings.

  • Add StandardModuleUiConfiguration bean in webModuleApplicationContext to be recognized by uicommons.

  • Add a GlobalResourceIncluder in webModuleApplicationContext to include the bahmnicore.css in all pages.

  • Ensure the right resources are included in bahmnicore.scss.

  • @import “variables”; //Required for the “reference” scss

  • $fontPath: “…/…/uicommons/fonts”; //Make uicommons use its own font files path

  • @import “reference”; //Actually import all necessary css files from uicommons

  • Require uicommons module in config.xml

Everything is good now.

Sorry. I was a bit soon in mentioning that all was good. There seems to be another dependency on the referenceapplication. I am not sure how this has been handled in PIH. The page “/appointmentschedulingui/” throws a NullPointerException, and the cause is that we do not have the “sessionLocationId” set anywhere. Stack trace here.

I find a null check for sessionLocation in places where it is used. Would it work if we just make this handle nulls gracefully?

If you are going to be using reference application modules alongside Bahmni, you should have the Bahmni login controller set a session attribute for “session location” as is done in the reference application login controller.

fwiw, I thought I made this null-safe a couple weeks ago when this error was first encountered:

Not sure if I’m missing anything obvious…

Thanks for pointing it out. I overlooked recent changes in the module. The page works fine now. We can use the module if a similar fix is done on as well. :smile:

We use the REST module (/openmrs/ws/rest/v1/session) to login, there is no custom login controller. Which means I will probably have to create a call that just adds “session location” to the httpSession.

Ah, interesting.

I wonder if we should introduce (in the rest module) some kind of onLogin hook?

1 Like

That will be a very useful feature to have.