(fix) O3-2658: Show attachment descriptions when available

[Vijaykv5]

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

• The Title for Attachments thumbnail has being removed from every attachments.
• The description of the attachment preview is changed to title as we are placing the image description in title.
• Major fix in POST API was fixed here.

Screenshots

Related Issue

03-2658

Reference issue in API : openmrs/openmrs-esm-core#908

Other

The Name of the file attached is removed as it doesn't make much sense for the clinician.

[Vijaykv5]

@denniskigen @dkayiwa May you can review this PR?

[denniskigen]

@ibacher it appears that the attachments resource doesn't have a provision for recording a description of an attachment. In lieu of this, should we weigh whether to show the image description instead of the image title (which might be not be particularly informative in many cases, unless the user explicitly amends it to make it so).

[ibacher]

@denniskigen Problem is that the title is also treated as, effectively, the name of the file when it's downloaded, so I don't know that we'd want to do that. There is an instructions field that might be useful for holding a description? I'm not sure if it's exposed via the REST endpoint, but that would be easy to fix.

[denniskigen]

Cool, can we do that then, @ibacher?

[Vijaykv5]

@denniskigen Problem is that the title is also treated as, effectively, the name of the file when it's downloaded, so I don't know that we'd want to do that. There is an instructions field that might be useful for holding a description? I'm not sure if it's exposed via the REST endpoint, but that would be easy to fix.

I think as of now we are not having an instruction field in Endpoint

[ibacher]

Actually, things will work properly if we just wire the description field to the "comments" attribute and display that. What appears to be happening is I upload a file, give it an image name and that is set as both the file name (title on the backend) and comments.

Basically a file upload looks like this:

-----------------------------37729685656089254093382668808
Content-Disposition: form-data; name="fileCaption"

bytes.png
-----------------------------37729685656089254093382668808
Content-Disposition: form-data; name="patient"

eb0ea38e-f414-4cec-819d-6e9ae9239d4a
-----------------------------37729685656089254093382668808
Content-Disposition: form-data; name="file"; filename="bytes.png"
Content-Type: image/png

CONTENTS

As you can see, we're setting the name bytes.png twice. The first one (the fileCaption field) should be set to whatever is in the description.

We might need a ticket to be able to display the filename, but I don't know that that's critical.

[ibacher]

And here's a ticket I created almost a year ago to get this added: https://openmrs.atlassian.net/browse/ATT-52

[denniskigen]

Is it fair to say that this should be a prerequisite for merging this in?

[ibacher]

Is it fair to say that this should be a prerequisite for merging this in?

I think so. I think there's a little bit more revision of the attachments widgets required once that change gets made.

[Vijaykv5]

So do we need to wait until once the prerequisite to complete?

Actually, things will work properly if we just wire the description field to the "comments" attribute and display that. What appears to be happening is I upload a file, give it an image name and that is set as both the file name (title on the backend) and comments.

Basically a file upload looks like this:

-----------------------------37729685656089254093382668808
Content-Disposition: form-data; name="fileCaption"

bytes.png
-----------------------------37729685656089254093382668808
Content-Disposition: form-data; name="patient"

eb0ea38e-f414-4cec-819d-6e9ae9239d4a
-----------------------------37729685656089254093382668808
Content-Disposition: form-data; name="file"; filename="bytes.png"
Content-Type: image/png

CONTENTS

As you can see, we're setting the name bytes.png twice. The first one (the fileCaption field) should be set to whatever is in the description.

We might need a ticket to be able to display the filename, but I don't know that that's critical.

[denniskigen]

Work on the ticket you shared would likely obviate openmrs/openmrs-esm-core#908 too, @ibacher

[ibacher]

So I fixed that ticket and updated the distribution. Should be available on dev3 shortly.

[Vijaykv5]

@denniskigen
May I know what I need to do with this PR?

[denniskigen]

State of things following the most recent commit:

state-of-things.mp4

• The image description is now showing in the image preview UI.
• The attachments grid is now set to render 3 columns. Previously, it was set to show 4 columns. The UI would break if you had 4 attachment previews rendered in the grid as the width of the fourth item would be constrained by the max-width of the parent container element.
• The attachments app is now using the most up to date type annotations from the framework.
• The overview widget now has a loading state that's shown when data is getting fetched from the API.

[denniskigen]

@ibacher just noticed that the global property attachments.allowedFileExtensions doesn't seem configured to support any specific extensions. Do we want to configure that?

[ibacher]

Do we want to configure that?

No. It's intentionally an opt-in option.

[denniskigen]

I should probably remove this bit about the supported file types as it's misleading without any corresponding checks:

The uploader currently doesn't enforce any limitations on the allowed file types.

[denniskigen]

Thanks for working on this, @Vijaykv5. I've tacked many other useful refactors on top of your work.

[Vijaykv5]

Thank you @denniskigen :)