Agreement signing form pre-fills agent's name instead of client's

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.tsx runs a useEffect that decodes the portal access token client-side to extract a contactId, then searches inspection.people for 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 to inspection.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.tsx via portalContactAndPermissionsVerification, but that resolved contact object is not passed down to AgreementSigningForm.
  • 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

  1. Correct contact source — The signing form should derive its pre-fill values from the contact resolved by portalContactAndPermissionsVerification in page.tsx, not from client-side token decoding.
  2. 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 resolved contact from portalContactAndPermissionsVerification should be passed as a prop to AgreementSigningSection and threaded down to AgreementSigningForm.
  • 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 — the populateFields useEffect should be replaced or superseded by prop-driven pre-fill from the server-resolved contact. The client-side token decode and unconditional people[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 in page.tsx; the fix threads it to the form rather than re-resolving on the client

Please authenticate to join the conversation.

Upvoters
Status

Planned

Board
🏠

Main App

Date

About 4 hours ago

Author

Linear

Subscribe to post

Get notified by email when there are changes.