How to add/remove fragments from dashboard & link forms

Continuing the discussion from How do I rearrange fragments in patient dashboard?:

@raff just pivoting off your answer to the question above, how can I do the following via the app framework:

  1. Remove fragments from the patient dashboard

  2. Add new fragments to the patient dashboard

  3. Link my HTML forms (which are deployed) to the general actions via the General Actions tab

Thanks in advance

1 Like

Hi @ssmusoke,

I am assuming that you are referring to coreapp’s first column fragments and second column fragments from …/webapp/pages/clinicianfacing/patient.gsp? If yes, see below.

1. Add a fragment to the dashboard

patient.gsp’s controller fetches extensions whose extensionPointId are either "patientDashboard.firstColumnFragments" or "patientDashboard.secondColumnFragments" to then dispatch them in the appropriate part of the view.

This is for example how the allergy widget is brought in on the left column by openmrs-module-allergyui:

{
    "id": "${project.parent.groupId}.${project.parent.artifactId}.patientDashboard.secondColumnFragments",
    "extensionPointId": "patientDashboard.secondColumnFragments",
    "extensionParams": {
        "provider": "${project.parent.artifactId}",
        "fragment": "allergies"
    }
}

2. Remove a fragment from the dashboard

As pointed by @darius back in the days when we asked, the easiest is to disable the extension that you don’t want to see anymore. You could have somewhere in an activator:

AppFrameworkService service = Context.getService(AppFrameworkService.class);
service.disableExtension("org.openmrs.module.coreapps.patientHeader.secondLineFragments.activeVisitStatus");

Do you mean how to customise the overall actions menu that is on the right hand side?

If yes, then I believe your HFE forms should show up as soon as there is an active visit.

@mksd Thanks, now I get how to manage fragments on the dashboard.

On the forms my question is how to register the forms without going through Configure Metadata -> Manage Forms then adding each form to the UI as is currently the case - I am trying to have my module configure everything for the installation so that a user just has to create new users and they are off.

We have solved this “issue” through our own module’s activator.

The idea is that all HFE forms that are in omod/src/main/webapp/resources/htmlforms/ are scanned by the above code. Ans so we have added new attributes in their header specifying the defaults for what you would otherwise do manually in Configure Metadata \ Manage Forms:

<htmlform formUuid="5743bf01-7879-40a0-ab26-95fc2446e510" formName="Triage" formEncounterType="5235f7da-194e-4278-afbd-a473bb430857" formVersion="0.6"
 formAddMetadata="yes"
 formUILocation="patientDashboard.visitActions"
 formOrder="1"
 formIcon="icon-medkit"
 formShowIf=""
 formDisplayStyle="Standard"
 >
 ...
</htmlform>
```
The above code comes from, amongst others, [our triage form](https://github.com/mekomsolutions/openmrs-module-lfhcforms/blob/dev/omod/src/main/webapp/resources/htmlforms/triage.html#L2-L7).

-----

Feel free to dig in there and ask more questions about our implementation's details.
1 Like

@mksd I owe you a six-pack of beer … This is just perfect!!! Yay!!! HTML forms deployeable via metadata task … finally completed

2 Likes

Just seeing this now… (thanks @ssmusoke for pointing this out to me)… would be good to add this to the reference app somewhere, would have to think about where it should live… @darius

I agree it would be great to get this into the reference application.

@ssmusoke, I know you’ve been mostly doing this, but make sure to create tickets for things like this that would benefit the rest of the community!

Opened - https://issues.openmrs.org/browse/HTML-651 and https://issues.openmrs.org/browse/HTML-652

1 Like

@mksd Coming back to this solution, have you had any need to show the form in two different locations - there are cases when I need the same form in both registrationSummary.overallActions and registrationSummary.overallActions.

How about you introduce a tag in the html form like

<appframeworkExtensions>
    [
        // json equivalent to what you'd otherwise put in xyz_extensions.json
    ]
</appframeworkExtensions>

You can read this at server startup time and then delegate to appframework to actually deal with it.

@darius There is a Form UI Location tag which was holding a single extension for the form, which may be updated to take a comma delimited list of extensions as a quick fix.