[DSpace-CRIS] Download button & Allow authors to download restricted files

[FrancescoMolinaro]

References

• Fixes [DSpace-CRIS] Download button & Allow authors to download restricted files DSpace#12169
• Relates to: Feature differences #12 and Feature differences #13

Description

Add new way of rendering download link in item page, the new UI component can be activated via the config:

showDownloadLinkAsAttachment

inside the layout config in default.app.config.ts.

This PR adds a route guard that allows to run the required authorization checks also on direct download links, supporting in this way the Feature differences #13, which has been implemented on DSpace/DSpace#11964 , even though is not strictly depending on that rest PR.

The metadata to be visualized in the attachment box are handled with a separated config param:

advancedAttachmentRendering

Which allows granural control on which information to show in the template.

In addition a new route guard has been added for the bitstream download path, so that we can check the authorization before loading the page and handle in advance eventual authorizations needed.

On the rest side the canDownload authorization feature will be enhanced to allow authors the download of restricted items.

Instructions for Reviewers

The new config has been set as true for the time being so that every link in item page will be displayed with the new component.
The positioning was also adapted from the left side of the page to the right one, so to use the wider space for the additional informations.

List of changes in this PR:

Add new UI component and related configs
Add new guard for bitsream download path

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You do not need to complete this checklist prior creating your PR (draft PRs are always welcome).
However, reviewers may request that you complete any actions in this list if you have not done so. If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• My PR is created against the main branch of code (unless it is a backport or is fixing an issue specific to an older branch).
• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes ESLint validation using npm run lint
• My PR doesn't introduce circular dependencies (verified via npm run check-circ-deps)
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• My PR aligns with Accessibility guidelines if it makes changes to the user interface.
• My PR uses i18n (internationalization) keys instead of hardcoded English text, to allow for translations.
• My PR includes details on how to test it. I've provided clear instructions to reviewers on how to successfully test this fix or feature.
• If my PR includes new libraries/dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR includes new features or configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.

[tdonohue]

@FrancescoMolinaro : Same here, please specify in the PR description which DSpace-CRIS differences this PR implements/relates to.

[github-actions]

Hi @FrancescoMolinaro,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

[tdonohue]

@FrancescoMolinaro : Just to verify, does this PR require any backend PR? Or is it standalone? It's unclear to me whether this requires specific backend changes to work.

[FrancescoMolinaro]

Hi @tdonohue , sorry for missing to specify it, this PR is mainly a UI variant of the normal link and it is indeed standalone.

[lgeggleston]

@aprilherron General reminder for all new feature PRs currently under review: there is still a possibility of getting this into 10.0, in case you have the capacity to complete the review at the moment. Feature merge deadline will be Friday 3/27. Thank you!

[aprilherron]

Review notes:

Config syntax

Feature is enabled by default.
To turn it off, use config:

layout:
  showDownloadLinkAsAttachment: false

Tests

1. If it is enabled the new bitstream view shows on the item-page.

2. If it is disabled the new bitstream view doesn't show on the item-page
   => But the normal download links DO NOT appear (marked spot in code for fix in code-review)

3. Make sure every field in the bitstream-view is correct:

   • Name = dc.title
   • Size = the same in edit > bitstream
   • Format = the same in edit > bitstream
   • Checksum = the same as in the DB

4. Multiple bitstream:

   • Both bitsteams still have the correct field values
   • The each download button downloads the correct bitstream

5. Unexpected values:

   • Creating a bitstream with a huge filename doesn't overflow the bitstream-view

6. Authorization:

   • Anon users can see and use the bitstream-view -> if the bitstream is openAccess
   • Normal users can see and use the bitstream-view -> if the bitstream is openAccess
   • Admin users can see and user the bitstream-view -> if the bitstream is openAccess
   • Anon users can see and use the bitstream-view, but are unable to download the bitstream. They can request a copy instead -> if the bitstream is not openAccess
   • Normal users can see and use the bitstream-view, but are unable to download the bitstream. They can request a copy instead -> if the bitstream is not openAccess
   • Admin users can see and use the bitstream-view, and are able to download the bitstream -> if the bitstream is not openAccess

7. Security:

   • Valid html in the filename <b>test.pdf</b> does not render as HTML

[FrancescoMolinaro]

Hi @aprilherron , thanks for the feedback, I have set the property as false by default so that the new layout will be optional. In addition I have also fixed the issue with the missing default download link and implemented some test to enforce the behavior, now it should work as expected, thanks again for the review.

[tdonohue]

@aprilherron : If you can find time to rereview this (based on the updates), I'd appreciate it. Please also remember to explicitly give the PR a "+1" if you feel it's working well and ready to be merged.

