Add support for new attachment API and improve UX for error messages

[bjosttveit]

Description

Will now use the new attachment API if the backend version is up to date. Since the new API can make changes to form data, validations, and instance data we have to upload attachments in series instead of in parallel (if multiple are selected at the same time) to prevent race conditions. However, it will gather all of the changes and update the state only once at the end. This could really use some cypress tests to verify that form data etc. is updated correctly, but its a lot of set up, and I cannot spend that much more time on this right now.

Errors with uploading a file is no longer showed in a toster (only if you drag more files than allowed, you still get a toaster saying you selected too many files), but is shown below the fileupload component, the user needs to close the alert for it to disappear. Attachments which fail to upload are stored in the node-state instead of the react-component's state so that they don't disappear when switching pages. It will however disappear on refresh since nothing gets stored in the backend.

This, together with Altinn/app-lib-dotnet#850 deals with some of the issues in #2706. Specifically, enabling updating the form data / validations and the app frontend getting these changes as well as improved UX for error messages that caused the upload to be rejected.

This is what it looks like now. Long filenames are truncated in the middle.

If there are multiple issues with an attachment, it will be shown as a list. If there are more than 3 issues you have to expand to show them all so that it does not immediately take up a lot of space if the list is very long.

Related Issue(s)

• closes Use new endpoint for POST when saving attachments #2596
• closes Give user more time to read validation issues on file upload #1992
• closes FileUpload - Attachment box gets highlighted with red indicating error for allowed content type #2012

Verification/QA

• Manual functionality testing
  • I have tested these changes manually
  • Creator of the original issue (or service owner) has been contacted for manual testing (or will be contacted when released in alpha)
  • No testing done/necessary
• Automated tests
  • Unit test(s) have been added/updated
  • Cypress E2E test(s) have been added/updated
  • No automatic tests are needed here (no functional changes/additions)
  • I want someone to help me make some tests
• UU/WCAG (follow these guidelines until we have our own)
  • I have tested with a screen reader/keyboard navigation/automated wcag validator
  • No testing done/necessary (no DOM/visual changes)
  • I want someone to help me perform accessibility testing
• User documentation @ altinn-studio-docs
  • Has been added/updated
  • No functionality has been changed/added, so no documentation is needed
  • I will do that later/have created an issue
• Support in Altinn Studio
  • Issue(s) created for support in Studio
  • This change/feature does not require any changes to Altinn Studio
• Sprint board
  • The original issue (or this PR itself) has been added to the Team Apps project and to the current sprint board
  • I don't have permissions to do that, please help me out
• Labels
  • I have added a kind/* label to this PR for proper release notes grouping
  • I don't have permissions to add labels, please help me out

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 Security Hotspot
41.5% Coverage on New Code (required ≥ 45%)
22.47% Condition Coverage on New Code (required ≥ 45%)

See analysis details on SonarQube Cloud

[olemartinorg]

@bjosttveit Some questions before I go into reviewing the actual code:

However, it will gather all of the changes and update the state only once at the end.

Will it handle failures, then? What about timeouts, i.e. you internet speed drops to zero (or you upload a gigantic attachment). Will you risk losing out on that state update for previously uploaded attachments if you (for example) navigate to another page in the meantime?

Long filenames are truncated in the middle.

Will you still be able to see the full filename on hover?

If there are more than 3 issues you have to expand to show them all so that it does not immediately take up a lot of space if the list is very long.

Nice! Should this be a button instead of a link, maybe? 🤔

[bjosttveit]

Will it handle failures, then? What about timeouts, i.e. you internet speed drops to zero (or you upload a gigantic attachment).

The upload itself should not throw any uncaught exceptions. The promise for uploading each file has a .then which adds a success result and updates the intermediate state, and a .catch which adds a failure result (and does not update the intermediate state). So in theory any number of attachments failing to upload for any reason should not affect successful uploads.

Will you risk losing out on that state update for previously uploaded attachments if you (for example) navigate to another page in the meantime?

What do you mean by navigate to another page? Navigating within the app should not affect things. The FileUpload component simply calls the (async) function without awaiting it or expecting a return value. All of the state updates are handled by the attachmentplugin (store) and propagate back to the component through hooks (as it was before).

Navigating away (like refreshing) will maybe cancel pending requests? But you would also get the updated form data for what has already completed when loading I guess.

Will you still be able to see the full filename on hover?

Yes

Nice! Should this be a button instead of a link, maybe? 🤔

It is a button 😄 (variant tertiary)

[olemartinorg]

Good stuff! 💪