Add DocumentLinkVisitor with JSON‐Based Visitor Data

[mahid797]

We want a separate DocumentLinkVisitor table (renamed from LinkVisitors) that stores each
visitor’s submitted data as JSON. This allows maximum flexibility for future additions (e.g., phone,
address, custom fields). We also rename columns for consistency (firstName, lastName, etc.) and
track “visitedAt” rather than “createdAt.”

Goals & Scope

• Rename LinkVisitors → DocumentLinkVisitor.

• Rename columns:

  • linkId → documentLinkId
  • createdAt → visitedAt
  • Make naming consistent across the schema for all tables—either underscore
    (first_name,last_name) or camelCase (lastName,firstName).

• Add a JSON column (visitorData) for storing dynamic visitor field submissions.

• Decide if we also keep dedicated firstName, lastName, email columns or if everything
  (including name/email) moves into JSON.

Detailed Tasks

1. Rename Model

   • In schema.prisma, rename LinkVisitors to DocumentLinkVisitor.

2. Convert to JSON Storage

   • Use visitorFieldsConfig to validate incoming visitor data before writing to visitorData.

   • Add visitorData Json? to store user‐submitted data. Example:

     { "name": "Alice", "email": "[email protected]" }

   • Use the same visitorFieldsConfig to verify that submitted fields are valid keys before
     writing them to visitorData.

   • We can keep name/email columns if we want quick queries, or we can remove them entirely.

3. Field Renames (If Keeping Name/Email Columns)

   • first_name → firstName, last_name → lastName, email → email.
   • createdAt → visitedAt for clarity.

4. Update Code & Migrations

   • Adjust the LinkService (or DocumentLinkService) methods that create visitor records.
   • If we keep name/email columns but also store them in JSON, ensure they stay in sync (or
     consider removing them).
   • Migrate existing data from LinkVisitors into DocumentLinkVisitor.

5. Future Growth

   • With visitorData in place, new fields (phone, address, etc.) can be stored seamlessly.
   • The front end sees which fields are required (via DocumentLink.visitorFields), and the server
     logs the submission in visitorData.

Acceptance Criteria

• DocumentLinkVisitor table (renamed from LinkVisitors) is present in the schema.
• Columns are renamed (documentLinkId, visitedAt, etc.).
• A JSON field (visitorData) is included to store the user’s dynamic data.
• Migrations complete successfully, with old data migrated to new columns if needed.
• The backend API that logs a visitor (e.g., POST /public_links/[linkId]/access) now writes to
  visitorData.
• If name/email columns remain, confirm they are updated consistently with the JSON data or
  removed if not needed.
• Frontend uses the same config to dynamically render checkboxes and input fields with correct
  labels and types.
• Any invalid field keys sent from the frontend are rejected by the backend with appropriate
  error messages based on visitorFieldsConfig.

---

Notes

• After these schema changes, the frontend can rely on visitorFields from DocumentLink to
  dynamically decide which fields to request, then store them in DocumentLinkVisitor.visitorData.
• The server doesn’t store labels or input types—only the minimal flags or list of field keys.