Implementation-defined forms should be available through the RA user interface

Background

The 2.0 reference application includes some built-in forms, accessible through the new UI, but forms created by implementations using HTML Form Entry or XForms cannot be accessed through the new UI without writing code (because they need to be connected to extension points through the App Framework module).

There were some discussions around this at the 2013 Implementers Meetings. See the notes here.

Approach and Scope

Build a new Manage Forms page that lists all Forms, and lets you manage how they are attached to the UI.

It is not necessary to replicate all Manage Forms functionality from the legacy UI as part of this epic.

It is only necessary to support HTML Form Entry and XForms. If the user tries to attach a form that uses some other technology to the UI, it's okay to fail.

Mockup

Dev Notes

I suggest implementing this in a new module called formentryapp or formentryui

The core org.openmrs.module.web.extension.FormEntryHandler class can be used to determine whether a form is an HTML Form or an XForm. If that class turns out to no longer serve its purpose (e.g. because the view/edit/enter urls point to the old UI not the new one) then it may be necessary to include an appframework extension point for use in the 2.x web application.

The "where to attach each form to the UI" data could be stored in many different ways. The most sophisticated would be to introduce a general-purpose table to store implementation-defined extensions. The simplest (offhand I like this best) is to store this as a JSON document in a FormResource attached to each form.

We need to introduce an implementation of the org.openmrs.module.appframework.factory.AppFrameworkFactory interface that generates appropriate extensions based on how the form wants to be attached to the UI. You can see an example of what the extensions should ultimately look like here: https://github.com/openmrs/openmrs-module-referenceapplication/blob/master/omod/src/main/resources/apps/visitActions_extension.json

Potentially we need to switch the extensions that currently live in https://github.com/openmrs/openmrs-module-referenceapplication/blob/master/omod/src/main/resources/apps/visitActions_extension.json so that they are set up by this implementation-defined mechanism instead (and thus can be configured by implementations too).

AppFramework loads extensions during its activator's contextRefreshed() method. So after saving a change to where a form wants to appear in the UI, you need to call this.

Acceptance Criteria

1. The patient dashboards should have an action under Visit Actions for the currently-active visit that let you choose a form to fill out (from among forms suitable for a visit context)
2. The patient dashboards should have an action under Overall Actions that let you choose a form to fill out (from among forms not tied to a specific visit)
3. The administrator should be able to choose specific forms to appear as top-level Visit Actions
4. The administrator should be able to choose specific forms to appear as top-level Overall Actions
5. Forms built via either the HTML Form Entry or XForms module may be published in this way
6. (nice-to-have) Forms that are top-level actions should have an icon associated with them, if specified by the admin

Open Questions

Do we need to also provide a way to control how a form is displayed on the Visits page when you expand its encounter?