UI Issue on Bahmni Home screen

On the home screen, the footer displays ‘Bahmni Help’ when the scrollbar is at the extreme bottom.

But when it is scrolled up, ‘ni Help’ still remains on the screen.

Please review this issue and give your feedback.

@darius @teleivo @mksd @sruti

1 Like

@japleen any work in the direction of making this screen better responsive is welcome. Feel free to try out the HTML/CSS refactoring that might improve it, and report back.

1 Like

@japleen I can confirm this bug on the online demo (not sure what version it is). There has been some refactoring recently pushed on ‘master’ (not backported to release-0.90) that fixes some issues in the footer and bottom banner. Maybe that will solve this problem too.

Can anyone run a ‘master’ server and try it?

1 Like

You are right @mksrom. https://product-qa08.mybahmni.org is on master and I don’t see the issue here.

3 Likes

Okay that’s great! Thank you so much!

Hello Everyone, Did install bahmni 0.91 on centos 6.9 which went on successfully without any problem but on launching it I keep getting this error:

On checking the openmrs status it running and my logs are showing:

Really need help. Thanks in advance

I doubt the logs and the first screen correlates! The first screen indicates login page access and the error is probably relevant to clinical or IPD modules!

I would suggest that you do further investigations. Some pointers

  1. if OpenMRS is running? check [yourserver]/openmrs and see whether app is running, and check modules statuses etc
  2. Check request/response on the browser side - While accessing the login page, keep checking chrome developer tools, network calls and see for which call the error is. Can you can find out more info from the headers, responses?
  3. Keep tailing the log file on the server and try to find logs for starting with the browser call!

tail -200f /var/log/openmrs/openmrs.log

Thankyou for the prompt reply, sorry for the wrong log . On running

tail -200f /var/log/openmrs/openmrs.log

And

Thank you

I am guessing its the partial log. OpenMRS didn’t startup properly, I can see many modules failed to start. Check why the modules have not started up.

These are the reason

@ejustine and what’s the version of Bed Management on your installation then?

@mksd the Bed management module is version 5.8.1

Thank you

What happens when you attempt to start that one specifically?

@mksd On starting the Bed management module, it brings this message:

Error while starting module bedmanagement

Can you look in the logs to what is being produced when you attempt to start it?

@ejustine Seems like issue with the bed-management module. Have you identified the issue as @mksd suggested above?

Also, have you checked for the known for release 0.91

Beds Count mismatch on new Bed Management app

select count (bed_id) from bed_location_map where bed_id is null ;

select count (bed_id) from bed_location_map where bed_id not in ( select distinct bed_id from bed);

and also check for the known issue resolution for set a layout in ward management admin console

@mksd using this command:

tail -200f /var/log/openmrs/openmrs.log

Got this output on stating the Bedmanagement module

@ejustine next time, you should copy the log and share it through https://hastebin.com/ or equivalent.

Looks like there is an issue with table bed_type, where the column ‘uuid’ is already there when a Liquibase changeset is trying to add it. Are you sure that you’re starting off a blank sheet? Or is this an upgrade?

@mksd, it was a blank sheet , then database was sourced from bahmni 0.89 backup.

Thank you.

seems like its trying to add a column “uuid” to the bed_type table, where it already exists! Hacky solution (without the complete log available to make any other viable alternative)

  1. drop the column “uuid” from the “bed_type” table.
  2. Run bahmni, check whether the “uuid” column is added
  3. ensure that “uuid” column is populated uniquely for each row! (just use the uuid() function for each of the rows - you can do that manually, I am assuming that bed_types would be too many)

(If possible put the entire log in a pastebin, maybe it will throw more light)