Implement setting `pdfLayoutName` for a layoutSet

[nkylstad]

Description

Default PDF print layout uses the summary-mode for all existing layout-files. However, it is possible to define a custom PDF layout for a given layoutset. To do this, an app developer must set the pdfLayoutName property in Settings.json for the layoutset to the desired layout-name. This is something we should support setting in Studio.

Additional Information

Suggested approach is to add a new config panel section "PDF", as already specified in the latest sketches for the forms editor config panel. And then add a switch to that panel for page/layout settings, allowing user to set the selected layout as pdfLayoutName. See acceptance criteria section for more details on suggested solution. @Annikenkbrathen can you take a look?

Tasks

### Tasks
- [ ] UX: Design
- [ ] Implement frontend changes
- [ ] Implement backend changes if needed - endpoint for fetching and updating Settings.json file is available, so might not need to do anything here

Acceptance Criterias

• [ ] A "PDF" section is available for layouts, containing a switch that allows app developer to set the selected layout to pdfLayoutName.
• [ ] Turning on the switch for the selected layout should set the pdfLayoutName in the current layoutset's Setting.json file to the selected layout name.
• [ ] Turning off the switch for a layout that is set as pdfLayoutName should remove the pdfLayoutName property from the Settings.json file
• [ ] It should not be possible to set the pdfLayoutName property for multiple layouts.
• [ ] If the pdfLayoutName property is set for a layout that is not the selected layout, the switch should be disabled, and app developer should be informed of which layout has been set as pdfLayoutName.

[Ildest]

Reviewed this case - will ask for more information tomorrow in refinement before we proceed.

[standeren]

After a short discussion with Team Apps a suggestion is to only move (and not duplicate) the layout from order to pdfLayoutName in the settings file when setting a layout as the PDF. Also, we should consider adding the component InstanceInformation at the top of the layout automatically when the layout is transformed to a PDF.

Open question; should there be a create PDF-layout button instead of setting a predefined layout as the PDF? Feels more natural? If we still wish to support setting a predefined layout as the PDF, maybe the button for creating a PDF should be an option in addition? @UX @Annikenkbrathen

[Annikenkbrathen]

Not sure if I understood this correctly. Are you suggesting that it should be possible to chose predefined layoutset as PDF? Is this something you can do in the Process level, when creating a new layout? Could this be something you dragged in the BPMN? Or should you have the opportunity to chose a layoutset and then add as PDF in the settings with a button for example?

I'm not entirely sure which settings you need to configure and where, I notice.

[standeren]

There is only a single layout from a layoutset that can be set as a PDF for that particular layoutset. This is the case since the apps are generating separate PDFs for each data task in the process. So in my suggestion I imagine a PDF accordion being visible in the process config-panel for those tasks that have connected layoutsets to them. And inside the PDF accordion there is maybe som information on what will be the autogenerated PDF if you not wish to make your own. And a button to add a dedicated PDF layout (which will create a new, empty layout in the lage-page that is listed below the other layouts and maybe in a different color or with a PDF icon as @framitdavid suggested and with a auto-added InstanceInformation component). Below that button I imagine a text that tells you to assign one of your existing layouts as a PDF and a select dropdown with all the layouts to select from. Doing this will move the layoutname from order to pdfLayoutName in Settings file and visualize the layout in the same way in Lage-page as when adding a new, empty one, except in this case the PDF-layout will contain all the components as the layout originally did including the InstanceInformation component at the top.

We will also need to display different options after assigning a layout as the PDF;

1. Delete the PDF-layout completely --> which will delete the layout from the layouts folder and remove the pdfLayoutName property in the Settings file
2. Convert the PDF layout back to a regular layout --> which will not delete the layout from the layouts folder, but only remove the pdfLayoutName property in the Settings file and move the layout-name back to order in the settings file

Hope it make sense 😅 And again, not sure that process is the best place to have this setting, but my intuition says so for now 😅

[standeren]

@nkylstad @Annikenkbrathen and I also discussed wether the PDF-configs on component-level should be disabled for all other layouts than the designated PDF-layout if there is a designated PDF-layout. Any thoughts about that? 😊

[standeren]

New suggestion is to separate all these pdf-related actions.

The add new, empty designated PDF is suggested to be a button below the Legg til ny side in Lage-siden for a layoutset.

• when pressing it you see a input tex field to assign a name and information of what this means; default PDF genereated from ALL layouts in the set will no longer be generated, and potential layouts that are added to the excludeFromPdf will be meaningless.
• Include options when deleting the PDF layout --> 1 og 2 mentioned above

