task-i
This commit is contained in:
@@ -3,136 +3,242 @@
|
||||
## 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 D.1
|
||||
|
||||
### Enquiry Own / Assigned Scope
|
||||
|
||||
Current:
|
||||
sales role ยังอ่าน enquiry ในระดับ organization scope
|
||||
|
||||
Future:
|
||||
เพิ่ม server-side policy:
|
||||
|
||||
- sales เห็นเฉพาะ enquiry ที่ตัวเองสร้าง
|
||||
- หรือ enquiry ที่ assigned ให้ตัวเอง
|
||||
- sales_manager เห็นทั้งทีม
|
||||
|
||||
Priority:
|
||||
High
|
||||
|
||||
### Legacy Business Role Backfill
|
||||
|
||||
Current:
|
||||
ระบบ runtime ใช้ CRM businessRole แล้ว แต่ DB เก่าอาจยังมี role จาก IT-CENTER
|
||||
|
||||
Future:
|
||||
ทำ one-time migration/backfill script สำหรับ memberships.businessRole
|
||||
|
||||
Priority:
|
||||
Medium
|
||||
|
||||
## 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
|
||||
|
||||
## After Task I
|
||||
|
||||
### Storage provider production rollout
|
||||
|
||||
Task I introduced a storage provider abstraction with local and S3/MinIO-compatible implementations, but the production rollout still depends on environment configuration and infrastructure ownership outside the app.
|
||||
|
||||
Future:
|
||||
|
||||
- validate real bucket policies, credentials rotation, and environment separation
|
||||
- add operational runbooks for provider misconfiguration and storage outage handling
|
||||
- add smoke checks for startup-time storage provider health
|
||||
|
||||
### Legacy approved PDF migration
|
||||
|
||||
Task I keeps compatibility for legacy `public/generated/...` approved PDFs, but those legacy files are still outside the new artifact source-of-truth model.
|
||||
|
||||
Future:
|
||||
|
||||
- add a one-time migration script from legacy local paths into `crm_document_artifacts`
|
||||
- backfill `approvedArtifactId` where possible
|
||||
- remove legacy compatibility once migration is complete and verified
|
||||
|
||||
### Artifact lifecycle policy depth
|
||||
|
||||
Approved artifacts are now immutable-first and locked after generation, but void/regeneration policy is still service-level rather than a full operator workflow.
|
||||
|
||||
Future:
|
||||
|
||||
- add explicit admin tooling for artifact void and replacement flows
|
||||
- define whether artifact voiding also clears or supersedes quotation-facing references automatically
|
||||
- document retention expectations for voided objects in object storage
|
||||
|
||||
### Secure artifact delivery model
|
||||
|
||||
Approved-PDF viewing now goes through secure server routes and storage-backed reads, but signed-url/offload behavior is not yet used.
|
||||
|
||||
Future:
|
||||
|
||||
- decide when direct signed URLs are acceptable versus mandatory server streaming
|
||||
- add response caching strategy for large artifact downloads
|
||||
- evaluate optional download-audit sampling if volume grows
|
||||
|
||||
Reference in New Issue
Block a user