(feat) Revitalized Immunization Support

[samuelmale]

Requirements

• This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
• My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
• My work includes tests or is validated by existing tests.

Summary

This pull request addresses and resolves issues related to the Immunization package, which was previously broken and non-functional.

Key Changes

• Immunization Form Refactoring
• Detailed Summary Widget Enhancement
• Test coverage

Screenshots

Demo:

https://www.loom.com/share/ddcf5b602d5244fbbf86ba2739c9bb37?sid=f1294f54-d6ff-4ee5-a7c6-d473168752df

Related Issue

• https://openmrs.atlassian.net/browse/O3-2554
• https://openmrs.atlassian.net/browse/O3-2553

[ibacher]

Thanks @samuelmale! This mostly looks very good, but a few things should be adjusted.

[samuelmale]

@ibacher @denniskigen updated

[denniskigen]

Should None be listed as an option from the Immunization dropdown?

[denniskigen]

Also, might it make for a better UX to disambiguate between create and edit mode when using the Immunizations form in the workspace? Here I'm editing an existing immunization, yet the workspace title is the same that you'd see when creating an immunization:

edit-mode-for-an-existing-vaccination.mp4

[denniskigen]

You might also need to consider removing this padding so that immunization content in the Datatable is left-aligned to the start of the column (and not indented as you see here):

[samuelmale]

Should None be listed as an option from the Immunization dropdown?

@denniskigen That is an implementation detail; for the RefApp we may have to fix this in CIEL: https://app.openconceptlab.org/#/orgs/CIEL/sources/CIEL/concepts/984/

[samuelmale]

You might also need to consider removing this padding so that immunization content in the Datatable is left-aligned to the start of the column

I'm terrible at CSS; but hopefully, this passes the bar:

Also, might it make for a better UX to disambiguate between create and edit mode when using the Immunizations form in the workspace? Here I'm editing an existing immunization, yet the workspace title is the same that you'd see when creating an immunization:

@denniskigen Do we have a standard way of going about this?

The form title is defined at workspace registration; Qn: Is it possible to change the workspace title during the workspace launch? If not do we want to register two workspaces?

[denniskigen]

You might also need to consider removing this padding so that immunization content in the Datatable is left-aligned to the start of the column

I'm terrible at CSS; but hopefully, this passes the bar:

Also, might it make for a better UX to disambiguate between create and edit mode when using the Immunizations form in the workspace? Here I'm editing an existing immunization, yet the workspace title is the same that you'd see when creating an immunization:

@denniskigen Do we have a standard way of going about this?

The form title is defined at workspace registration; Qn: Is it possible to change the workspace title during the workspace launch? If not do we want to register two workspaces?

Yeah, that'd require more than one workspace registration, which is probably not what you want to do. Also, CSS is fine.

[ibacher]

The form title is defined at workspace registration

The title is also overrideable in the call to launchPatientWorkspace() which is how we set the title to the form name when launching the form apps.

Speaking of which, we prefer to use registerWorkspace() rather than extensions for workspaces...

[samuelmale]

@ibacher I knew it was possible to override the workspace title (I've done it in the past); Revisiting the workspace API as a refresher I got confused whether it was still supported. I feel like the API isn't explicit enough on the support of overriding the title.

export function launchPatientWorkspace(name: string, additionalProps?: object) {
 // 
}

In the doc, it implies that additionalProps is an arbitrary object passed to the workspace component. Is it ideal to support this through an optional parameter?

[denniskigen]

Separate from the form title discussion, I've taken the liberty to push a couple of commits on top of your work which fix various issues with styling, @samuelmale.

[ibacher]

Well, that's because to the API at that point, additionalProps is a bit of a black box. The implementation that allows the workspace title override is the workspace component itself. The issue is that additionalProps is used to pass properties to just about anything in the workspace registration chain, and we don't necessarily know the types. I guess:

interface WorkspaceAdditionalProps {
  workspaceTitle: string;
  [p: string]: unknown;
}

Kind of works, but is annoying...

[denniskigen]

@samuelmale, have you been able to attempt Ian's suggestion? And, @ibacher, have all the changes you requested been addressed?