139 lines
4.5 KiB
Markdown
139 lines
4.5 KiB
Markdown
# Technical Debt
|
|
|
|
## After Task D
|
|
|
|
### Database foreign keys
|
|
Customer, contact, and enquiry relationships are still enforced mainly in application logic.
|
|
|
|
Future:
|
|
- add FK constraints after the CRM schema settles
|
|
- review cascade behavior before enabling hard relational enforcement
|
|
|
|
### Date input UX
|
|
Several forms still use plain `YYYY-MM-DD` text/date inputs.
|
|
|
|
Future:
|
|
- move to a shared date picker pattern
|
|
- standardize timezone handling for CRM forms
|
|
|
|
### Related enquiry pagination
|
|
Customer detail can show related enquiries, but that view still has no dedicated pagination strategy.
|
|
|
|
Future:
|
|
- add paging once real data volume grows
|
|
|
|
### Follow-up activity timeline
|
|
Activity history still relies heavily on audit payloads instead of a curated domain timeline.
|
|
|
|
Future:
|
|
- build a combined activity view/service for CRM interactions
|
|
|
|
## After Task E
|
|
|
|
### Mixed tax rollup
|
|
Quotation items support per-line tax input, but summary calculation still assumes a header-centric tax model.
|
|
|
|
Future:
|
|
- support mixed-tax aggregation from actual item rows
|
|
- align document totals and reporting with per-line tax logic
|
|
|
|
### Attachment storage abstraction
|
|
Quotation attachments started as metadata-only and approved PDFs now write to local disk, but there is still no real storage abstraction.
|
|
|
|
Future:
|
|
- introduce a provider abstraction
|
|
- support upload/download lifecycle consistently across manual attachments and generated artifacts
|
|
- define migration strategy for existing local/public paths
|
|
|
|
### Revision snapshot coverage
|
|
Revision copy currently focuses on quotation header, items, customers, and topics.
|
|
|
|
Future:
|
|
- decide whether follow-ups and attachments belong in revision snapshots
|
|
- define immutable vs mutable child-data behavior across revisions
|
|
|
|
### CRM foreign keys
|
|
Core CRM tables still depend on organization-scoped validation in service code.
|
|
|
|
Future:
|
|
- add FK constraints after schema churn slows down
|
|
- review delete and soft-delete interactions first
|
|
|
|
## After Task F
|
|
|
|
### Permission sync for existing memberships
|
|
New permissions are defined in code, but old membership rows may still hold stale permission arrays.
|
|
|
|
Future:
|
|
- add a permission sync/backfill command
|
|
- provide admin tooling for role and permission maintenance
|
|
|
|
### Approval workflow configuration UI
|
|
Approval workflows are seeded and usable, but still not configurable from the dashboard.
|
|
|
|
Future:
|
|
- build workflow setup screens
|
|
- add step editing and role mapping management
|
|
|
|
### Approval notifications
|
|
Approval flow has no queue-backed notification channel yet.
|
|
|
|
Future:
|
|
- add notification jobs
|
|
- support reminders and escalation policy
|
|
|
|
## After Task G
|
|
|
|
### Document mapping editor
|
|
Template mappings are seeded and readable, but not manageable from UI.
|
|
|
|
Future:
|
|
- add mapping CRUD for admins
|
|
- support table column editing
|
|
- add draft/publish template workflow
|
|
|
|
### Product-specific template resolution
|
|
Quotation document template resolution still defaults to a coarse product selection strategy.
|
|
|
|
Future:
|
|
- define clearer rules for crane, dock door, solar, and service-specific templates
|
|
|
|
## After Task H / H.1
|
|
|
|
### Font compatibility fallback
|
|
PDF generation now uses vendored Cordia TTF files from `public/fonts`, which fixed the TTC runtime issue, but generator-side fallback normalization still remains as a safety net.
|
|
|
|
Future:
|
|
- keep validating Thai text metrics against designer output
|
|
- remove fallback normalization only after render parity is proven stable
|
|
|
|
### Local filesystem storage
|
|
Approved PDFs currently persist under `public/generated/quotations/<organizationId>/`.
|
|
|
|
Future:
|
|
- replace local public storage for production with object storage
|
|
- add signed/private delivery where required
|
|
- define backup and cleanup expectations
|
|
|
|
### Approved artifact immutability
|
|
Approved PDF persistence exists, but the lifecycle is not immutable by policy yet.
|
|
|
|
Future:
|
|
- define whether regeneration is allowed after approval
|
|
- version approved artifacts explicitly if regeneration must remain possible
|
|
- document which snapshot fields are contractual records
|
|
|
|
### Post-approval automation
|
|
Approved PDF generation is still manual by design.
|
|
|
|
Future:
|
|
- add a non-blocking auto-generation hook after final approval
|
|
- move heavy generation/retry behavior to a background job when needed
|
|
|
|
### PDF pipeline test coverage
|
|
Task H.1 added dev fixture and HTTP verification scripts, but there is still no CI-backed E2E coverage for the PDF pipeline.
|
|
|
|
Future:
|
|
- promote fixture verification into automated test coverage
|
|
- add regression checks for template mappings, storage persistence, and permission enforcement
|