Conversation
…-updaterender-revert
|
|
||
| export async function generateLetterProof( | ||
| templateId: string, | ||
| lockNumber: number, |
There was a problem hiding this comment.
it may become clear as I review but why do we need to lock number to generate the proof?
There was a problem hiding this comment.
Multiple users could be generating proofs at once. To avoid confusion about whether the preview was actually initiated by the user's own request, I thought it was best to be as defensive as possible here
| fields: Object.fromEntries([ | ||
| ...customPersonalisationFields.map((f) => [ | ||
| f, | ||
| `${PERSONALISATION_FORMDATA_PREFIX}${f}`, |
There was a problem hiding this comment.
how come we need the prefix?
There was a problem hiding this comment.
To avoid the possibility that someone would use 'lockNumber', 'systemPersonalisationPackId' etc. as a custom field name in their template, and we would overwrite the values. The form data is a flat object, so we need prefix namespacing for this ideally
| personalisationParameters?.[f] ?? '', | ||
| ]), | ||
| ['__systemPersonalisationPackId', systemPersonalisationPackId ?? ''], | ||
| ['systemPersonalisationPackId', systemPersonalisationPackId ?? ''], |
There was a problem hiding this comment.
not particularly related to your current ticket but this was something I was wondering about in my ticket - this is the ID for the test recipient field right?
has this ID come from somewhere? does it have to be this specifically? is "pack" referring to the PDS data or something else?
There was a problem hiding this comment.
It's the field name on the frontend - it corresponds to a field on the render object in the database.
I called it a 'pack' ID because it idenfifies a set of example data: nhsNumber, address lines, name etc.
4 participants
Description
I removed the
use-letter-template-pollhook since it was tightly coupled to the component which uses it (PollLetterRender) and inlined the logic.Other changes
As requested by @emmagifford, changed the invalid markers 'issues' to match the original markers as closely as possible:
{d.invalid!}instead ofinvalid!.Fixed a bug with the initial render where markers without a
d.prefix would get reconstructed and rendered with the prefix.Context
Type of changes
Checklist
Sensitive Information Declaration
To ensure the utmost confidentiality and protect your and others privacy, we kindly ask you to NOT including PII (Personal Identifiable Information) / PID (Personal Identifiable Data) or any other sensitive data in this PR (Pull Request) and the codebase changes. We will remove any PR that do contain any sensitive information. We really appreciate your cooperation in this matter.