3.) Thanks for reporting the bug, I upvoted and also commented it.
9.) We will start work ourselves on this within 2 to 3 weeks on our own fork of coreapps, hopefully our changes could be adopted by the community later on. There is a double issue in fact:
The "contactInfo" section is automatically picked up by the patient header fragment, but it sticks to the default Registration App’s URL (behind the ‘Edit’ button) rather than understanding that it has been overriden by another instance of the Registration App.
In our opinion, the other sections defined via the Registration App’s JSON should also have a ‘quick display’ with an ‘Edit’ button pointing to the ad-hoc section for edition. Or at least it should be easily configurable to obtain that. So the patient header should understand that further sections exists and provide quick displays and links to the relevant GSP to edit them.
Note that right now, there is no way to even view those sections (at least in the new UI, we never used the legacy one though). The workaround being to design bespoke HFE forms for the registration custom encounter type that allow edition (and hence viewing).
Of course, we are actually starting work on this literally right now.
And I’m hoping that we will have made quite some progress by the end of next week.
We will be working on our own fork of coreapps 1.6 and will submit this via a pull request as soon as we have reviewed the code (and unit tests) and tested the omod ‘enough’.
I will ping you as soon as we have got something useable for testing, so most likely in the course of next week. We would love to get your feedback then.
We finally have produced a version (126.96.36.199) of coreapps that aims at being consistent with the registrationapp’s configuration on a given OpenMRS instance.
In our version, you can toggle ‘Show/Hide registration Info’:
Our version of coreapps analyses the registrationapp’s configuration and ensures that every section is displayed with its ‘Edit’ hyperlink (and not just the "contactInfo" section as it is done now).
We would love to get other people to test this and provide feedback, and hopefully encourage us to go for a pull request for all of this on coreapps!
There is a limitation though. You will notice on my screenshot that the ‘Edit’ link is missing for the last section: ‘Ethnicity’. This is because, in our registrationapp’s config, this section uses "obs"-type fields. And it turns out that registrationapp’s editSection.gsp (or rather its controller) does not handle that situation. It can handle PersonAddresses and PersonAttributes but not Obs.
We prefer, altogether, to conceal the ‘Edit’ button as soon as obs are involved because, to make matters worse, if you leave it, it just behaves as if everything was fine, but nothing gets saved.
For now those have to be edited through an HFE form, but at least they display in the patient header with every other sections.
I believe you should be able to grab it from our CI server, I will send you the link in a private message.
This has not been tested much. In fact it has only been tested with our client’s registrationapp’s config. We are really keen on getting bug reports though, before requesting a pull on coreapps.
It is based on coreapps 1.6. That is the coreapps that was shipped with the distro 2.2 (which is the one we are still on). You will most likely not be able to install this on a 2.2+ instance
There are other changes than the ones you saw in my screenshot. We have added extension points in two places to allow for customisation of the patient header further. For example, this was requested by our client:
Dear @mksd, thank you so much for your work on this! What a wonderful Christmas present. I apologize that I didn’t get time to test this out before now.
As you suspected, it didn’t work with Reference App 2.3.1. I setup a standalone with 2.2, then imported my 2.3.1 database. The address hierarchy last field “broke” when I downgraded, but that was before I added your updated module. I found it to be fully functional on my system, allowing me to edit addresses, with the auto-complete boxes. I also found that I was able to see and edit my custom fields.
The only problem I ran into was with the formatting of the view page when viewing it in French; there is some overlapped text. In English, it wraps the last field to a second line and looks fine. Perhaps if I designed the form in more separate sections like yours it would be prettier.
Hi @arbaughj, nice, thanks for providing feedback!
It’s great that you actually tested with i18n using it another language than en-us.
As soon as possible we will upgrade our development platform to the latest Ref App distro, we will then merge all of this into the most recent version of coreapps, solving the problem… and putting us in a position to push this to the community.
I just played a bit with this on my end to reproduce your issues, and I could reproduce both:
The ‘Edit’ button/link overlap when it just goes to the line.
We have reused the same HTML structure and CSS as what was there before. Basically copying from contactInfoInline.gsp (the one in use if you look at the community sources.)
It turns out that another option is out there, burried in coreapps, but not used from what I can see: contactInfo.gsp. Copying from that one would solve the problem but would also imply a visual design change. The ‘Edit’ link would always be in the same right margin, regardless of the amount of data on its left hand side. Like this:
But then the widest line determines where, on the right side, all the ‘Edit’ links will be aligned. It may be impractical in some cases, but the issue you experienced would not occur anymore. However I find that, when using this HTML layout, one tends to click on the wrong ‘Edit’ link as they are not quite aligned with the data they are meant to edit.
The patient ID widget not staying at the top.
This is trickier and I am not sure exactly why this happens but clearly the existing structure doesn’t quite work in cases when more than the whole width is filled up. I mean it works, but the identifier gets moved down.
I think we should live with that one and raise a bug later if that is ok with you.
Although I agree with you that none of the two above should happen, you may indeed be able to simply avoid it all by creating more sections with less data in each section, as you suggested.
It seems that you could do something like we did and split your configuration with a ‘contact info’ section and a ‘next of kin’ section. Would that be an option for you?
As is it now, Registration App generates by default a Registration Summary config that follows the sections of the Registration App config. Meaning that you can always access all the sections in edit mode that are part of the Reg App config in the first place. See:
RA-1425 - Registration summary page to display all defined sections of the Registration App
I don’t remember though if the link to the registration summary is automatically added to the patient dashboard, maybe not… @ruhanga?