QA/UAT for Bed Admin OWA (for v0.91)

Continuing the discussion from is there any module that can manage Bed in hospital instead of adding script simple UI:

Copying over my comments from ~3 months ago:

Some of those may have been addressed already, but if so, nobody replied on the thread. (I know at least some are still outstanding.

Some more comments from testing today:

  • When I add a top-level admission location, the button still says “Add Ward”. It should say “Add Admission Location”
  • When adding a top-level admission location, you are asked to specify the “parent location”. That’s good, but it’s not obvious from this screen what value you want to choose. I recommend the following quick fix:
    • when I view a ward, under the breadcrumb (e.g. “Admission Locations > General Ward”) it should also show the location.description. And if this is a top-level admission location it should also show the “parent location”. (For children it’s already implied by the breadcrumbs.)
  • when you’re looking at a room, there should be a “loading” effect while things load.
  • I was able to assign a bed to someone, and then delete that bed with no warning/confirmation. That’s bad. (Personally I would block this entirely until you unassign the bed.)
  • I didn’t try this, but “Delete bed layout” should also not be allowed if beds are assigned

A bit more QA:

  • If your implementation doesn’t have a LocationTag named “Admission Location” and you try to create an admission location you get a 500 error with a stacktrace that is not understandable
  • If you have not created any bed types and then you Set Bed Layout for a location, you get a blank screen with no understandable error message
  • I tried to create a Bed Type with type “standard” and display name “Standard Bed” and a toast error message flashed very quickly (barely enough time to copy-paste):

Error ‘BedTypehashCode=673ebb81,uuid=832f995b-88a2-45a4-8269-8a14be142afd’ failed to validate with reason: displayName: This value exceeds the maximum length of {0} permitted for this field.

  • It works if I use display name “Standard”. “Standard Bed” really doesn’t seem like it should be too long. At the very least the {0} needs to be filled in.

And from looking at the code I also just noticed that this app will only work if you have OpenMRS deployed as /openmrs. (That is hardcoded in UrlHelper.apiBaseUrl and in header/index.js.)

I sent a PR for some of the easier fixes, but in general I’d like to get a sense from @arjun or other implementers which of these feedback should be blockers, versus things we put in the backlog.

(My guess is that “don’t allow deleting a bed, or bed layout, that is assigned” should be a blocker and everything else is a nice-to-have.)

I agree that fixing anything that puts data in an inconsistent state, like deleting an entity (bed, bed layout) which is being used, would be must have. @darius, it’s difficult to follow these feedbacks here and understand their status. Can we have a spreadsheet with line items and their priority and status for tracking or something in JIRA if its easy.

Also, is it possible to deploy this on a server which has 0.90? I was hoping i could deploy it on one of the test servers with actual data at a client site, so they could do some testing.

I summarized everything in this issue comment in JIRA. I think we can just track it in JIRA (i.e. create subtasks for the parts we’re going to do now in 0.91, and separate tickets with the backlog of feedback).

The main question for you (@arjun, or any other consumers of this function) are whether anything I did not list as a blocker for 0.91 should actually count as a blocker.

I assume you can just deploy the latest snapshot of the bedmanagement module in OpenMRS. There aren’t any other requirements that I know of. (For my testing I set up a fresh OpenMRS Platform of the latest version, and added the legacy ui module, plus the bedmanagement module.)