Print-out generation PDF MVP3

GGunnar commented 5 years ago

PO Statement

Deliver PDF print-out based on PoC in #1315.

The pdf in MVP3 will be a less desired version. The pdf will be more complex at a later point. (Improvements to PDF generation #2320)

In scope:

Print out generation when archiving and available in Inbox
- As an and user I want the same pp independent of what device/channel I have used to submit service-instance
- As a service developer I want the format of generated print to be pdf/a so that it meets public requirements/recommendations and is widely usable/acceptable.
WCAG 2.1, or similar, compliant pdf
- https://www.w3.org/TR/WCAG20-TECHS/pdf
Possible to download for app owners
Available on receipt page both when archiving and opening an archived instance
PDF layout is auto generated based on form layout and submitted data
All "components" in form layout will be presented. No dynamics is used in generating pdf.
Only visual pilot "innsendingstjenester" is supported (form layout).

Out of scope for mvp3

possible for service/app owner to change PDF layout directly in code repo (could be suspended to early post-MVP if necessary)
Server side dynamic rendering.
Create and display PDF when user wants to get a view of the content before submitting (like todays platform)

Tech statement

"pdf" should be a new independent component in Altinn Platform.
"pdf" should probably also be a seperate github repository.
PDF/A standard

Security considerations

Beware of input validation when executing the pdf generator (if external process)
Prevent injection of malicious code into the PDF document
Third party SCA tools must detect the java application with dependencies

Acceptance criteria

PDF/A standard
As an end user I want the printout to contain all information presented to me during processing of service-instance and information I have added during process so that I can document what has been done and submitted. Note: Not important that pp is aesthetically close to service-instance processed on device, but it must be clearly recognisable, that is data from processing must match with pp.
- Important note from a pilot developer: When we generate the PDF it is important that all information in an input field is included and not cut off e.g. if the text is too long to be shown in the field in the digital form. They have internal systems that uses only the pdf as input and the consequences can be big if not all information is displayed correctly.
As an and user I want the same pp independent of what device/channel I have used to submit service-instance
As a service owner I want to be able to receive PDF-versions of service-instances. Note: Today's functionality should be maintained in other words. (Many big service owners generate PDF themselves based on XML on most services, but not all. Smaller serice owners receive PDF from us)
- NOTE FROM PO: Can be postponed to post-mvp if demands large work.

Tasks

[x] Is this issue labeled with a correct area label?
[x] Analysis complete
[x] Issues is created
[x] QA has been done

sarahwoodhouse commented 5 years ago

Important note from a pilot developer: When we generate the PDF it is important that all information in an input field is included and not cut off e.g. if the text is too long to be shown in the field in the digital form. They have internal systems that uses only the pdf as input and the consequences can be big if not all information is displayed correctly.

lvbachmann commented 4 years ago

All issues in epic closed, and sufficiently tested. Thus closing the epic.

Altinn / altinn-studio