Objective
- Ensure the PAC agreement signing form always pre-populates the signer's name and email from the correct contact — the person the portal access token belongs to, not the first person on the job.
- Prevent clients from being presented with an agreement bearing another person's name, which blocks signing and creates a credibility problem with the client.
Background
- When a client opens a PAC agreement link,
AgreementSigningForm.tsxruns auseEffectthat decodes the portal access token client-side to extract acontactId, then searchesinspection.peoplefor a matching entry to pre-fill the name and email fields. - If the match fails — or if the token doesn't carry a
contactId— the form falls back toinspection.people[0], the first person in the array. - People are added to a job in the order they're assigned. When an agent is added before the client (which happens when the agent portal link is created first from the actions dropdown), the agent occupies index 0.
- The result: the client arrives at the agreement, sees the agent's name already entered, and cannot proceed with a correctly attributed signature.
- The correct contact is already resolved server-side in
page.tsxviaportalContactAndPermissionsVerification, but that resolvedcontactobject is not passed down toAgreementSigningForm. - Name and email on the PAC agreement are controlled by ISN/FlexFund and are not editable within Attik, so field editability is not a product concern here.
Product Decisions
Locked
- Correct contact source — The signing form should derive its pre-fill values from the contact resolved by
portalContactAndPermissionsVerificationinpage.tsx, not from client-side token decoding. - Fallback behavior — The
people[0]fallback should be retained only for staff/view-only tokens where no signer contact is resolved. It should not apply when a real client contact is expected.
Scope
Frontend
src/app/client/job/[slug]/agreement/[id]/page.tsx— the resolvedcontactfromportalContactAndPermissionsVerificationshould be passed as a prop toAgreementSigningSectionand threaded down toAgreementSigningForm.src/app/client/job/[slug]/agreement/[id]/components/AgreementSigningSection.tsx— needs to accept and forward the contact prop.src/app/client/job/[slug]/agreement/[id]/components/AgreementSigningForm.tsx— thepopulateFieldsuseEffectshould be replaced or superseded by prop-driven pre-fill from the server-resolved contact. The client-side token decode and unconditionalpeople[0]fallback should be removed; the fallback scoped only to view-only/staff contexts where no contact prop is provided.
References
- Reported inspection: https://www.attik.ai/inspections/1008601807
portalContactAndPermissionsVerification— already resolves the correct contact server-side inpage.tsx; the fix threads it to the form rather than re-resolving on the client