allagroup/alla-allaos-fullstack
Template
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

task-i

Browse Source
This commit is contained in:
phaichayon
2026-06-16 17:01:29 +07:00
parent 90ee59d388
commit 0a484e0b45
28 changed files with 6483 additions and 277 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/adr/0009-approved-document-storage-lifecycle.md
View File

@@ -3,22 +3,30 @@ accepted
Context:
Task H introduced server-side PDF generation for quotation preview, download, and approved-document persistence.
Task H.1 validated the full path with a real quotation fixture and confirmed that approved artifacts currently persist to local disk under `public/generated/...`.
Task H.1 validated the full path with a real quotation fixture and confirmed that approved artifacts originally persisted to local disk under `public/generated/...`.
Task I introduces a storage-provider abstraction and a database-backed document artifact model so approved PDFs are no longer tied to raw public paths as the source of truth.
Decision:
- Keep approved quotation PDFs on local filesystem storage for development and MVP use.
- Persist the generated file path on the quotation row via `approved_pdf_url`.
- Persist `approved_snapshot` and `approved_template_version_id` alongside the stored file path so the approved artifact can be traced back to the data and template used at generation time.
- Treat this storage model as acceptable only for local/dev and early MVP deployment, not as the final production storage architecture.
- Use a storage provider abstraction for approved quotation PDFs.
- Support a local provider for development and an S3 / MinIO-compatible provider for production-oriented deployments.
- Persist approved-document metadata in `crm_document_artifacts`.
- Persist `approved_artifact_id` on the quotation row as the primary approved-artifact reference.
- Keep `approved_pdf_url` as a compatibility field and allow `artifact:<artifactId>` references during the migration period.
- Lock approved PDF artifacts after generation and treat them as immutable-first records.
Consequences:
- Preview/download/generate-approved flows can ship now without blocking on object storage integration.
- Approved PDF persistence works with the current dashboard and static file serving model.
- Local public storage is simple, but it does not provide immutability guarantees, signed access control, retention policy, or durable storage semantics expected for long-lived production artifacts.
- Approved PDF persistence no longer depends on raw `public/generated/...` paths as the system of record.
- Secure download routes can resolve artifacts from database metadata and storage-provider reads.
- Local storage remains acceptable for development, but production-oriented deployments can move to S3/MinIO-compatible object storage without changing the quotation flow contract.
- Legacy approved PDFs stored under `public/generated/...` still require explicit migration and remain a temporary compatibility burden.
Future:
- introduce an object-storage abstraction shared by generated documents and manual attachments
- migrate legacy approved PDFs into `crm_document_artifacts`
- extend the storage abstraction to manual attachments as well as generated artifacts
- support signed URLs or another private delivery strategy where required
- define immutable approved artifact rules and whether regeneration is allowed
- add retention/cleanup policy for superseded or regenerated artifacts
- define operator-facing void/replacement workflow for immutable approved artifacts
- add retention/cleanup policy for superseded or voided artifacts
- move approved-PDF generation to an async job when post-approval auto-generation is introduced