Add customreceipt as alternative to simplereceipt

[standeren]

Description

Add customReceipt component as an alternative to simpleReceipt when autodeleteonprocessend is enabled.

Related Issue(s)

• closes #9548

Verification

• Manual testing
  • I have tested these changes manually
  • Creator of the original issue (or service owner) has been contacted for manual testing
  • No testing done/necessary
• Automated tests
  • Unit test(s) have been added
  • Cypress E2E test(s) have been added
  • No automatic tests are needed here
  • I want someone to help me make some tests
• User documentation @ altinn-studio-docs
  • Has been updated
  • No changes/updates needed
• Changes/additions to component properties
  • Changes are reflected in both src/layout/layout.d.ts and layout.schema.v1.json, and these are all backwards-compatible
  • No changes made
• 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

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

75.0% Coverage
0.0% Duplication

[bjosttveit]

Have you tested this manually?

[olemartinorg]

I agree with @bjosttveit here, please fill out the checklist. Having automatic tests for this functionality would be preferable. While this looks simple enough from the small amount of code changes, there might be significant implications of changes like these.

Application metadata is fetched fairly early in the runtime, and is not dependent on having an instance. The available layouts relies on knowing which process task the instance is currently in, which makes it depend on having an instance available. When auto-deletion is on, we should assume there is no instance, making the current process state undefined, thereby making it impossible to determine which layouts should be loaded, so none will be available. In essence, my theory here is that the state we need to have available here relies on data we know we won't have - so this code should never even be able to execute.

And if it does work, that probably means that app-frontend is not (correctly) deleting its local state (form data, layouts) in Redux when moving to the next process step (ending up at the receipt). That means this functionality relies on side-effect, so a refactor in something like #345 will probably cause this functionality to break. If we knowingly paint ourselves in a corner like that, we have to introduce complexity in the future to make sure this feature still works.

A simple way to test this is to fill out a form (with auto deletion of instance data), get to the receipt page, make sure the instance data is deleted, and refresh the page. That will re-load the app/instance state from backend, so if that works (and better yet; we have a cypress test to prove it), I'd be very happy greenlighting this functionality.

[bjosttveit]

Gjorde denne om til draft siden det enda er uavklart