@FrancescoMolinaro : I've yet to review/test this, but we may want to consider enabling this by default if it accurately fixes #3384 (as that's a long standing accessibility/usability issue). That said, I'll try to give this a test tomorrow to see if this should be enabled by default.

[aprilherron]

Bug in untyped-item view has been addressed. This PR looks good to be merged 👍

[tinsch]

@FrancescoMolinaro I ran some response time performance tests on your branch, because I recently worked on a similar area of the code (#5028). I found out that your new code runs much faster on larger page sizes with showDownloadLinkAsAttachment enabled than the 'old' code for the bitstream download links. Congrats 👏🎉

Could you maybe explain a bit what you are doing with this bitstream route guard, and if we could also use it for the 'normal' bitstream download links?

Here is a diagram from my performance tests, so that you can see how much better the new feature performs:

[github-actions]

Hi @FrancescoMolinaro,
Conflicts have been detected against the base branch.
Please resolve these conflicts as soon as you can. Thanks!

[tdonohue]

@FrancescoMolinaro : Could you quickly rebase this PR? It appears to have gained merge conflicts after the merger of #5112

[FrancescoMolinaro]

Hi @tinsch , thanks for the feedback much appreciated, the bitstream route guard is currently already active for all the downloads as it runs on the download page indipendently from the property showDownloadLinkAsAttachment.
It's purpose is to check if the user is authorized to access the download path, the main point is to check authorizations on direct link, e.g. accessing a link like https://demo.dspace.org/bitstreams/55113c70-2f96-4f66-acbc-692987fcedcc/download from a shared link.

I believe that what makes the file-download-link.component.html slow to render on pages, is the template of the component itself, which creates many unnecessary subscriptions, creating the risk of memory leaks.

I have made a commit to change this as I think is a good improvment in any case, you can check the last commit of this PR for confirmation on your tests, hopefully performaces will be better also with the property set to false.

[tinsch]

Thanks a lot! I will look into it and retest it 👍

[tdonohue]

@FrancescoMolinaro : I gave this a review and test today. Overall, it works, but I've found some issues in the code which I think need cleanup/correction (see inline below).

I also have a few basic questions here:

1. I don't understand how to configure advancedAttachmentRendering > metadata fields, as the examples provided in config.example.yml seem to be invalid.
2. I also don't see how this PR is providing authors with the ability to download restricted files. Is that provided via a backend PR? If so, which backend PR does this feature require?

I have been able to verify that the basics of rendering bitstreams in a list with a download button works properly.

[tinsch]

Thanks a lot! I will look into it and retest it 👍

I ran the performance tests again, and the results are nearly the same now with and without the new showDownloadLinkAsAttachment feature enabled. Both better than on current main. Thanks a lot! 👏

[FrancescoMolinaro]

Hi @tdonohue , regarding the functionality that makes possible for authors to download restricted files the logic can be found on DSpace/DSpace#11964, it has been included in the same PR of the edit in submission style.
The frontend PR is not necessarily depending on that one as the code doesn't add any extra check, but adds a route guard that allows to run the required checks also on direct download links.

I will update the description adding this information.

[tdonohue]

@FrancescoMolinaro : Thanks for all the updates! I'm nearly a +1 to this PR. Almost everything works well. However, I'm not able to get the metadata settings to work properly. See inline comment below.

[tdonohue]

These metadata settings don't appear to work for me? For example, if I remove some of the fields like this:

layout:
  showDownloadLinkAsAttachment: true
  metadata:
    - name: dc.title
      type: metadata
      truncatable: false
    - name: format
      type: attribute

I'd expect to then no longer see the checksum and size in the display. However, I still see the same display as before.

Am I misunderstanding how these settings should work?

[FrancescoMolinaro]

Hi @tdonohue , I think you are missing a level of the configuration, the metadata config are inside the advancedAttachmentRendering property, I have tested with the following config and seems working as expected:

layout:
  showDownloadLinkAsAttachment: true
  advancedAttachmentRendering:
    metadata:
      - name: dc.title
        type: metadata
        truncatable: false
      - name: format
        type: attribute

[tdonohue]

Ah, my mistake! I'll retest today then and get this PR merged

[tdonohue]

Thanks @FrancescoMolinaro ! I retested today and verified it works well (now that I'm using the correct configuration)! Thanks again for correcting my mistake :)

[tdonohue]

👍 Thanks @FrancescoMolinaro ! This all looks great to me now. Retested today and it's all working well.

As with all other DSpace-CRIS merger PRs, I'm flagging this with "needs documentation" until documentation can be added to https://wiki.lyrasis.org/display/DSDOC10x