Various co-sign improvements

[joeribekker]

Thema / Theme

Frontend

Omschrijving / Description

Globaal

• [ ] Het woord "mede-ondertekener" moet worden "mede-ondertekenaar"

• Bij het gebruik van een link in de mede-onderteken e-mail:

  • [ ] Verberg mede-onderteken blok op het formulier
  • [ ] Stuur een link in de mede-onderteken e-mail, die een code in de URL bevat dat het om mede-ondertekenen gaat.
  • [ ] Toon enkel het mede-onderteken blok als de URL de code van hierboven bevat (verberg dus de mogelijkheid om gewoon in te loggen)
  • [ ] Geen tussenstap om code in te voeren

• [ ] Meerdere PDFs met onderscheid in wat relevant is (tevens wel/niet betaald, wel/niet mede-ondertekend). Deze als versies opslaan.

Startpagina

• [ ] Tekstwijziging bij mede-onderteken blok: Heeft u een e-mail ontvangen om mede te ondertekenen? Start het mede-ondertekenen door in te loggen.

Mede-onderteken component

• [ ] Vraag om BSN (of selecteer partner in latere fase)

Bevestigingspagina

• [ ] Tekstwijziging titel:
• [ ] Tekstwijziging body
• [ ] Toon NIET het nummer indien links worden gebruikt
• [ ] Toon direct een knop "Nu mede-onderteken" (die de link gebruikt om mede te ondertekenen)

Bevestigings e-mail naar de indiener

• [ ] Tekstwijziging: Onderwerp moet niet "bevestiging" bevatten en ook geen referentienummer. Dit geeft de indruk dat het klaar is.
• [ ] Verwijder kopje "samenvatting" als er geen samenvatting is
• [ ] Tekstwijziging: Body

Mede-onderteken e-mail

• [ ] Tekstwijziging: Body (meer B1)
• [ ] Betere layout (kopje)

Bevestiging mede-ondertekening

• [ ] Tekstwijziging. Wellicht meer zoals de standaard bevestiging

[joeribekker]

This ticket will include:

• Removal of component and integrate it as a form-feature
• Refactor of email templating into a separately managed model (library)

[joeribekker]

@sergei-maertens will add details that we discussed.

[sergei-maertens]

Writing these down so we don't forget what was discussed last Friday

We'll build CoSign v3 and deprecate/remove v1 and v2. Now cosign is set up as a formio component, but that is a "wrong" approach since you can only ever use one such component in the entire form (which goes against the idea of a component). Implementation of requested changes is also very hard if we keep treating it as a formio component, so let's stop doing that.

• Whether cosigning is required or not will become a Form level field/configuration/flag.
• This means we can expose whether it's a co-sign form or not quite easily in the form detail endpoint
• We make entering the co-sign information something that needs to be provided on the confirmation page (similar to accepting the terms and conditions/privacy policy etc.). We store email address + (optional?) BSN of the cosigner in the submission object. Need to take security/privacy into account, so figure out if we need to hash/encrypt the BSN (depends on whether we display it in the confirmation PDF or not).
• Detecting whether links are sent in emails or not can be done by inspecting the cosign email template for the presence of the {{ form_url }} variable -> should be exposed in form detail so we can render/hide the cosign login button(s).
• Cosign components are now sometimes made conditional with logic, depending on whether the user has a partner or not, for example. We can add a logic action set_cosign_required to True | False based on some conditions. We then record on the Submission if cosign is required.

About email templates - we get various template variants, depending on whether the submissions needs cosigning/payment/.... Handling all these cases (for a subject, for example) with {% if %} statements is pretty hostile to functional administrators needing to manage this content. For that reason, we decided that we should revamp our (email) template system.

• Configure email templates as individual records. This should allow configuration of subject + body as one record. A template is semantically identified by the combination of (template_type, language) - template type is then for example submission_confirmation, cosign_request, payment_required etc.
• Code sending emails will need to understand the various combinations and how they map to the template type, look up the relevant template and render it
• Data migrations need to populate the table with initial templates that we ship, as starting points. There should be some way to ensure that all languages and template types are configured (post migrate hook?), since new types and languages can be added after this data migration was run (for existing instances).
• Email templates need to be properly validated - we need to be able to configure per type which variables/tags are expected/allowed. Some openforms.template functionality will need to be ported.
• https://github.com/maykinmedia/mail-editor should ideally be used, if required, we will further extend it to serve our needs

Some more Q & A from Slack:

• No in-between step to enter code -> pass it directly in the link from the email as query param, e.g. ?cosignSubmission=OF-123. Could also become a backend URL with a time-expiring token that automatically invalidates the link, similar to the resume form link. Details to be sorted out.
• Multiple PDF versions -> the actual/content rendering may require additional context or render modes in our node visitor (Renderer class) that actually generates the PDF content

[joeribekker]

eformulieren teksten.docx