While the excludeFromPdf and Assign existing layout as only designated PDF kan be switches in the page config panel under a PDF accordion. Setting the particular layout as pdf will move it visually to a PDF at the bottom of the layouts and the excludefromPDF will be disabled. Also, all other layouts will now show disabled excludeFromPdf switches and information that selecting this layout as a PDF will disable a current PDF layout (delete the current or convert it back to layout?)

This section can also include what components from the layout to exclude from pdf. These will ba added to the array of all components from the layoutset in the settingsfile to exclude from pdf.

[Annikenkbrathen]

(Disussion points since we cancelled the meeting @framitdavid @nkylstad @bjosttveit @Edavda @RonnyB71 @Magnusrm @standeren )

After looking deeper into the issue, we got some questions that need to be discussed:

• Is it desired to be able to create an empty PDF page where you can add your own content independently of what you have in the layout set? If so, why is this desired?

• We were also a bit uncertain about the need to "convert" a page from a regular form page to a PDF. Is there a point when we have the option to create an empty PDF page from the start? (It might be useful if someone started in the wrong place, but is that the only reason?)

• Can we implement a feature to copy the content from the layout set (the components from the pages) and choose which ones should be displayed/not displayed in the new custom PDF, then convert it to a PDF and continue adding new components? Here we believe there might be a need to display some content from the layout set in the PDF, but also add custom content, for example.

• How do the users know that they want to create a custom PDF without having seen what is auto-generated by us? We see that it is possible to preview the PDF in the iframe under the tool panel for app preview. Is this a function we can get in Studio as well? That we can add a button that does the same, or opens their preview?

From our side, we see two ways to solve custom PDF:

We believe that the first one will be the most user-friendly and useful based on the advantages we can see and the cases we can think of. You might have different insights🤔

1. PDF settings is a dedicated area at the layoutset level where you set up what you want to include before you convert it to a new PDF page.

2. Ability to set up everything at the page level. You can either convert an existing page to a PDF, that is a copy of all the components, then edit it as you want by removing and adding new components like a regular page. Should you then be able to convert more than one page to the same PDF to have full flexibility? And can you chose too add a PDF page that is empty instead?

Both solutions should include the possibility to see the auto-generated PDF.

[nkylstad]

Is it desired to be able to create an empty PDF page where you can add your own content independently of what you have in the layout set? If so, why is this desired?

Probably not, although there might be a wish for some informative texts in the receipt PDF that are not there in the form pages. I'm sure someone from team apps might have some more insight here, but my understanding is that most of the content will still be summary-components referring to components within the layoutset. So the only addition I see is informative texts, and possibly having a different order/grouping of components. Apart from this, setting components/pages to be excluded from PDF might be enough.

We were also a bit uncertain about the need to "convert" a page from a regular form page to a PDF. Is there a point when we have the option to create an empty PDF page from the start? (It might be useful if someone started in the wrong place, but is that the only reason?)

Again probably not. I think this "need" came from the payment task layout. But being able to copy content into the PDF layout as suggested would cover that nicely.

Can we implement a feature to copy the content from the layout set (the components from the pages) and choose which ones should be displayed/not displayed in the new custom PDF, then convert it to a PDF and continue adding new components? Here we believe there might be a need to display some content from the layout set in the PDF, but also add custom content, for example.

That would be cool! Maybe something we could delay to a second iteration of this, depending on how far Team Apps have come with the new summary component - my understanding is that that component could take over some of this functionality. Someone from team apps would need to comment on that.

How do the users know that they want to create a custom PDF without having seen what is auto-generated by us? We see that it is possible to preview the PDF in the iframe under the tool panel for app preview. Is this a function we can get in Studio as well? That we can add a button that does the same, or opens their preview?

Agreed. Some button to open it directly, or at the very least a shortcut to open it in preview, would be a great feature!

From our side, we see two ways to solve custom PDF:

I definitely prefer option 1 here as well!

[Annikenkbrathen]

We're waiting for a demo of Summary 2.0 from the apps team before we decide how to solve it.

[framitdavid]

@standeren I suggest we meet later this week to split this issue into multiple parts and clarify our needs, to simplify the implementation process (implement it more step-by-step). We talk short about it on sprint plan today.

[framitdavid]

Let's keep it simple and stupid for now. Let's just make it possible to mark a page within a layout set as a PDF page. When the user opens another page and clicks on the "use as pdf", then we can display f.ex "Page 3 is already added as PDF page, do you want to change to this page". 😊 Suggest that we add a pdf-icon to the page accordion if the page is marked as pdf-page.

If our user needs more features, let's implement that when we know more about the use cases.

[Annikenkbrathen]

Good suggestion @framitdavid !👏🏻In addition, can we open an issue to look into the preview button? I still think it's important to allow users to see how the PDF will look, both for the general PDF and when a page is added as a PDF