Feat/1804 pdf preview

[adamhaeger]

Added support for displaying a text if the user is previewing the pdf before the form is submitted

Depends on backend PR: Altinn/app-lib-dotnet#904

Description

Please see acceptance criterias here: #1804

• Added printPreview action type to ActionButton config
• Rendering PDF preview if button is clicked.

Related Issue(s)

• #{1804}

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

[bjosttveit]

I see you did the same as before, I commented on the previous PR and hoped it would be solved differently this time. Anyway, my comments from last time:

1. I don't like that you are importing dev-tools components into the application. My expectation is that anything in features/devtools can be changed / broken at any time since its only meant to be a tool for developers and don't necessarily live up to the same standards of quality and support as the rest of the app. I would rather you create a separate component for this feature, or alternately moving the existing component outside of dev-tools and importing it there instead so it is more explicit that this cannot just be messed with.
2. This will just dump any errors from the backend into the modal if PDF-generation fails (as it often does), this is because it is a developer tool, and for a feature I would expect some more user friendly feed-back.
3. You are mixing two different concepts here. setPDFPreview (old preview using window.print), and PDFGeneratorPreview which uses the actual PDF generator in the backend (you can see in dev-tools that there are two different buttons). The handleClick with action === 'printPreview' will never be called because you render the PDFGeneratorPreview instead of the Button with onClick={handleClick}.

[adamhaeger]

I see you did the same as before, I commented on the previous PR and hoped it would be solved differently this time. Anyway, my comments from last time:

1. I don't like that you are importing dev-tools components into the application. My expectation is that anything in features/devtools can be changed / broken at any time since its only meant to be a tool for developers and don't necessarily live up to the same standards of quality and support as the rest of the app. I would rather you create a separate component for this feature, or alternately moving the existing component outside of dev-tools and importing it there instead so it is more explicit that this cannot just be messed with.
2. This will just dump any errors from the backend into the modal if PDF-generation fails (as it often does), this is because it is a developer tool, and for a feature I would expect some more user friendly feed-back.
3. You are mixing two different concepts here. setPDFPreview (old preview using window.print), and PDFGeneratorPreview which uses the actual PDF generator in the backend (you can see in dev-tools that there are two different buttons). The handleClick with action === 'printPreview' will never be called because you render the PDFGeneratorPreview instead of the Button with onClick={handleClick}.

Just a few comments:

1. I did not know that we dont hold the dev tools code to the same standard as the rest of the codebase. This seems like the wrong approach to me. I see no reason it should not be up to the same standards as the rest of the code. I agree it makes sense to move the preview somewhere else though.
2. Ill look into the error message.

[bjosttveit]

1. I did not know that we dont hold the dev tools code to the same standard as the rest of the codebase. This seems like the wrong approach to me. I see no reason it should not be up to the same standards as the rest of the code.

Well, its just a matter of priority, we can't prioritize everything. We don't have any tests covering dev-tools, and we don't mind if things break for a little while as it does not affect end users. If developers find some feature essential we should obviously fix it eventually though.

[sonarcloud]

Quality Gate failed

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

See analysis details on SonarQube Cloud