We have a challenge at @OHRI with loading JSON forms from the backend.
This occurs when, as designed, initializer retires a form when there’s a new version of the same form in the configuration dir (a new form is created and the existing is retired)
The openmrs api getForms returns a list of forms whether retired or not and in addition, the search is a fuzzy not exact-match kind of search.
Additionally, the api excludes a form x if there is a form y with the same name as x already in the list of forms to be returned (it doesn’t matter whether retired or not)
Has anyone faced this challenge and would it be in order to a) return only non-retired forms and b) return exact match*? and c) do not exclude a form in the return list even if there’s another form in the return list with the same name?
Thanks for this post Amos, some interesting challenges & ideas in here. Initial impression is this seems like things we could improve fairly easily in several ways - tell me if I’m missing or oversimplifying something
1) Form Naming Convention to Avoid User Confusion: I have seen other implementers name their form with the version number to avoid user confusion, e.g. “HIV Adult Return Visit Form v1.7”. Currently if you had just the form name, and there were multiple forms with that same name, they would look pretty confusing to the user, like this:
2) Retiring a Form Behavior:@alaboso what is the use case to show a user multiple different versions? And, could that be addressed simply with the naming convention change?
3) Returning only non-retired forms: This makes sense to me; is there any reason to return retired forms? Doesn’t that kind of break the whole point of “retiring” them? @mksrom@slubwama
a) seems fine; we should probably have a parameterised version that can exclude retired forms
b) seems inappropriate for getForms() however, having exact match be the default behaviour of getForm() would seem fine.
c) is, I think, not something we need to implement. As long as we can indicate to some version of getForms()not to include retired forms, it will only return one version of any form (because form names are required to be unique).
Incidentally, there’s already a version of getForms() which can handle a) and, consequently c), specifically this one (I’m perfectly fine with changing the default behaviour of getForms(String) and adding a new version getForms(String, boolean) which controls the retired parameter; I just wanted to point out that we already have a solution for this).
I agree with adding a parameter to include/exclude the retired forms. What’s the next step on this? What, who and where can this be done? I know some work in REST-WS - no work in core as this utilizes already existing function
In addition, you had a thread on slack - can this requirement be added into the existing /form functionality? like another parameter to also fetch form content including subform content? If not and there’s more that can be added to the proposed backend module, what will happen to the current endpoint? or the new endpoint would only be for content?
I am thinking about it being comprehensive/self-contained where both /form and /form-content exist in one place, as compared to /form being in REST-WS & core and /form-content being in another module
Well, for general form searches, we should update the REST API end point to use the other getForms() end-point and have an includeRetired parameter. If you can ticket that, anyone in the community should be able to make the change.
No, but we’ll have a new endpoint in a new module to handle that.
It will remain as is. The new module, for example, will not implement the ability to search for forms (since the REST module already does that). Just loading and operating on the schema itself.
I’m hesitant to hijack core API endpoints for form-based functionality. OpenMRS still supports multiple form engines, even if implementations might opt to use only one form engine. The form content stuff is particular to the forms involved (e.g., it doesn’t work for HTMLFormEntry, or even make much sense since HTMLFormEntry already defines it’s own endpoints for getting the form contents).
It’s the right thing to do it in the REST module. The o3forms module is only about handling JSON-forms in particular. It should not have any other functionality.
