Document Link Management Refactoring

[mahid797]

Due to unclear initial requirements, our current link management has several shortcomings in both code quality (e.g., reliance on numeric toggles, poor separation of concerns) and missing key features that should be part of the application. This parent issue tracks all related sub‐issues to ensure a coherent, professional, and future‐proof architecture.

Overview

1. Link Management Gaps

   • Numeric toggles (e.g., requiredUserDetailsOption) hamper flexibility; we want dynamic visitor fields in JSON.
   • Existing code has ephemeral styling, minimal typed models, and inconsistent naming.
   • The “Link Creation” flow is partially incomplete (e.g., the “SendingAccordion,” emailing placeholders, and missing expansions).

2. Refactoring Objectives

   • Server: Switch to minimal JSON keys in DocumentLink.visitorFields, rely on visitorFieldsConfig for labeling/types, rename Link → DocumentLink, and store visitor submissions in DocumentLinkVisitor.
   • Document Access Client: Overhaul /links/[linkId] → /documentAccess/[linkId] with dynamic forms, Tanstack Query hooks, and analytics placeholders.
   • Link Creation Client: Provide a typed, flexible “CreateLink” modal, remove numeric toggles in favor of checkboxes, unify the emailing placeholders in “SendingAccordion,” and finalize the shareable link UI.

3. Three Main Issues

   1. Document Access Feature (Public Links) – Server Side Refactoring
      • Focuses on schema changes (Link → DocumentLink, LinkVisitors → DocumentLinkVisitor), dynamic visitorFields, and ownership clarifications.
   2. Document Access Feature (Public Links) – Client Side Refactoring
      • Migrates the old /links/[linkId] to /documentAccess/[linkId], integrates dynamic visitor fields, inline PDF viewing, and analytics.
   3. Link Creation Feature – Client Side Refactoring
      • Overhauls CreateLink.tsx (typed models, dynamic checkboxes), introduces useCreateLink, and refactors “SendingAccordion” for email placeholders or contact selection.

4. Expected Outcome

   • A professional, DRY architecture where each sub‐issue completes a necessary layer of the refactoring.
   • Clear synergy between server and client, ensuring any future expansions (e.g., advanced analytics or fully dynamic user-defined fields) can be done without major rewrites.

---

💡 Important: Please read the Development Guidelines before starting work on these issues

Bluewave Datahall Development Guide

References

• Server-Side: Document Access Feature (Public Links) – Server Side Refactoring #216
• Client-Side:
  1. Document Access Feature (Public Links) – Client Side Refactoring #217
  2. Link Creation Feature – Client Side Refactoring #218

Note

It is strongly recommended to review all related issues—server and client—in their entirety before starting any individual sub‐issue. This ensures a complete understanding of the design changes and avoids duplicative or misaligned work.

By addressing these three major issues in tandem under this parent issue, we ensure the Link Management system evolves into a fully functional, easily maintainable, and scalable solution.