251126:1200 แก้ไข document-numbering:ข้อกำหนด, ตาราง
This commit is contained in:
admin
@@ -0,0 +1,777 @@
|
||||
# 📝 **Documents Management System Version 1.4.4: Application Requirements Specification**
|
||||
|
||||
**สถานะ:** FINAL-Rev.04
|
||||
**วันที่:** 2025-11-26
|
||||
**อ้างอิงพื้นฐาน:** v1.4.3
|
||||
**Classification:** Internal Technical Documentation
|
||||
|
||||
## 📌 **1. วัตถุประสงค์**
|
||||
|
||||
สร้างเว็บแอปพลิเคชันสำหรับระบบบริหารจัดการเอกสารโครงการ (Document Management System - DMS) แบบครบวงจร ที่เน้นความปลอดภัยสูงสุด ความถูกต้องของข้อมูล (Data Integrity) และรองรับการขยายตัวในอนาคต (Scalability) โดยแก้ไขปัญหา Race Condition และเพิ่มความเสถียรในการจัดการไฟล์และ Workflow
|
||||
|
||||
- มีฟังก์ชันหลักในการอัปโหลด จัดเก็บ ค้นหา แชร์ และควบคุมสิทธิ์การเข้าถึงเอกสาร
|
||||
- ช่วยลดการใช้เอกสารกระดาษ เพิ่มความปลอดภัยในการจัดเก็บข้อมูล
|
||||
- เพิ่มความสะดวกในการทำงานร่วมกันระหว่างองกรณ์
|
||||
- **เสริม:** ปรับปรุงความปลอดภัยของระบบด้วยมาตรการป้องกันที่ทันสมัย
|
||||
- **เสริม:** เพิ่มความทนทานของระบบด้วยกลไก resilience patterns
|
||||
- **เสริม:** สร้างระบบ monitoring และ observability ที่ครอบคลุม
|
||||
|
||||
## 🛠️ **2. สถาปัตยกรรมและเทคโนโลยี (System Architecture & Technology Stack)**
|
||||
|
||||
ใช้สถาปัตยกรรมแบบ Headless/API-First ที่ทันสมัย ทำงานทั้งหมดบน QNAP Server ผ่าน Container Station เพื่อความสะดวกในการจัดการและบำรุงรักษา
|
||||
|
||||
**Domain:** `np-dms.work`, `www.np-dms.work`
|
||||
**IP:** 159.192.126.103
|
||||
**Docker Network:** ทุก Service จะเชื่อมต่อผ่านเครือข่ายกลางชื่อ `lcbp3` เพื่อให้สามารถสื่อสารกันได้
|
||||
|
||||
### **2.1 Infrastructure & Environment:**
|
||||
|
||||
- **Server:** QNAP (Model: TS-473A, RAM: 32GB, CPU: AMD Ryzen V1500B)
|
||||
- **Containerization:** Container Station (Docker & Docker Compose) ใช้ UI ของ Container Station เป็นหลัก ในการ configuration และการรัน docker command
|
||||
- **Development Environment:** VS Code/Cursor on Windows 11
|
||||
- **Data Storage:** `/share/dms-data` บน QNAP
|
||||
- **ข้อจำกัด:** ไม่สามารถใช้ .env ในการกำหนดตัวแปรภายนอกได้ ต้องกำหนดใน docker-compose.yml เท่านั้น
|
||||
|
||||
### **2.2 การจัดการ Configuration (ปรับปรุง):**
|
||||
|
||||
- ใช้ `docker-compose.yml` สำหรับ environment variables ตามข้อจำกัดของ QNAP
|
||||
- **Secrets Management (ใหม่):**
|
||||
- ห้ามระบุ Sensitive Secrets (Password, Keys) ใน `docker-compose.yml` หลัก
|
||||
- ต้องใช้ไฟล์ `docker-compose.override.yml` (ที่ถูก gitignore) สำหรับ Inject Environment Variables ที่เป็นความลับในแต่ละ Environment (Dev/Prod)
|
||||
- ไฟล์ `docker-compose.yml` หลักให้ใส่ค่า Dummy หรือว่างไว้
|
||||
- **แต่ต้องมี mechanism สำหรับจัดการ sensitive secrets อย่างปลอดภัย** โดยใช้:
|
||||
- Docker secrets (ถ้ารองรับ)
|
||||
- External secret management (Hashicorp Vault) หรือ
|
||||
- Encrypted environment variables
|
||||
- Development environment ยังใช้ .env ได้ แต่ต้องไม่ commit เข้า version control
|
||||
- ต้องมี configuration validation during application startup
|
||||
- ต้องแยก configuration ตาม environment (development, staging, production)
|
||||
|
||||
### **2.3 Core Services:**
|
||||
|
||||
- **Code Hosting:** Gitea (Self-hosted on QNAP)
|
||||
- Application name: git
|
||||
- Service name: gitea
|
||||
- Domain: `git.np-dms.work`
|
||||
- หน้าที่: เป็นศูนย์กลางในการเก็บและจัดการเวอร์ชันของโค้ด (Source Code) สำหรับทุกส่วน
|
||||
|
||||
- **Backend / Data Platform:** NestJS
|
||||
- Application name: lcbp3-backend
|
||||
- Service name: backend
|
||||
- Domain: `backend.np-dms.work`
|
||||
- Framework: NestJS (Node.js, TypeScript, ESM)
|
||||
- หน้าที่: จัดการโครงสร้างข้อมูล (Data Models), สร้าง API, จัดการสิทธิ์ผู้ใช้ (Roles & Permissions), และสร้าง Workflow ทั้งหมดของระบบ
|
||||
|
||||
- **Database:** MariaDB 10.11
|
||||
- Application name: lcbp3-db
|
||||
- Service name: mariadb
|
||||
- Domain: `db.np-dms.work`
|
||||
- หน้าที่: ฐานข้อมูลหลักสำหรับเก็บข้อมูลทั้งหมด
|
||||
- Tooling: DBeaver (Community Edition), phpmyadmin สำหรับการออกแบบและจัดการฐานข้อมูล
|
||||
|
||||
- **Database Management:** phpMyAdmin
|
||||
- Application name: lcbp3-db
|
||||
- Service: phpmyadmin:5-apache
|
||||
- Service name: pma
|
||||
- Domain: `pma.np-dms.work`
|
||||
- หน้าที่: จัดการฐานข้อมูล mariadb ผ่าน Web UI
|
||||
|
||||
- **Frontend:** Next.js
|
||||
- Application name: lcbp3-frontend
|
||||
- Service name: frontend
|
||||
- Domain: `lcbp3.np-dms.work`
|
||||
- Framework: Next.js (App Router, React, TypeScript, ESM)
|
||||
- Styling: Tailwind CSS + PostCSS
|
||||
- Component Library: shadcn/ui
|
||||
- หน้าที่: สร้างหน้าตาเว็บแอปพลิเคชันสำหรับให้ผู้ใช้งานเข้ามาดู Dashboard, จัดการเอกสาร, และติดตามงาน โดยจะสื่อสารกับ Backend ผ่าน API
|
||||
|
||||
- **Workflow Automation:** n8n
|
||||
- Application name: lcbp3-n8n
|
||||
- Service: n8nio/n8n:latest
|
||||
- Service name: n8n
|
||||
- Domain: `n8n.np-dms.work`
|
||||
- หน้าที่: จัดการ workflow ระหว่าง Backend และ Line
|
||||
|
||||
- **Reverse Proxy:** Nginx Proxy Manager
|
||||
- Application name: lcbp3-npm
|
||||
- Service: Nginx Proxy Manager (nginx-proxy-manage: latest)
|
||||
- Service name: npm
|
||||
- Domain: `npm.np-dms.work`
|
||||
- หน้าที่: เป็นด่านหน้าในการรับ-ส่งข้อมูล จัดการโดเมนทั้งหมด, ทำหน้าที่เป็น Proxy ชี้ไปยัง Service ที่ถูกต้อง, และจัดการ SSL Certificate (HTTPS) ให้อัตโนมัติ
|
||||
|
||||
- **Search Engine:** Elasticsearch
|
||||
- **Cache:** Redis
|
||||
|
||||
### **2.4 Business Logic & Consistency (ปรับปรุง):**
|
||||
|
||||
- **2.4.1 ตรรกะทางธุรกิจที่ซับซ้อนทั้งหมด** (เช่น การเปลี่ยนสถานะ Workflow [cite: 3.5.3, 3.6.5], การบังคับใช้สิทธิ์ [cite: 4.4], การตรวจสอบ Deadline [cite: 3.2.5]) **จะถูกจัดการในฝั่ง Backend (NestJS)** [cite: 2.3] เพื่อให้สามารถบำรุงรักษาและทดสอบได้ง่าย (Testability)
|
||||
|
||||
- **2.4.2 Unified Workflow Engine (ใหม่):** รวม Logic การเดินเอกสารของ `CorrespondenceRouting` และ `RfaWorkflow` ให้ใช้ Core Engine เดียวกันเพื่อลดความซ้ำซ้อนและง่ายต่อการบำรุงรักษา
|
||||
|
||||
- **2.4.3 Idempotency Keys (ใหม่):** API ที่สำคัญ (เช่น Submit Document, Approve) ต้องบังคับส่ง Header `Idempotency-Key` เพื่อป้องกันการทำรายการซ้ำจากการกดปุ่มรัวๆ หรือ Network Retry
|
||||
|
||||
- **2.4.4 Optimistic Locking (ใหม่):** ใช้ Version Column ใน Database ควบคู่กับ Redis Lock สำหรับการสร้างเลขที่เอกสาร เพื่อเป็น Safety Net ชั้นสุดท้าย
|
||||
|
||||
- **2.4.5** **จะไม่มีการใช้ SQL Triggers** เพื่อป้องกันตรรกะซ่อนเร้น (Hidden Logic) และความซับซ้อนในการดีบัก
|
||||
|
||||
### **2.5 Data Migration และ Schema Versioning:**
|
||||
|
||||
- ต้องมี database migration scripts สำหรับทุก schema change โดยใช้ TypeORM migrations
|
||||
- ต้องรองรับ rollback ของ migration ได้
|
||||
- ต้องมี data seeding strategy สำหรับ environment ต่างๆ (development, staging, production)
|
||||
- ต้องมี version compatibility between schema versions
|
||||
- Migration scripts ต้องผ่านการทดสอบใน staging environment ก่อน production
|
||||
- ต้องมี database backup ก่อนทำ migration ใน production
|
||||
|
||||
### **2.6 กลยุทธ์ความทนทานและการจัดการข้อผิดพลาด (Resilience & Error Handling Strategy)**
|
||||
|
||||
- 2.6.1 Circuit Breaker Pattern: ใช้สำหรับ external service calls (Email, LINE, Elasticsearch)
|
||||
- 2.6.2 Retry Mechanism: ด้วย exponential backoff สำหรับ transient failures
|
||||
- 2.6.3 Fallback Strategies: Graceful degradation เมื่อบริการภายนอกล้มเหลว
|
||||
- 2.6.4 Error Handling: Error messages ต้องไม่เปิดเผยข้อมูล sensitive
|
||||
- 2.6.5 Monitoring: Centralized error monitoring และ alerting system
|
||||
|
||||
## **📦 3. ข้อกำหนดด้านฟังก์ชันการทำงาน (Functional Requirements)**
|
||||
|
||||
### **3.1. การจัดการโครงสร้างโครงการและองค์กร**
|
||||
|
||||
- 3.1.1. โครงการ (Projects): ระบบต้องสามารถจัดการเอกสารภายในหลายโครงการได้ (ปัจจุบันมี 4 โครงการ และจะเพิ่มขึ้นในอนาคต)
|
||||
- 3.1.2. สัญญา (Contracts): ระบบต้องสามารถจัดการเอกสารภายในแต่ละสัญญาได้ ในแต่ละโครงการ มีได้หลายสัญญา หรืออย่างน้อย 1 สัญญา
|
||||
- 3.1.3. องค์กร (Organizations):
|
||||
- มีหลายองค์กรในโครงการ องค์กรณ์ที่เป็น Owner, Designer และ Consultant สามารถอยู่ในหลายโครงการและหลายสัญญาได้
|
||||
- Contractor จะถือ 1 สัญญา และอยู่ใน 1 โครงการเท่านั้น
|
||||
|
||||
### **3.2. การจัดการเอกสารโต้ตอบ (Correspondence Management)**
|
||||
|
||||
- 3.2.1. วัตถุประสงค์: เอกสารโต้ตอบ (correspondences) ระหว่างองกรณื-องกรณ์ ภายใน โครงการ (Projects) และระหว่าง องค์กร-องค์กร ภายนอก โครงการ (Projects), รองรับ To (ผู้รับหลัก) และ CC (ผู้รับสำเนา) หลายองค์กร
|
||||
- 3.2.2. ประเภทเอกสาร: ระบบต้องรองรับเอกสารรูปแบบ ไฟล์ PDF หลายประเภท (Types) เช่น จดหมาย (Letter), อีเมล์ (Email), Request for Information (RFI), และสามารถเพิ่มประเภทใหม่ได้ในภายหลัง
|
||||
- 3.2.3. การสร้างเอกสาร (Correspondence):
|
||||
- ผู้ใช้ที่มีสิทธิ์ (เช่น Document Control) สามารถสร้างเอกสารรอไว้ในสถานะ ฉบับร่าง" (Draft) ได้ ซึ่งผู้ใช้งานต่างองค์กรจะมองไม่เห็น
|
||||
- เมื่อกด "Submitted" แล้ว การแก้ไข, ถอนเอกสารกลับไปสถานะ Draft, หรือยกเลิก (Cancel) จะต้องทำโดยผู้ใช้ระดับ Admin ขึ้นไป พร้อมระบุเหตุผล
|
||||
- 3.2.4. การอ้างอิงและจัดกลุ่ม:
|
||||
- เอกสารสามารถอ้างถึง (Reference) เอกสารฉบับก่อนหน้าได้หลายฉบับ
|
||||
- สามารถกำหนด Tag ได้หลาย Tag เพื่อจัดกลุ่มและใช้ในการค้นหาขั้นสูง
|
||||
- 3.2.5. Correspondence Routing & Workflow
|
||||
- 3.2.5.1 Routing Templates (แม่แบบการส่งต่อ)
|
||||
- ผู้ดูแลระบบต้องสามารถสร้างแม่แบบการส่งต่อได้
|
||||
- แม่แบบสามารถเป็นแบบทั่วไป (ใช้ได้ทุกโครงการ) หรือเฉพาะโครงการ
|
||||
- แต่ละแม่แบบประกอบด้วยลำดับขั้นตอนการส่งต่อ
|
||||
- การส่งจาก Originator -> Organization 1 -> Organization 2 -> Organization 3 แล้วส่งผลกลับตามลำดับเดิม (โดยถ้า องกรณ์ใดใน Wouting ให้ส่งกลับ ก็สามารถส่งผลกลับตามลำดับเดิมโดยไม่ต้องรอให้ถึง องกรณืในลำดับถัดไป)
|
||||
- 3.2.5.2 Routing Steps (ขั้นตอนการส่งต่อ) แต่ละขั้นตอนในแม่แบบต้องกำหนด:
|
||||
- **ลำดับขั้นตอน** (Sequence)
|
||||
- **องค์กรผู้รับ** (To Organization)
|
||||
- **วัตถุประสงค์** (Purpose): เพื่ออนุมัติ (FOR_APPROVAL), เพื่อตรวจสอบ (FOR_REVIEW), เพื่อทราบ (FOR_INFORMATION), เพื่อดำเนินการ (FOR_ACTION)
|
||||
- **ระยะเวลาที่คาดหวัง** (Expected Duration)
|
||||
- 3.2.5.3 Actual Routing Execution (การส่งต่อจริง) เมื่อสร้างเอกสารและเลือกใช้แม่แบบ ระบบต้อง:
|
||||
- สร้างลำดับการส่งต่อตามแม่แบบ
|
||||
- ติดตามสถานะของแต่ละขั้นตอน: ส่งแล้ว (SENT), กำลังดำเนินการ (IN_PROGRESS), ดำเนินการแล้ว (ACTIONED), ส่งต่อแล้ว (FORWARDED), ตอบกลับแล้ว (REPLIED)
|
||||
- ระบุวันครบกำหนด (Due Date) สำหรับแต่ละขั้นตอน
|
||||
- บันทึกผู้ดำเนินการและเวลาที่ดำเนินการ
|
||||
- 3.2.5.4 Routing Flexibility (ความยืดหยุ่น)
|
||||
- สามารถข้ามขั้นตอนได้ในกรณีพิเศษ (โดยผู้มีสิทธิ์)
|
||||
- สามารถส่งกลับขั้นตอนก่อนหน้าได้
|
||||
- สามารถเพิ่มความคิดเห็นในแต่ละขั้นตอน
|
||||
- แจ้งเตือนอัตโนมัติเมื่อถึงขั้นตอนใหม่หรือใกล้ครบกำหนด
|
||||
- 3.2.6. การจัดการ: มีการจัดการอย่างน้อยดังนี้
|
||||
- สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบของ องกรณ์ ที่เป็นผู้รับได้
|
||||
- มีระบบแจ้งเตือน ให้ผู้รับผิดชอบขององกรณ์ที่เป็น ผู้รับ/ผู้ส่ง ทราบ เมื่อมีเอกสารใหม่ หรือมีการเปลี่ยนสถานะ
|
||||
|
||||
### **3.3. การจัดกาแบบคู่สัญญา (Contract Drawing)**
|
||||
|
||||
- 3.3.1. วัตถุประสงค์: แบบคู่สัญญา (Contract Drawing) ใช้เพื่ออ้างอิงและใช้ในการตรวจสอบ
|
||||
- 3.3.2. ประเภทเอกสาร: ไฟล์ PDF
|
||||
- 3.3.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
|
||||
- 3.3.4. การอ้างอิงและจัดกลุ่ม: ใช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Contract Drawing
|
||||
|
||||
### **3.4. การจัดกาแบบก่อสร้าง (Shop Drawing)**
|
||||
|
||||
- 3.4.1. วัตถุประสงค์: แบบก่อสร้าง (Shop Drawing) ใช้เในการตรวจสอบ โดยจัดส่งด้วย Request for Approval (RFA)
|
||||
- 3.4.2. ประเภทเอกสาร: ไฟล์ PDF
|
||||
- 3.4.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
|
||||
- 3.4.4. การอ้างอิงและจัดกลุ่ม: ช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Shop Drawings
|
||||
|
||||
### **3.5. การจัดการเอกสารขออนุมัติ (Request for Approval & Workflow)**
|
||||
|
||||
- 3.5.1. วัตถุประสงค์: เอกสารขออนุมัติ (Request for Approval) ใช้ในการส่งเอกสารเพิอขออนุมัติ
|
||||
- 3.5.2. ประเภทเอกสาร: Request for Approval (RFA) เป็นชนิดหนึ่งของ Correspondence ที่มีลักษณะเฉพาะที่ต้องได้รับการอนุมัติ มีประเภทดังนี้:
|
||||
- Request for Drawing Approval (RFA_DWG)
|
||||
- Request for Document Approval (RFA_DOC)
|
||||
- Request for Method statement Approval (RFA_MES)
|
||||
- Request for Material Approval (RFA_MAT)
|
||||
- 3.5.2. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
|
||||
- 3.5.3. การอ้างอิงและจัดกลุ่ม: การจัดการ Drawing (RFA_DWG):
|
||||
- เอกสาร RFA_DWG จะประกอบไปด้วย Shop Drawing (shop_drawings) หลายแผ่น ซึ่งแต่ละแผ่นมี Revision ของตัวเอง
|
||||
- Shop Drawing แต่ละ Revision สามารถอ้างอิงถึง Contract Drawing (Ccontract_drawings) หลายแผ่น หรือไม่อ้างถึงก็ได้
|
||||
- ระบบต้องมีส่วนสำหรับจัดการข้อมูล Master Data ของทั้ง Shop Drawing และ Contract Drawing แยกจากกัน
|
||||
- 3.5.4. Workflow การอนุมัติ: ต้องรองรับกระบวนการอนุมัติที่ซับซ้อนและเป็นลำดับ เช่น
|
||||
- ส่งจาก Originator -> Organization 1 -> Organization 2 -> Organization 3 แล้วส่งผลกลับตามลำดับเดิม (โดยถ้า องกรณ์ใดใน Workflow ให้ส่งกลับ ก็สามารถส่งผลกลับตามลำดับเดิมโดยไม่ต้องรอให้ถึง องกรณืในลำดับถัดไป)
|
||||
- 3.5.5. การจัดการ: มีการจัดการอย่างน้อยดังนี้
|
||||
- สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ได้
|
||||
- มีระบบแจ้งเตือน ให้ผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ทราบ เมื่อมี RFA ใหม่ หรือมีการเปลี่ยนสถานะ
|
||||
|
||||
### **3.6.การจัดการเอกสารนำส่ง (Transmittals)**
|
||||
|
||||
- 3.6.1. วัตถุประสงค์: เอกสารนำส่ง ใช้สำหรับ นำส่ง Request for Approval (RFAS) หลายฉบับ ไปยังองค์กรอื่น
|
||||
- 3.6.2. ประเภทเอกสาร: ไฟล์ PDF
|
||||
- 3.6.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้
|
||||
- 3.6.4. การอ้างอิงและจัดกลุ่ม: เอกสารนำส่ง เป็นส่วนหนึ่งใน Correspondence
|
||||
|
||||
### **3.7. ใบเวียนเอกสาร (Circulation Sheet)**
|
||||
|
||||
- 3.7.1. วัตถุประสงค์: การสื่อสาร เอกสาร (Correspondence) ทุกฉบับ จะมีใบเวียนเอกสารเพื่อควบคุมและมอบหมายงานภายในองค์กร (สามารถดูและแก้ไขได้เฉพาะคนในองค์กร)
|
||||
- 3.7.2. ประเภทเอกสาร: ไฟล์ PDF
|
||||
- 3.7.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ในองค์กรนั้น สามารถสร้างและแก้ไขได้
|
||||
- 3.7.4. การอ้างอิงและจัดกลุ่ม: การระบุผู้รับผิดชอบ:
|
||||
- ผู้รับผิดชอบหลัก (Main): มีได้หลายคน
|
||||
- ผู้ร่วมปฏิบัติงาน (Action): มีได้หลายคน
|
||||
- ผู้ที่ต้องรับทราบ (Information): มีได้หลายคน
|
||||
- 3.7.5. การติดตามงาน:
|
||||
- สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบประเภท Main และ Action ได้
|
||||
- มีระบบแจ้งเตือนเมื่อมี Circulation ใหม่ และแจ้งเตือนล่วงหน้าก่อนถึงวันแล้วเสร็จ
|
||||
- สามารถปิด Circulation ได้เมื่อดำเนินการตอบกลับไปยังองค์กรผู้ส่ง (Originator) แล้ว หรือ รับทราบแล้ว (For Information)
|
||||
|
||||
### **3.8. ประวัติการแก้ไข (Revisions):** ระบบจะเก็บประวัติการสร้างและแก้ไข เอกสารทั้งหมด
|
||||
|
||||
### **3.9. การจัดเก็บไฟล์ (File Handling - ปรับปรุงใหญ่)**
|
||||
|
||||
- **3.9.1 Two-Phase Storage Strategy:**
|
||||
1. **Phase 1 (Upload):** ไฟล์ถูกอัปโหลดเข้าโฟลเดอร์ `temp/` และได้รับ `temp_id`
|
||||
2. **Phase 2 (Commit):** เมื่อ User กด Submit ฟอร์มสำเร็จ ระบบจะย้ายไฟล์จาก `temp/` ไปยัง `permanent/{YYYY}/{MM}/` และบันทึกลง Database ภายใน Transaction เดียวกัน
|
||||
3. **Cleanup:** มี Cron Job ลบไฟล์ใน `temp/` ที่ค้างเกิน 24 ชม. (Orphan Files)
|
||||
|
||||
- **3.9.2 Security:**
|
||||
- Virus Scan (ClamAV) ก่อนย้ายเข้า Permanent
|
||||
- Whitelist File Types: PDF, DWG, DOCX, XLSX, ZIP
|
||||
- Max Size: 50MB
|
||||
- Access Control: ตรวจสอบสิทธิ์ผ่าน Junction Table ก่อนให้ Download Link
|
||||
|
||||
- **3.9.3 ความปลอดภัยของการจัดเก็บไฟล์:**
|
||||
- ต้องมีการ scan virus สำหรับไฟล์ที่อัปโหลดทั้งหมด โดยใช้ ClamAV หรือบริการ third-party
|
||||
- จำกัดประเภทไฟล์ที่อนุญาต: PDF, DWG, DOCX, XLSX, ZIP (ต้องระบุรายการที่ชัดเจน)
|
||||
- ขนาดไฟล์สูงสุด: 50MB ต่อไฟล์
|
||||
- ไฟล์ต้องถูกเก็บนอก web root และเข้าถึงได้ผ่าน authenticated endpoint เท่านั้น
|
||||
- ต้องมี file integrity check (checksum) เพื่อป้องกันการแก้ไขไฟล์
|
||||
- Download links ต้องมี expiration time (default: 24 ชั่วโมง)
|
||||
- ต้องบันทึก audit log ทุกครั้งที่มีการดาวน์โหลดไฟล์สำคัญ
|
||||
|
||||
### **3.10. การจัดการเลขที่เอกสาร (Document Numbering - ปรับปรุง)**
|
||||
|
||||
- 3.10.1. ระบบต้องสามารถสร้างเลขที่เอกสาร (Running Number) ได้โดยอัตโนมัติและยืดหยุ่นสูง
|
||||
- 3.10.2. **Logic การนับเลข (Counter Logic):** การนับเลขจะต้องรองรับการแยกตาม Key ที่ซับซ้อนขึ้น:
|
||||
- **Project** + **Originator** + **Type** + **Discipline** (ถ้ามี) + **Sub-Type** (ถ้ามี) + **Year**
|
||||
- 3.10.3. **Format Template:** รองรับการกำหนดรูปแบบด้วย **Token Replacement** เช่น:
|
||||
- `{ORG}-{TYPE}-{DISCIPLINE}-{SEQ:4}-{REV}` -> `TEAM-RFA-STR-0001-A`
|
||||
- รองรับ Token: `{PROJECT}`, `{ORG}`, `{TYPE}`, `{DISCIPLINE}`, `{SUBTYPE}`, `{SUBTYPE_NUM}`, `{YEAR}`, `{YEAR_SHORT}`, `{SEQ:n}`
|
||||
- 3.10.4. **Transmittal Logic:** รองรับเงื่อนไขพิเศษสำหรับ Transmittal ที่เลขอาจเปลี่ยนตามผู้รับ (To Owner vs To Contractor)
|
||||
- 3.10.5. **กลไกความปลอดภัย:** ยังคงใช้ Redis Distributed Lock และ Optimistic Locking เพื่อป้องกันเลขซ้ำหรือข้าม
|
||||
- 3.10.6. ต้องมี retry mechanism และ fallback strategy เมื่อการ generate เลขที่เอกสารล้มเหลว
|
||||
|
||||
### **3.11 การจัดการ JSON Details (JSON & Performance - ปรับปรุง)**
|
||||
|
||||
- **3.11.1 วัตถุประสงค์**
|
||||
- จัดเก็บข้อมูลแบบไดนามิกที่เฉพาะเจาะจงกับแต่ละประเภทของเอกสาร
|
||||
- รองรับการขยายตัวของระบบโดยไม่ต้องเปลี่ยนแปลง database schema
|
||||
- จัดการ metadata และข้อมูลประกอบสำหรับ correspondence, routing, และ workflows
|
||||
|
||||
- **3.11.2 โครงสร้าง JSON Schema**
|
||||
ระบบต้องมี predefined JSON schemas สำหรับประเภทเอกสารต่างๆ:
|
||||
- **3.11.2.1 Correspondence Types**
|
||||
- **GENERIC**: ข้อมูลพื้นฐานสำหรับเอกสารทั่วไป
|
||||
- **RFI**: รายละเอียดคำถามและข้อมูลทางเทคนิค
|
||||
- **RFA**: ข้อมูลการขออนุมัติแบบและวัสดุ
|
||||
- **TRANSMITTAL**: รายการเอกสารที่ส่งต่อ
|
||||
- **LETTER**: ข้อมูลจดหมายทางการ
|
||||
- **EMAIL**: ข้อมูลอีเมล
|
||||
- **3.11.2.2 Routing Types**
|
||||
- **ROUTING_TEMPLATE**: กฎและเงื่อนไขการส่งต่อ
|
||||
- **ROUTING_INSTANCE**: สถานะและประวัติการส่งต่อ
|
||||
- **ROUTING_ACTION**: การดำเนินการในแต่ละขั้นตอน
|
||||
- **3.11.2.3 Audit Types**
|
||||
- **AUDIT_LOG**: ข้อมูลการตรวจสอบ
|
||||
- **SECURITY_SCAN**: ผลการตรวจสอบความปลอดภัย
|
||||
|
||||
- **3.11.3 Virtual Columns (ใหม่):** สำหรับ Field ใน JSON ที่ต้องใช้ในการค้นหา (Search) หรือจัดเรียง (Sort) บ่อยๆ **ต้องสร้าง Generated Column (Virtual Column)** ใน Database และทำ Index ไว้ เพื่อประสิทธิภาพสูงสุด
|
||||
|
||||
- **3.11.4 Validation Rules**
|
||||
- ต้องมี JSON schema validation สำหรับแต่ละประเภท
|
||||
- ต้องรองรับ versioning ของ schema
|
||||
- ต้องมี default values สำหรับ field ที่ไม่บังคับ
|
||||
- ต้องตรวจสอบ data types และ format ให้ถูกต้อง
|
||||
|
||||
- **3.11.5 Performance Requirements**
|
||||
- JSON field ต้องมีขนาดไม่เกิน 50KB
|
||||
- ต้องรองรับ indexing สำหรับ field ที่ใช้ค้นหาบ่อย
|
||||
- ต้องมี compression สำหรับ JSON ขนาดใหญ่
|
||||
|
||||
- **3.11.6 Security Requirements**
|
||||
- ต้อง sanitize JSON input เพื่อป้องกัน injection attacks
|
||||
- ต้อง validate JSON structure ก่อนบันทึก
|
||||
- ต้อง encrypt sensitive data ใน JSON fields
|
||||
|
||||
### **3.12 ข้อกำหนดพิเศษ**
|
||||
- **ผู้ใช้งานที่มีสิทธิ์ระดับสูง (Global) หรือผู้ได้รับอนุญาตเป็นกรณีพิเศษ**
|
||||
- สามารถเลือก **สร้างในนามองค์กร (Create on behalf of)** ได้ เพื่อให้สามารถออกเลขที่เอกสาร (Running Number) ขององค์กรอื่นได้โดยไม่ต้องล็อกอินใหม่
|
||||
- สามารถทำงานแทนผู้ใช้งานอื่นได้ Routing & Workflow ของ Correspondence, RFA, Circulation Sheet
|
||||
|
||||
### 3.13. การจัดการข้อมูลหลักขั้นสูง (Admin Panel for Master Data)
|
||||
|
||||
- 3.13.1. **Disciplines Management:** Admin ต้องสามารถ เพิ่ม/ลบ/แก้ไข สาขางาน (Disciplines) แยกตามสัญญา (Contract) ได้
|
||||
- 3.13.2. **Sub-Type Mapping:** Admin ต้องสามารถกำหนด Correspondence Sub-types และ Mapping รหัสตัวเลข (เช่น MAT = 11) ได้
|
||||
- 3.13.3. **Numbering Format Configuration:** Admin ต้องมี UI สำหรับตั้งค่า Format Template ของแต่ละ Project/Type ได้โดยไม่ต้องแก้โค้ด
|
||||
|
||||
## **🔐 4. ข้อกำหนดด้านสิทธิ์และการเข้าถึง (Access Control Requirements)**
|
||||
|
||||
### **4.1. ภาพรวม:** ผู้ใช้และองค์กรสามารถดูและแก้ไขเอกสารได้ตามสิทธิ์ที่ได้รับ โดยระบบสิทธิ์จะเป็นแบบ Role-Based Access Control (RBAC)
|
||||
|
||||
### **4.2. ลำดับชั้นของสิทธิ์ (Permission Hierarchy)**
|
||||
|
||||
- Global: สิทธิ์สูงสุดของระบบ
|
||||
- Organization: สิทธิ์ภายในองค์กร เป็นสิทธิ์พื้นฐานของผู้ใช้
|
||||
- Project: สิทธิ์เฉพาะในโครงการ จะถูกพิจารณาเมื่อผู้ใช้อยู่ในโครงการนั้น
|
||||
- Contract: สิทธิ์เฉพาะในสัญญา จะถูกพิจารณาเมื่อผู้ใช้อยู่ในสัญญานั้น (สัญญาเป็นส่วนหนึ่งของโครงการ)
|
||||
|
||||
กฎการบังคับใช้: เมื่อตรวจสอบสิทธิ์ ระบบจะพิจารณาสิทธิ์จากทุกระดับที่ผู้ใช้มี และใช้ สิทธิ์ที่มากที่สุด (Most Permissive) เป็นตัวตัดสิน
|
||||
|
||||
ตัวอย่าง: ผู้ใช้ A เป็น Viewer ในองค์กร แต่ถูกมอบหมายเป็น Editor ในโครงการ X เมื่ออยู่ในโครงการ X ผู้ใช้ A จะมีสิทธิ์แก้ไขได้
|
||||
|
||||
### **4.3. การกำหนดบทบาท (Roles) และขอบเขต (Scope)**
|
||||
|
||||
| บทบาท (Role) | ขอบเขต (Scope) | คำอธิบาย | สิทธิ์หลัก (Key Permissions) |
|
||||
| :------------------- | :------------- | :------------------ | :----------------------------------------------------------------------------- |
|
||||
| **Superadmin** | Global | ผู้ดูแลระบบสูงสุด | ทำทุกอย่างในระบบ, จัดการองค์กร, จัดการข้อมูลหลักระดับ Global |
|
||||
| **Org Admin** | Organization | ผู้ดูแลองค์กร | จัดการผู้ใช้ในองค์กร, จัดการบทบาท/สิทธิ์ภายในองค์กร, ดูรายงานขององค์กร |
|
||||
| **Document Control** | Organization | ควบคุมเอกสารขององค์กร | เพิ่ม/แก้ไข/ลบเอกสาร, กำหนดสิทธิ์เอกสารภายในองค์กร |
|
||||
| **Editor** | Organization | ผู้แก้ไขเอกสารขององค์กร | เพิ่ม/แก้ไขเอกสารที่ได้รับมอบหมาย |
|
||||
| **Viewer** | Organization | ผู้ดูเอกสารขององค์กร | ดูเอกสารที่มีสิทธิ์เข้าถึง |
|
||||
| **Project Manager** | Project | ผู้จัดการโครงการ | จัดการสมาชิกในโครงการ (เพิ่ม/ลบ/มอบบทบาท), สร้าง/จัดการสัญญาในโครงการ, ดูรายงานโครงการ |
|
||||
| **Contract Admin** | Contract | ผู้ดูแลสัญญา | จัดการสมาชิกในสัญญา, สร้าง/จัดการข้อมูลหลักเฉพาะสัญญา (ถ้ามี), อนุมัติเอกสารในสัญญา |
|
||||
|
||||
### **4.4. Token Management (ปรับปรุง)**
|
||||
|
||||
- **Payload Optimization:** ใน JWT Access Token ให้เก็บเฉพาะ `userId` และ `scope` ปัจจุบันเท่านั้น
|
||||
- **Permission Caching:** สิทธิ์ละเอียด (Permissions List) ให้เก็บใน **Redis** และดึงมาตรวจสอบเมื่อ Request เข้ามา เพื่อลดขนาด Token และเพิ่มความเร็ว
|
||||
|
||||
### **4.5. กระบวนการเริ่มต้นใช้งาน (Onboarding Workflow) ที่สมบูรณ์**
|
||||
|
||||
- **4.5.1. สร้างองค์กร (Organization)**
|
||||
- **Superadmin** สร้างองค์กรใหม่ (เช่น บริษัท A)
|
||||
- **Superadmin** แต่งตั้งผู้ใช้อย่างน้อย 1 คนให้เป็น **Org Admin** หรือ **Document Control** ของบริษัท A
|
||||
- **4.5.2. เพิ่มผู้ใช้ในองค์กร**
|
||||
- **Org Admin** ของบริษัท A เพิ่มผู้ใช้อื่นๆ (Editor, Viewer) เข้ามาในองค์กรของตน
|
||||
- **4.5.3. มอบหมายผู้ใช้ให้กับโครงการ (Project)**
|
||||
- **Project Manager** ของโครงการ X (ซึ่งอาจมาจากบริษัท A หรือบริษัทอื่น) ทำการ "เชิญ" หรือ "มอบหมาย" ผู้ใช้จากองค์กรต่างๆ ที่เกี่ยวข้องเข้ามาในโครงการ X
|
||||
- ในขั้นตอนนี้ **Project Manager** จะกำหนด **บทบาทระดับโครงการ** (เช่น Project Member, หรืออาจไม่มีบทบาทพิเศษ ให้ใช้สิทธิ์จากระดับองค์กรไปก่อน)
|
||||
- **4.5.4. เมอบหมายผู้ใช้ให้กับสัญญา (Contract)**
|
||||
- **Contract Admin** ของสัญญา Y (ซึ่งเป็นส่วนหนึ่งของโครงการ X) ทำการเลือกผู้ใช้ที่อยู่ในโครงการ X แล้ว มอบหมายให้เข้ามาในสัญญา Y
|
||||
- ในขั้นตอนนี้ **Contract Admin** จะกำหนด **บทบาทระดับสัญญา** (เช่น Contract Member) และสิทธิ์เฉพาะที่จำเป็น
|
||||
- **4.5.5 Security Onboarding:**
|
||||
- ต้องบังคับเปลี่ยน password ครั้งแรกสำหรับผู้ใช้ใหม่
|
||||
- ต้องมี security awareness training สำหรับผู้ใช้ที่มีสิทธิ์สูง
|
||||
- ต้องมี process สำหรับการรีเซ็ต password ที่ปลอดภัย
|
||||
- ต้องบันทึก audit log ทุกครั้งที่มีการเปลี่ยนแปลง permissions
|
||||
|
||||
### **4.6. การจัดการข้อมูลหลัก (Master Data Management) ที่แบ่งตามระดับ**
|
||||
|
||||
| ข้อมูลหลัก | ผู้มีสิทธิ์จัดการ | ระดับ |
|
||||
| :---------------------------------- | :------------------------------ | :------------------------------ |
|
||||
| ประเภทเอกสาร (Correspondence, RFA) | **Superadmin** | Global |
|
||||
| สถานะเอกสาร (Draft, Approved, etc.) | **Superadmin** | Global |
|
||||
| หมวดหมู่แบบ (Shop Drawing) | **Project Manager** | Project (สร้างใหม่ได้ภายในโครงการ) |
|
||||
| Tags | **Org Admin / Project Manager** | Organization / Project |
|
||||
| บทบาทและสิทธิ์ (Custom Roles) | **Superadmin / Org Admin** | Global / Organization |
|
||||
| Document Numbering Formats | **Superadmin / Admin** | Global / Organization |
|
||||
|
||||
## **👥 5. ข้อกำหนดด้านผู้ใช้งาน (User Interface & Experience)**
|
||||
|
||||
### **5.1. Layout หลัก:** หน้าเว็บใช้รูปแบบ App Shell ที่ประกอบด้วย
|
||||
|
||||
- Navbar (ส่วนบน): แสดงชื่อระบบ, เมนูผู้ใช้ (Profile), เมนูสำหรับ Document Control/เมนูสำหรับ Admin/Superadmin (จัดการผู้ใช้, จัดการสิทธิ์), และปุ่ม Login/Logout
|
||||
- Sidebar (ด้านข้าง): เป็นเมนูหลักสำหรับเข้าถึงส่วนที่เกี่ยวข้องกับเอกสารทั้งหมด เช่น Dashboard, Correspondences, RFA, Drawings
|
||||
- Main Content Area: พื้นที่สำหรับแสดงเนื้อหาหลักของหน้าที่เลือก
|
||||
|
||||
### **5.2. หน้า Landing Page:** เป็นหน้าแรกที่แสดงข้อมูลบางส่วนของโครงการสำหรับผู้ใช้ที่ยังไม่ได้ล็อกอิน
|
||||
|
||||
### **5.3. หน้า Dashboard:** เป็นหน้าแรกหลังจากล็อกอิน ประกอบด้วย
|
||||
|
||||
- การ์ดสรุปภาพรวม (KPI Cards): แสดงข้อมูลสรุปที่สำคัญขององค์กร เช่น จำนวนเอกสาร, งานที่เกินกำหนด
|
||||
- ตาราง "งานของฉัน" (My Tasks Table): แสดงรายการงานทั้งหมดจาก Circulation ที่ผู้ใช้ต้องดำเนินการ
|
||||
- Security Metrics: แสดงจำนวน files scanned, security incidents, failed login attempts
|
||||
|
||||
### **5.4. การติดตามสถานะ:** องค์กรสามารถติดตามสถานะเอกสารทั้งของตนเอง (Originator) และสถานะเอกสารที่ส่งมาถึงตนเอง (Recipient)
|
||||
|
||||
### **5.5. การจัดการข้อมูลส่วนตัว (Profile Page):** ผู้ใช้สามารถจัดการข้อมูลส่วนตัวและเปลี่ยนรหัสผ่านของตนเองได้
|
||||
|
||||
### **5.6. การจัดการเอกสารทางเทคนิค (RFA & Workflow):** ผู้ใช้สามารถดู RFA ในรูปแบบ Workflow ทั้งหมดได้ในหน้าเดียว, ขั้นตอนที่ยังไม่ถึงหรือผ่านไปแล้วจะเป็นรูปแบบ diable, สามารถดำเนินการได้เฉพาะในขั้นตอนที่ได้รับมอบหมายงาน (active) เช่น ตรวจสอบแล้ว เพื่อไปยังขั้นตอนต่อไป, สิทธิ์ Document Control ขึ้นไป สามรถกด ไปยังขั้นตอนต่อไป ได้ทุกขั้นตอน, การย้อนกลับ ไปขั้นตอนก่อนหน้า สามารถทำได้โดย สิทธิ์ Document Control ขึ้นไป
|
||||
|
||||
### **5.7. การจัดการใบเวียนเอกสาร (Circulation):** ผู้ใช้สามารถดู Circulation ในรูปแบบ Workflow ทั้งหมดได้ในหน้าเดียว,ขั้นตอนที่ยังไม่ถึงหรือผ่านไปแล้วจะเป็นรูปแบบ diable, สามารถดำเนินการได้เฉพาะในขั้นตอนที่ได้รับมอบหมายงาน (active) เช่น ตรวจสอบแล้ว เพื่อไปยังขั้นตอนต่อไป, สิทธิ์ Document Control ขึ้นไป สามรถกด ไปยังขั้นตอนต่อไป ได้ทุกขั้นตอน, การย้อนกลับ ไปขั้นตอนก่อนหน้า สามารถทำได้โดย สิทธิ์ Document Control ขึ้นไป
|
||||
|
||||
### **5.8. การจัดการเอกสารนำส่ง (Transmittals):** ผู้ใช้สามารถดู Transmittals ในรูปแบบรายการทั้งหมดได้ในหน้าเดียว
|
||||
|
||||
### **5.9. ข้อกำหนด UI/UX การแนบไฟล์ (File Attachment UX):**
|
||||
|
||||
- ระบบต้องรองรับการอัปโหลดไฟล์หลายไฟล์พร้อมกัน (Multi-file upload) เช่น การลากและวาง (Drag-and-Drop)
|
||||
- ในหน้าอัปโหลด (เช่น สร้าง RFA หรือ Correspondence) ผู้ใช้ต้องสามารถกำหนดได้ว่าไฟล์ใดเป็น "เอกสารหลัก" (Main Document เช่น PDF) และไฟล์ใดเป็น "เอกสารแนบประกอบ" (Supporting Attachments เช่น .dwg, .docx, .zip)
|
||||
- **Security Feedback:** แสดง security warnings สำหรับ file types ที่เสี่ยงหรือ files ที่ fail virus scan
|
||||
- **File Type Indicators:** แสดง file type icons และ security status
|
||||
|
||||
### **5.10 Form & Interaction (ใหม่)**
|
||||
|
||||
- **Dynamic Form Generator:** ใช้ Component กลางที่รับ JSON Schema แล้ว Render Form ออกมาอัตโนมัติ เพื่อลดความซ้ำซ้อนของโค้ดหน้าบ้าน และรองรับเอกสารประเภทใหม่ๆ ได้ทันที
|
||||
- **Optimistic Updates:** การเปลี่ยนสถานะ (เช่น กด Approve, กด Read) ให้ UI เปลี่ยนสถานะทันทีให้ผู้ใช้เห็นก่อนรอ API Response (Rollback ถ้า Failed)
|
||||
|
||||
### **5.11 Mobile Responsiveness (ใหม่)**
|
||||
|
||||
- **Table Visualization:** บนหน้าจอมือถือ ตารางข้อมูลที่มีหลาย Column (เช่น Correspondence List) ต้องเปลี่ยนการแสดงผลเป็นแบบ **Card View** อัตโนมัติ
|
||||
- **Navigation:** Sidebar ต้องเป็นแบบ Collapsible Drawer
|
||||
|
||||
### **5.12 Resilience & Offline Support (ใหม่)**
|
||||
|
||||
- **Auto-Save Draft:** ระบบต้องบันทึกข้อมูลฟอร์มที่กำลังกรอกลง **LocalStorage** อัตโนมัติ เพื่อป้องกันข้อมูลหายกรณีเน็ตหลุดหรือปิด Browser โดยไม่ได้ตั้งใจ
|
||||
- **Graceful Degradation:** หาก Service รอง (เช่น Search, Notification) ล่ม ระบบหลัก (CRUD) ต้องยังทำงานต่อได้
|
||||
|
||||
## **🛡️ 6. ข้อกำหนดที่ไม่ใช่ฟังก์ชันการทำงาน (Non-Functional Requirements)**
|
||||
|
||||
### **6.1. การบันทึกการกระทำ (Audit Log):** ทุกการกระทำที่สำคัญของผู้ใช้ (สร้าง, แก้ไข, ลบ, ส่ง) จะถูกบันทึกไว้ใน audit_logs เพื่อการตรวจสอบย้อนหลัง
|
||||
|
||||
- **6.1.1 ขอบเขตการบันทึก Audit Log:**
|
||||
- ทุกการสร้าง/แก้ไข/ลบ ข้อมูลสำคัญ (correspondences, RFAs, drawings, users, permissions)
|
||||
- ทุกการเข้าถึงข้อมูล sensitive (user data, financial information)
|
||||
- ทุกการเปลี่ยนสถานะ workflow (status transitions)
|
||||
- ทุกการดาวน์โหลดไฟล์สำคัญ (contract documents, financial reports)
|
||||
- ทุกการเปลี่ยนแปลง permission และ role assignment
|
||||
- ทุกการล็อกอินที่สำเร็จและล้มเหลว
|
||||
- ทุกการส่งคำขอ API ที่สำคัญ
|
||||
|
||||
- **6.1.2 ข้อมูลที่ต้องบันทึกใน Audit Log:**
|
||||
- ผู้ใช้งาน (user_id)
|
||||
- การกระทำ (action)
|
||||
- ชนิดของ entity (entity_type)
|
||||
- ID ของ entity (entity_id)
|
||||
- ข้อมูลก่อนการเปลี่ยนแปลง (old_values) - สำหรับ update operations
|
||||
- ข้อมูลหลังการเปลี่ยนแปลง (new_values) - สำหรับ update operations
|
||||
- IP address
|
||||
- User agent
|
||||
- Timestamp
|
||||
- Request ID สำหรับ tracing
|
||||
|
||||
### **6.2. Data Archiving & Partitioning (ใหม่)**
|
||||
|
||||
- สำหรับตารางที่มีขนาดใหญ่และโตเร็ว (เช่น `audit_logs`, `notifications`, `correspondence_revisions`) ต้องออกแบบโดยรองรับ **Table Partitioning** (แบ่งตาม Range วันที่ หรือ List) เพื่อประสิทธิภาพในระยะยาว
|
||||
|
||||
### **6.3. การค้นหา (Search):** ระบบต้องมีฟังก์ชันการค้นหาขั้นสูง ที่สามารถค้นหาเอกสาร **correspondence**, **rfa**, **shop_drawing**, **contract-drawing**, **transmittal** และ **ใบเวียน (Circulations)** จากหลายเงื่อนไขพร้อมกันได้ เช่น ค้นหาจากชื่อเรื่อง, ประเภท, วันที่, และ Tag
|
||||
|
||||
### **6.4. การทำรายงาน (Reporting):** สามารถจัดทำรายงานสรุปแยกประเภทของ Correspondence ประจำวัน, สัปดาห์, เดือน, และปีได้
|
||||
|
||||
### **6.5. ประสิทธิภาพ (Performance):** มีการใช้ Caching กับข้อมูลที่เรียกใช้บ่อย และใช้ Pagination ในตารางข้อมูลเพื่อจัดการข้อมูลจำนวนมาก
|
||||
|
||||
- **6.5.1 ตัวชี้วัดประสิทธิภาพ:**
|
||||
- **API Response Time:** < 200ms (90th percentile) สำหรับ operation ทั่วไป
|
||||
- **Search Query Performance:** < 500ms สำหรับการค้นหาขั้นสูง
|
||||
- **File Upload Performance:** < 30 seconds สำหรับไฟล์ขนาด 50MB
|
||||
- **Concurrent Users:** รองรับผู้ใช้พร้อมกันอย่างน้อย 100 คน
|
||||
- **Database Connection Pool:** ขนาดเหมาะสมกับ workload (default: min 5, max 20 connections)
|
||||
- **Cache Hit Ratio:** > 80% สำหรับ cached data
|
||||
- **Application Startup Time:** < 30 seconds
|
||||
|
||||
- **6.5.2 Caching Strategy:**
|
||||
- **Master Data Cache:** Roles, Permissions, Organizations, Project metadata (TTL: 1 hour)
|
||||
- **User Session Cache:** User permissions และ profile data (TTL: 30 minutes)
|
||||
- **Search Result Cache:** Frequently searched queries (TTL: 15 minutes)
|
||||
- **File Metadata Cache:** Attachment metadata (TTL: 1 hour)
|
||||
- **Document Cache:** Frequently accessed document metadata (TTL: 30 minutes)
|
||||
- **ต้องมี cache invalidation strategy ที่ชัดเจน:**
|
||||
- Invalidate on update/delete operations
|
||||
- Time-based expiration
|
||||
- Manual cache clearance สำหรับ admin operations
|
||||
- ใช้ Redis เป็น distributed cache backend
|
||||
- ต้องมี cache monitoring (hit/miss ratios)
|
||||
|
||||
### **6.6. ความปลอดภัย (Security):**
|
||||
|
||||
- มีระบบ Rate Limiting เพื่อป้องกันการโจมตีแบบ Brute-force
|
||||
- การจัดการ Secret (เช่น รหัสผ่าน DB, JWT Secret) จะต้องทำผ่าน Environment Variable ของ Docker เพื่อความปลอดภัยสูงสุด
|
||||
|
||||
- **6.6.1 Rate Limiting Strategy:**
|
||||
- **Anonymous Endpoints:** 100 requests/hour ต่อ IP address
|
||||
- **Authenticated Endpoints:**
|
||||
- Viewer: 500 requests/hour
|
||||
- Editor: 1000 requests/hour
|
||||
- Document Control: 2000 requests/hour
|
||||
- Admin/Superadmin: 5000 requests/hour
|
||||
- **File Upload Endpoints:** 50 requests/hour ต่อ user
|
||||
- **Search Endpoints:** 500 requests/hour ต่อ user
|
||||
- **Authentication Endpoints:** 10 requests/minute ต่อ IP address
|
||||
- **ต้องมี mechanism สำหรับยกเว้น rate limiting สำหรับ trusted services**
|
||||
- ต้องบันทึก log เมื่อมีการ trigger rate limiting
|
||||
|
||||
- **6.6.2 Error Handling และ Resilience:**
|
||||
- ต้องมี circuit breaker pattern สำหรับ external service calls
|
||||
- ต้องมี retry mechanism ด้วย exponential backoff
|
||||
- ต้องมี graceful degradation เมื่อบริการภายนอกล้มเหลว
|
||||
- Error messages ต้องไม่เปิดเผยข้อมูล sensitive
|
||||
|
||||
- **6.6.3 Input Validation:**
|
||||
- ต้องมี input validation ทั้งฝั่ง client และ server (defense in depth)
|
||||
- ต้องป้องกัน OWASP Top 10 vulnerabilities:
|
||||
- SQL Injection (ใช้ parameterized queries ผ่าน ORM)
|
||||
- XSS (input sanitization และ output encoding)
|
||||
- CSRF (CSRF tokens สำหรับ state-changing operations)
|
||||
- ต้อง validate file uploads:
|
||||
- File type (white-list approach)
|
||||
- File size
|
||||
- File content (magic number verification)
|
||||
- ต้อง sanitize user inputs ก่อนแสดงผลใน UI
|
||||
- ต้องใช้ content security policy (CSP) headers
|
||||
- ต้องมี request size limits เพื่อป้องกัน DoS attacks
|
||||
|
||||
- **6.6.4 Session และ Token Management:**
|
||||
- **JWT token expiration:** 8 hours สำหรับ access token
|
||||
- **Refresh token expiration:** 7 days
|
||||
- **Refresh token mechanism:** ต้องรองรับ token rotation และ revocation
|
||||
- **Token revocation on logout:** ต้องบันทึก revoked tokens จนกว่าจะ expire
|
||||
- **Concurrent session management:**
|
||||
- จำกัดจำนวน session พร้อมกันได้ (default: 5 devices)
|
||||
- ต้องแจ้งเตือนเมื่อมี login จาก device/location ใหม่
|
||||
- **Device fingerprinting:** สำหรับ security และ audit purposes
|
||||
- **Password policy:**
|
||||
- ความยาวขั้นต่ำ: 8 characters
|
||||
- ต้องมี uppercase, lowercase, number, special character
|
||||
- ต้องเปลี่ยน password ทุก 90 วัน
|
||||
- ต้องป้องกันการใช้ password ที่เคยใช้มาแล้ว 5 ครั้งล่าสุด
|
||||
|
||||
### **6.7. การสำรองข้อมูลและการกู้คืน (Backup & Recovery):**
|
||||
|
||||
- ระบบจะต้องมีกลไกการสำรองข้อมูลอัตโนมัติสำหรับฐานข้อมูล MariaDB [cite: 2.4] และไฟล์เอกสารทั้งหมดใน /share/dms-data [cite: 2.1] (เช่น ใช้ HBS 3 ของ QNAP หรือสคริปต์สำรองข้อมูล) อย่างน้อยวันละ 1 ครั้ง
|
||||
- ต้องมีแผนการกู้คืนระบบ (Disaster Recovery Plan) ในกรณีที่ Server หลัก (QNAP) ใช้งานไม่ได้
|
||||
|
||||
- **6.7.1 ขั้นตอนการกู้คืน:**
|
||||
- **Database Restoration Procedure:**
|
||||
- สร้างจาก full backup ล่าสุด
|
||||
- Apply transaction logs ถึง point-in-time ที่ต้องการ
|
||||
- Verify data integrity post-restoration
|
||||
- **File Storage Restoration Procedure:**
|
||||
- Restore จาก QNAP snapshot หรือ backup
|
||||
- Verify file integrity และ permissions
|
||||
- **Application Redeployment Procedure:**
|
||||
- Deploy จาก version ล่าสุดที่รู้ว่าทำงานได้
|
||||
- Verify application health
|
||||
- **Data Integrity Verification Post-Recovery:**
|
||||
- Run data consistency checks
|
||||
- Verify critical business data
|
||||
- **Recovery Time Objective (RTO):** < 4 ชั่วโมง
|
||||
- **Recovery Point Objective (RPO):** < 1 ชั่วโมง
|
||||
|
||||
### **6.8. กลยุทธ์การแจ้งเตือน (Notification Strategy - ปรับปรุง):**
|
||||
|
||||
- **6.8.1 ระบบจะส่งการแจ้งเตือน (ผ่าน Email หรือ Line [cite: 2.7]) เมื่อมีการกระทำที่สำคัญ** ดังนี้:
|
||||
1. เมื่อมีเอกสารใหม่ (Correspondence, RFA) ถูกส่งมาถึงองค์กรณ์ของเรา
|
||||
2. เมื่อมีใบเวียน (Circulation) ใหม่ มอบหมายงานมาที่เรา
|
||||
3. (ทางเลือก) เมื่อเอกสารที่เราส่งไป ถูกดำเนินการ (เช่น อนุมัติ/ปฏิเสธ)
|
||||
4. (ทางเลือก) เมื่อใกล้ถึงวันครบกำหนด (Deadline) [cite: 3.2.5, 3.6.6, 3.7.5]
|
||||
|
||||
- **6.8.2 Grouping/Digest (ใหม่):** กรณีมีการแจ้งเตือนประเภทเดียวกันจำนวนมากในช่วงเวลาสั้นๆ (เช่น Approve เอกสาร 10 ฉบับรวด) ระบบต้อง **รวม (Batch)** เป็น 1 Email/Line Notification เพื่อไม่ให้รบกวนผู้ใช้ (Spamming)
|
||||
|
||||
- **6.8.3 Notification Delivery Guarantees:**
|
||||
- **At-least-once delivery:** สำหรับ important notifications
|
||||
- **Retry mechanism:** ด้วย exponential backoff (max 3 reties)
|
||||
- **Dead letter queue:** สำหรับ notifications ที่ส่งไม่สำเร็จหลังจาก retries
|
||||
- **Delivery status tracking:** ต้องบันทึกสถานะการส่ง notifications
|
||||
- **Fallback channels:** ถ้า Email ล้มเหลว ให้ส่งผ่าน SYSTEM notification
|
||||
- **Notification preferences:** ผู้ใช้ต้องสามารถกำหนด channel preferences ได้
|
||||
|
||||
### **6.9. Maintenance Mode (ใหม่)**
|
||||
|
||||
- ระบบต้องมีกลไก **Maintenance Mode** ที่ Admin สามารถเปิดใช้งานได้
|
||||
- เมื่อเปิด: ผู้ใช้ทั่วไปจะเห็นหน้า "ปิดปรับปรุง" และไม่สามารถเรียก API ได้ (ยกเว้น Admin)
|
||||
- ใช้สำหรับช่วง Deploy Version ใหม่ หรือ Database Migration
|
||||
|
||||
### **6.10. Monitoring และ Observability**
|
||||
|
||||
- **6.10.1 Application Monitoring:**
|
||||
- **Health checks:** /health endpoint สำหรับ load balancer
|
||||
- **Metrics collection:** Response times, error rates, throughput
|
||||
- **Distributed tracing:** สำหรับ request tracing across services
|
||||
- **Log aggregation:** Structured logging ด้วย JSON format
|
||||
- **Alerting:** สำหรับ critical errors และ performance degradation
|
||||
- **6.10.2 Business Metrics:**
|
||||
- จำนวน documents created ต่อวัน
|
||||
- Workflow completion rates
|
||||
- User activity metrics
|
||||
- System utilization rates
|
||||
- Search query performance
|
||||
- **6.10.3 Security Monitoring:**
|
||||
- Failed login attempts
|
||||
- Rate limiting triggers
|
||||
- Virus scan results
|
||||
- File download activities
|
||||
- Permission changes
|
||||
|
||||
### **6.11 JSON Processing & Validation**
|
||||
|
||||
- **6.11.1 JSON Schema Management**
|
||||
- ต้องมี centralized JSON schema registry
|
||||
- ต้องรองรับ schema versioning และ migration
|
||||
- ต้องมี schema validation during runtime
|
||||
- **6.11.2 Performance Optimization**
|
||||
- **Caching:** Cache parsed JSON structures
|
||||
- **Compression:** ใช้ compression สำหรับ JSON ขนาดใหญ่
|
||||
- **Indexing:** Support JSON path indexing สำหรับ query
|
||||
- **6.11.3 Error Handling**
|
||||
- ต้องมี graceful degradation เมื่อ JSON validation ล้มเหลว
|
||||
- ต้องมี default fallback values
|
||||
- ต้องบันทึก error logs สำหรับ validation failures
|
||||
|
||||
## **🧪 7. ข้อกำหนดด้านการทดสอบ (Testing Requirements)**
|
||||
|
||||
### **7.1. Unit Testing:**
|
||||
|
||||
- ต้องมี unit tests สำหรับ business logic ทั้งหมด
|
||||
- Code coverage อย่างน้อย 70% สำหรับ backend services
|
||||
- ต้องทดสอบ RBAC permission logic ทุกระดับ
|
||||
|
||||
### **7.2. Integration Testing:**
|
||||
|
||||
- ทดสอบการทำงานร่วมกันของ modules
|
||||
- ทดสอบ database migrations และ data integrity
|
||||
- ทดสอบ API endpoints ด้วย realistic data
|
||||
|
||||
### **7.3. End-to-End Testing:**
|
||||
|
||||
- ทดสอบ complete user workflows
|
||||
- ทดสอบ document lifecycle จาก creation ถึง archival
|
||||
- ทดสอบ cross-module integrations
|
||||
|
||||
### **7.4. Security Testing:**
|
||||
|
||||
- **Penetration Testing:** ทดสอบ OWASP Top 10 vulnerabilities
|
||||
- **Security Audit:** Review code สำหรับ security flaws
|
||||
- **Virus Scanning Test:** ทดสอบ file upload security
|
||||
- **Rate Limiting Test:** ทดสอบ rate limiting functionality
|
||||
|
||||
### **7.5. Performance Testing:**
|
||||
|
||||
- **Load Testing:** ทดสอบด้วย realistic workloads
|
||||
- **Stress Testing:** หา breaking points ของระบบ
|
||||
- **Endurance Testing:** ทดสอบการทำงานต่อเนื่องเป็นเวลานาน
|
||||
|
||||
### **7.6. Disaster Recovery Testing:**
|
||||
|
||||
- ทดสอบ backup และ restoration procedures
|
||||
- ทดสอบ failover mechanisms
|
||||
- ทดสอบ data integrity หลังการ recovery
|
||||
|
||||
### **7.7 Specific Scenario Testing (เพิ่ม)**
|
||||
|
||||
- **Race Condition Test:** ทดสอบยิง Request ขอเลขที่เอกสารพร้อมกัน 100 Request
|
||||
- **Transaction Test:** ทดสอบปิดเน็ตระหว่าง Upload ไฟล์ (ตรวจสอบว่าไม่มี Orphan File หรือ Broken Link)
|
||||
- **Permission Test:** ทดสอบ CASL Integration ทั้งฝั่ง Backend และ Frontend ให้ตรงกัน
|
||||
|
||||
## **8. ข้อกำหนดด้านการบำรุงรักษา (Maintenance Requirements)**
|
||||
|
||||
### **8.1. Log Retention:**
|
||||
|
||||
- Audit logs: 7 ปี
|
||||
- Application logs: 1 ปี
|
||||
- Performance metrics: 2 ปี
|
||||
|
||||
### **8.2. Monitoring และ Alerting:**
|
||||
|
||||
- ต้องมี proactive monitoring สำหรับ critical systems
|
||||
- ต้องมี alerting สำหรับ security incidents
|
||||
- ต้องมี performance degradation alerts
|
||||
|
||||
### **8.3. Patch Management:**
|
||||
|
||||
- ต้องมี process สำหรับ security patches
|
||||
- ต้องทดสอบ patches ใน staging environment
|
||||
- ต้องมี rollback plan สำหรับ failed updates
|
||||
|
||||
### **8.4. Capacity Planning:**
|
||||
|
||||
- ต้อง monitor resource utilization
|
||||
- ต้องมี scaling strategy สำหรับ growth
|
||||
- ต้องมี performance baselines และ trending
|
||||
|
||||
## **9. ข้อกำหนดด้านการปฏิบัติตามกฎระเบียบ (Compliance Requirements)**
|
||||
|
||||
### **9.1. Data Privacy:**
|
||||
|
||||
- ต้องปฏิบัติตามกฎหมายคุ้มครองข้อมูลส่วนบุคคล
|
||||
- ต้องมี data retention policies
|
||||
- ต้องมี data deletion procedures
|
||||
|
||||
### **9.2. Audit Compliance:**
|
||||
|
||||
- ต้องรองรับ internal และ external audits
|
||||
- ต้องมี comprehensive audit trails
|
||||
- ต้องมี reporting capabilities สำหรับ compliance
|
||||
|
||||
### **9.3. Security Standards:**
|
||||
|
||||
- ต้องปฏิบัติตาม organizational security policies
|
||||
- ต้องมี security incident response plan
|
||||
- ต้องมี regular security assessments
|
||||
|
||||
## **📋 สรุปการปรับปรุงจากเวอร์ชันก่อนหน้า**
|
||||
|
||||
### **Security Enhancements:**
|
||||
|
||||
1. **File Upload Security** - Virus scanning, file type validation, access controls
|
||||
2. **Input Validation** - OWASP Top 10 protection, XSS/CSRF prevention
|
||||
3. **Rate Limiting** - Comprehensive rate limiting strategy
|
||||
4. **Secrets Management** - Secure handling of sensitive configuration
|
||||
|
||||
### **Architecture Improvements:**
|
||||
|
||||
1. **Document Numbering** - Changed from Stored Procedure to Application-level Locking with Optimistic Locking safety net
|
||||
2. **Resilience Patterns** - Circuit breaker, retry mechanisms, fallback strategies
|
||||
3. **Monitoring & Observability** - Health checks, metrics, distributed tracing
|
||||
4. **Caching Strategy** - Comprehensive caching with proper invalidation
|
||||
5. **Two-Phase File Storage** - Temp -> Permanent storage with transaction safety
|
||||
6. **Unified Workflow Engine** - Consolidated routing logic for better maintainability
|
||||
|
||||
### **Performance Targets:**
|
||||
|
||||
1. **API Response Time** - < 200ms (90th percentile)
|
||||
2. **Search Performance** - < 500ms
|
||||
3. **File Upload** - < 30 seconds for 50MB files
|
||||
4. **Cache Hit Ratio** - > 80%
|
||||
|
||||
### **Operational Excellence:**
|
||||
|
||||
1. **Disaster Recovery** - RTO < 4 hours, RPO < 1 hour
|
||||
2. **Backup Procedures** - Comprehensive backup and restoration
|
||||
3. **Security Testing** - Penetration testing and security audits
|
||||
4. **Performance Testing** - Load testing with realistic workloads
|
||||
5. **Maintenance Mode** - Graceful system maintenance capabilities
|
||||
|
||||
### **User Experience Improvements:**
|
||||
|
||||
1. **Dynamic Form Generator** - Reduced code duplication and better schema support
|
||||
2. **Mobile Responsiveness** - Card view for tables on mobile devices
|
||||
3. **Auto-Save Draft** - LocalStorage integration for form resilience
|
||||
4. **Notification Digest** - Reduced notification spam
|
||||
|
||||
### **Data Management:**
|
||||
|
||||
1. **Virtual Columns** - Improved JSON field search performance
|
||||
2. **Table Partitioning** - Support for large-scale data growth
|
||||
3. **Idempotency Keys** - Prevention of duplicate transactions
|
||||
|
||||
เอกสารนี้สะท้อนถึงความมุ่งมั่นในการสร้างระบบที่มีความปลอดภัย, มีความทนทาน, และมีประสิทธิภาพสูง พร้อมรองรับการเติบโตในอนาคตและความต้องการทางธุรกิจที่เปลี่ยนแปลงไป
|
||||
|
||||
**หมายเหตุ:** Requirements นี้จะถูกทบทวนและปรับปรุงเป็นระยะตาม feedback จากทีมพัฒนาและความต้องการทางธุรกิจที่เปลี่ยนแปลงไป
|
||||
|
||||
## **Document Control:**
|
||||
|
||||
- **Document:** Application Requirements Specification v1.4.4
|
||||
- **Version:** 1.4
|
||||
- **Date:** 2025-11-26
|
||||
- **Author:** NAP LCBP3-DMS & Gemini
|
||||
- **Status:** FINAL-Rev.04
|
||||
- **Classification:** Internal Technical Documentation
|
||||
- **Approved By:** Nattanin
|
||||
|
||||
---
|
||||
|
||||
`End of Requirements Specification v1.4.4`
|
||||
@@ -0,0 +1,975 @@
|
||||
# 📝 **Documents Management System Version 1.4.4: แนวทางการพัฒนา FullStackJS**
|
||||
|
||||
**สถานะ:** FINAL GUIDELINE Rev.04
|
||||
**วันที่:** 2025-11-26
|
||||
**อ้างอิง:** Requirements Specification v1.4.3
|
||||
**Classification:** Internal Technical Documentation
|
||||
|
||||
## 🧠 **1. ปรัชญาทั่วไป (General Philosophy)**
|
||||
|
||||
แนวทางปฏิบัติที่ดีที่สุดแบบครบวงจรสำหรับการพัฒนา NestJS Backend, NextJS Frontend และ Tailwind-based UI/UX ในสภาพแวดล้อม TypeScript มุ่งเน้นที่ **"Data Integrity First"** (ความถูกต้องของข้อมูลต้องมาก่อน) ตามด้วย Security และ UX
|
||||
|
||||
* **ความชัดเจน (clarity), ความง่ายในการบำรุงรักษา (maintainability), ความสอดคล้องกัน (consistency) และ การเข้าถึงได้ (accessibility)** ตลอดทั้งสแต็ก
|
||||
* **Strict Typing:** ใช้ TypeScript อย่างเคร่งครัด ห้าม `any`
|
||||
* **Consistency:** ใช้ภาษาอังกฤษใน Code / ภาษาไทยใน Comment
|
||||
* **Resilience:** ระบบต้องทนทานต่อ Network Failure และ Race Condition
|
||||
|
||||
## ⚙️ **2. แนวทางทั่วไปสำหรับ TypeScript**
|
||||
|
||||
### **2.1 หลักการพื้นฐาน**
|
||||
|
||||
* ใช้ **ภาษาอังกฤษ** สำหรับโค้ด
|
||||
* ใช้ **ภาษาไทย** สำหรับ comment และเอกสารทั้งหมด
|
||||
* กำหนดไทป์ (type) อย่างชัดเจนสำหรับตัวแปร, พารามิเตอร์ และค่าที่ส่งกลับ (return values) ทั้งหมด
|
||||
* หลีกเลี่ยงการใช้ any; ให้สร้างไทป์ (types) หรืออินเทอร์เฟซ (interfaces) ที่กำหนดเอง
|
||||
* ใช้ **JSDoc** สำหรับคลาส (classes) และเมธอด (methods) ที่เป็น public
|
||||
* ส่งออก (Export) **สัญลักษณ์หลัก (main symbol) เพียงหนึ่งเดียว** ต่อไฟล์
|
||||
* หลีกเลี่ยงบรรทัดว่างภายในฟังก์ชัน
|
||||
* ระบุ // File: path/filename ในบรรทัดแรกของทุกไฟล์
|
||||
* ระบุ // บันทึกการแก้ไข, หากมีการแก้ไขเพิ่มในอนาคต ให้เพิ่มบันทึก
|
||||
|
||||
### **2.2 Configuration & Secrets Management**
|
||||
|
||||
* **Production/Staging:** ห้ามใส่ Secrets (Password, Keys) ใน `docker-compose.yml` หลัก
|
||||
* **Development:** ให้สร้างไฟล์ `docker-compose.override.yml` (เพิ่มใน `.gitignore`) เพื่อ Inject ตัวแปร Environment ที่เป็นความลับ
|
||||
* **Validation:** ใช้ `joi` หรือ `zod` ในการ Validate Environment Variables ตอน Start App หากขาดตัวแปรสำคัญให้ Throw Error ทันที
|
||||
|
||||
### **2.3 Idempotency (ความสามารถในการทำซ้ำได้)**
|
||||
|
||||
* สำหรับการทำงานที่สำคัญ (Create Document, Approve, Transactional) **ต้อง** ออกแบบให้เป็น Idempotent
|
||||
* Client **ต้อง** ส่ง Header `Idempotency-Key` (UUID) มากับ Request
|
||||
* Server **ต้อง** ตรวจสอบว่า Key นี้เคยถูกประมวลผลสำเร็จไปแล้วหรือไม่ ถ้าใช่ ให้คืนค่าเดิมโดยไม่ทำซ้ำ
|
||||
|
||||
### **2.4 ข้อตกลงในการตั้งชื่อ (Naming Conventions)**
|
||||
|
||||
| Entity (สิ่งที่ตั้งชื่อ) | Convention (รูปแบบ) | Example (ตัวอย่าง) |
|
||||
| :-------------------- | :----------------- | :--------------------------------- |
|
||||
| Classes | PascalCase | UserService |
|
||||
| Property | snake_case | user_id |
|
||||
| Variables & Functions | camelCase | getUserInfo |
|
||||
| Files & Folders | kebab-case | user-service.ts |
|
||||
| Environment Variables | UPPERCASE | DATABASE_URL |
|
||||
| Booleans | Verb + Noun | isActive, canDelete, hasPermission |
|
||||
|
||||
ใช้คำเต็ม — ไม่ใช้อักษรย่อ — ยกเว้นคำมาตรฐาน (เช่น API, URL, req, res, err, ctx)
|
||||
|
||||
### 🧩**2.5 ฟังก์ชัน (Functions)**
|
||||
|
||||
* เขียนฟังก์ชันให้สั้น และทำ **หน้าที่เพียงอย่างเดียว** (single-purpose) (\< 20 บรรทัด)
|
||||
* ใช้ **early returns** เพื่อลดการซ้อน (nesting) ของโค้ด
|
||||
* ใช้ **map**, **filter**, **reduce** แทนการใช้ loops เมื่อเหมาะสม
|
||||
* ควรใช้ **arrow functions** สำหรับตรรกะสั้นๆ, และใช้ **named functions** ในกรณีอื่น
|
||||
* ใช้ **default parameters** แทนการตรวจสอบค่า null
|
||||
* จัดกลุ่มพารามิเตอร์หลายตัวให้เป็นอ็อบเจกต์เดียว (RO-RO pattern)
|
||||
* ส่งค่ากลับ (Return) เป็นอ็อบเจกต์ที่มีไทป์กำหนด (typed objects) ไม่ใช่ค่าพื้นฐาน (primitives)
|
||||
* รักษาระดับของสิ่งที่เป็นนามธรรม (abstraction level) ให้เป็นระดับเดียวในแต่ละฟังก์ชัน
|
||||
|
||||
### 🧱**2.6 การจัดการข้อมูล (Data Handling)**
|
||||
|
||||
* ห่อหุ้มข้อมูล (Encapsulate) ในไทป์แบบผสม (composite types)
|
||||
* ใช้ **immutability** (การไม่เปลี่ยนแปลงค่า) ด้วย readonly และ as const
|
||||
* ทำการตรวจสอบความถูกต้องของข้อมูล (Validations) ในคลาสหรือ DTOs ไม่ใช่ภายในฟังก์ชันทางธุรกิจ
|
||||
* ตรวจสอบความถูกต้องของข้อมูลโดยใช้ DTOs ที่มีไทป์กำหนดเสมอ
|
||||
|
||||
### 🧰**2.7 คลาส (Classes)**
|
||||
|
||||
* ปฏิบัติตามหลักการ **SOLID**
|
||||
* ควรใช้ **composition มากกว่า inheritance** (Prefer composition over inheritance)
|
||||
* กำหนด **interfaces** สำหรับสัญญา (contracts)
|
||||
* ให้คลาสมุ่งเน้นการทำงานเฉพาะอย่างและมีขนาดเล็ก (\< 200 บรรทัด, \< 10 เมธอด, \< 10 properties)
|
||||
|
||||
### 🚨**2.8 การจัดการข้อผิดพลาด (Error Handling)**
|
||||
|
||||
* ใช้ Exceptions สำหรับข้อผิดพลาดที่ไม่คาดคิด
|
||||
* ดักจับ (Catch) ข้อผิดพลาดเพื่อแก้ไขหรือเพิ่มบริบท (context) เท่านั้น; หากไม่เช่นนั้น ให้ใช้ global error handlers
|
||||
* ระบุข้อความข้อผิดพลาด (error messages) ที่มีความหมายเสมอ
|
||||
|
||||
### 🧪**2.9 การทดสอบ (ทั่วไป) (Testing (General))**
|
||||
|
||||
* ใช้รูปแบบ **Arrange–Act–Assert**
|
||||
* ใช้ชื่อตัวแปรในการทดสอบที่สื่อความหมาย (inputData, expectedOutput)
|
||||
* เขียน **unit tests** สำหรับ public methods ทั้งหมด
|
||||
* จำลอง (Mock) การพึ่งพาภายนอก (external dependencies)
|
||||
* เพิ่ม **acceptance tests** ต่อโมดูลโดยใช้รูปแบบ Given–When-Then
|
||||
|
||||
### **Testing Strategy โดยละเอียด**
|
||||
|
||||
* **Test Pyramid Structure**
|
||||
|
||||
/\
|
||||
/ \ E2E Tests (10%)
|
||||
/____\ Integration Tests (20%)
|
||||
/ \ Unit Tests (70%)
|
||||
/________\
|
||||
|
||||
* **Testing Tools Stack**
|
||||
|
||||
```typescript
|
||||
// Backend Testing Stack
|
||||
const backendTesting = {
|
||||
unit: ['Jest', 'ts-jest', '@nestjs/testing'],
|
||||
integration: ['Supertest', 'Testcontainers', 'Jest'],
|
||||
e2e: ['Supertest', 'Jest', 'Database Seeds'],
|
||||
security: ['Jest', 'Custom Security Test Helpers'],
|
||||
performance: ['Jest', 'autocannon', 'artillery']
|
||||
};
|
||||
|
||||
// Frontend Testing Stack
|
||||
const frontendTesting = {
|
||||
unit: ['Vitest', 'React Testing Library'],
|
||||
integration: ['React Testing Library', 'MSW'],
|
||||
e2e: ['Playwright', 'Jest'],
|
||||
visual: ['Playwright', 'Loki']
|
||||
};
|
||||
```
|
||||
|
||||
* **Test Data Management**
|
||||
|
||||
```typescript
|
||||
// Test Data Factories
|
||||
interface TestDataFactory {
|
||||
createUser(overrides?: Partial<User>): User;
|
||||
createCorrespondence(overrides?: Partial<Correspondence>): Correspondence;
|
||||
createRoutingTemplate(overrides?: Partial<RoutingTemplate>): RoutingTemplate;
|
||||
}
|
||||
|
||||
// Test Scenarios
|
||||
const testScenarios = {
|
||||
happyPath: 'Normal workflow execution',
|
||||
edgeCases: 'Boundary conditions and limits',
|
||||
errorConditions: 'Error handling and recovery',
|
||||
security: 'Authentication and authorization',
|
||||
performance: 'Load and stress conditions'
|
||||
};
|
||||
```
|
||||
|
||||
## 🏗️ **3. แบ็กเอนด์ (NestJS) - Implementation Details**
|
||||
|
||||
### **3.1 หลักการ**
|
||||
|
||||
* **สถาปัตยกรรมแบบโมดูลาร์ (Modular architecture)**:
|
||||
* หนึ่งโมดูลต่อหนึ่งโดเมน
|
||||
* โครงสร้างแบบ Controller → Service → Repository (Model)
|
||||
* API-First: มุ่งเน้นการสร้าง API ที่มีคุณภาพสูง มีเอกสารประกอบ (Swagger) ที่ชัดเจนสำหรับ Frontend Team
|
||||
* DTOs ที่ตรวจสอบความถูกต้องด้วย **class-validator**
|
||||
* ใช้ **MikroORM** (หรือ TypeORM/Prisma) สำหรับการคงอยู่ของข้อมูล (persistence) ซึ่งสอดคล้องกับสคีมา MariaDB
|
||||
* ห่อหุ้มโค้ดที่ใช้ซ้ำได้ไว้ใน **common module** (@app/common):
|
||||
* Configs, decorators, DTOs, guards, interceptors, notifications, shared services, types, validators
|
||||
|
||||
### **3.2 Database & Data Modeling (MariaDB + TypeORM)**
|
||||
|
||||
#### **3.2.1 Optimistic Locking & Versioning**
|
||||
|
||||
เพื่อป้องกัน Race Condition ในการแก้ไขข้อมูลพร้อมกัน (โดยเฉพาะการรันเลขที่เอกสาร) ให้เพิ่ม Column `@VersionColumn()` ใน Entity ที่สำคัญ
|
||||
|
||||
```typescript
|
||||
@Entity()
|
||||
export class DocumentCounter {
|
||||
// ... fields
|
||||
@Column()
|
||||
last_number: number;
|
||||
|
||||
@VersionColumn() // เพิ่ม Versioning
|
||||
version: number;
|
||||
}
|
||||
```
|
||||
|
||||
#### **3.2.2 Virtual Columns for JSON Performance**
|
||||
|
||||
เนื่องจากเราใช้ MariaDB 10.11 และมีการเก็บข้อมูล JSON (Details) ให้ใช้ **Generated Columns (Virtual)** สำหรับ Field ที่ต้อง Search/Sort บ่อยๆ และทำ Index บน Virtual Column นั้น
|
||||
|
||||
```sql
|
||||
-- ตัวอย่าง SQL Migration
|
||||
ALTER TABLE correspondence_revisions
|
||||
ADD COLUMN ref_project_id INT GENERATED ALWAYS AS (JSON_UNQUOTE(JSON_EXTRACT(details, '$.projectId'))) VIRTUAL;
|
||||
CREATE INDEX idx_ref_project_id ON correspondence_revisions(ref_project_id);
|
||||
```
|
||||
|
||||
#### **3.2.3 Partitioning Strategy**
|
||||
|
||||
สำหรับตาราง `audit_logs` และ `notifications` ให้เตรียมออกแบบ Entity ให้รองรับ Partitioning (เช่น แยกตามปี) โดยใช้ Raw SQL Migration ในการสร้างตาราง
|
||||
|
||||
### **3.3 File Storage Service (Two-Phase Storage)**
|
||||
|
||||
ปรับปรุง Service จัดการไฟล์ให้รองรับ Transactional Integrity
|
||||
|
||||
1. **Upload (Phase 1):**
|
||||
* รับไฟล์ → Scan Virus (ClamAV) → Save ลงโฟลเดอร์ `temp/`
|
||||
* Return `temp_id` และ Metadata กลับไปให้ Client
|
||||
2. **Commit (Phase 2):**
|
||||
* เมื่อ Business Logic (เช่น Create Correspondence) ทำงานสำเร็จ
|
||||
* Service จะย้ายไฟล์จาก `temp/` ไปยัง `permanent/{YYYY}/{MM}/`
|
||||
* Update path ใน Database
|
||||
* ทั้งหมดนี้ต้องอยู่ภายใต้ Database Transaction เดียวกัน (ถ้า DB Fail, ไฟล์จะค้างที่ Temp และถูกลบโดย Cron Job)
|
||||
|
||||
### **3.4 Document Numbering (Double-Lock Mechanism)**
|
||||
|
||||
การออกเลขที่เอกสารต้องใช้กลไกความปลอดภัย 2 ชั้น:
|
||||
|
||||
1. **Layer 1 (Redis Lock):** ใช้ `redlock` เพื่อ Block ไม่ให้ Process อื่นเข้ามายุ่งกับ Counter ของ Project/Type นั้นๆ ชั่วคราว
|
||||
2. **Layer 2 (Optimistic Lock):** ตอน Update Database ให้เช็ค `version` ถ้า version เปลี่ยน (แสดงว่า Redis Lock หลุดหรือมีคนแทรก) ให้ Throw Error และ Retry ใหม่
|
||||
|
||||
### **3.5 Unified Workflow Engine**
|
||||
|
||||
ห้ามแยก Logic ระหว่าง `CorrespondenceRouting` และ `RfaWorkflow` ออกจากกันเด็ดขาด ให้สร้าง `WorkflowEngineService` ที่เป็น Generic:
|
||||
|
||||
* **Input:** `currentState`, `action`, `rules (Guard)`
|
||||
* **Output:** `nextState`, `assignee`
|
||||
* รองรับทั้ง Linear Flow (Routing) และ Complex Flow (RFA) ผ่าน Configuration
|
||||
|
||||
### **3.6 ฟังก์ชันหลัก (Core Functionalities)**
|
||||
|
||||
* Global **filters** สำหรับการจัดการ exception
|
||||
* **Middlewares** สำหรับการจัดการ request
|
||||
* **Guards** สำหรับการอนุญาต (permissions) และ RBAC
|
||||
* **Interceptors** สำหรับการแปลงข้อมูล response และการบันทึก log
|
||||
|
||||
### **3.7 ข้อจำกัดในการ Deploy (QNAP Container Station)**
|
||||
|
||||
* **ห้ามใช้ไฟล์ .env** ในการตั้งค่า Environment Variables [cite: 2.1]
|
||||
* การตั้งค่าทั้งหมด (เช่น Database connection string, JWT secret) **จะต้องถูกกำหนดผ่าน Environment Variable ใน docker-compose.yml โดยตรง** [cite: 6.5] ซึ่งจะจัดการผ่าน UI ของ QNAP Container Station [cite: 2.1]
|
||||
|
||||
### **3.8 ข้อจำกัดด้านความปลอดภัย (Security Constraints):**
|
||||
|
||||
* **File Upload Security:** ต้องมี virus scanning (ClamAV), file type validation (white-list), และ file size limits (50MB)
|
||||
* **Input Validation:** ต้องป้องกัน OWASP Top 10 vulnerabilities (SQL Injection, XSS, CSRF)
|
||||
* **Rate Limiting:** ต้อง implement rate limiting ตาม strategy ที่กำหนด
|
||||
* **Secrets Management:** ต้องมี mechanism สำหรับจัดการ sensitive secrets อย่างปลอดภัย แม้จะใช้ docker-compose.yml
|
||||
|
||||
### **3.9 โครงสร้างโมดูลตามโดเมน (Domain-Driven Module Structure)**
|
||||
|
||||
เพื่อให้สอดคล้องกับสคีมา SQL (LCBP3-DMS) เราจะใช้โครงสร้างโมดูลแบบ **Domain-Driven (แบ่งตามขอบเขตธุรกิจ)** แทนการแบ่งตามฟังก์ชัน:
|
||||
|
||||
#### 3.9.1 **CommonModule:**
|
||||
|
||||
* เก็บ Services ที่ใช้ร่วมกัน เช่น DatabaseModule, FileStorageService (จัดการไฟล์ใน QNAP), AuditLogService, NotificationService
|
||||
* จัดการ audit_logs
|
||||
* NotificationService ต้องรองรับ Triggers ที่ระบุใน Requirement 6.7 [cite: 6.7]
|
||||
|
||||
#### 3.9.2 **AuthModule:**
|
||||
|
||||
* จัดการะการยืนยันตัวตน (JWT, Guards)
|
||||
* **(สำคัญ)** ต้องรับผิดชอบการตรวจสอบสิทธิ์ **4 ระดับ** [cite: 4.2]: สิทธิ์ระดับระบบ (Global Role), สิทธิ์ระดับองกรณ์ (Organization Role), สิทธิ์ระดับโปรเจกต์ (Project Role), และ สิทธิ์ระดับสัญญา (Contract Role)
|
||||
* **(สำคัญ)** ต้องมี API สำหรับ **Admin Panel** เพื่อ:
|
||||
* สร้างและจัดการ Role และการจับคู่ Permission แบบไดนามิก [cite: 4.3]
|
||||
* ให้ Superadmin สร้าง Organizations และกำหนด Org Admin ได้ [cite: 4.6]
|
||||
* ให้ Superadmin/Admin จัดการ document_number_formats (รูปแบบเลขที่เอกสาร), document_number_counters (Running Number) [cite: 3.10]
|
||||
|
||||
#### 3.9.3 **UserModule:**
|
||||
|
||||
* จัดการ users, roles, permissions, global_default_roles, role_permissions, user_roles, user_project_roles
|
||||
* **(สำคัญ)** ต้องมี API สำหรับ **Admin Panel** เพื่อ:
|
||||
* สร้างและจัดการ Role และการจับคู่ Permission แบบไดนามิก [cite: 4.3]
|
||||
|
||||
#### 3.9.4 **ProjectModule:**
|
||||
|
||||
* จัดการ projects, organizations, contracts, project_parties, contract_parties
|
||||
|
||||
#### 3.9.5 **MasterModule:**
|
||||
|
||||
* จัดการ master data (correspondence_types, rfa_types, rfa_status_codes, rfa_approve_codes, circulation_status_codes, correspondence_types, correspondence_status, tags) [cite: 4.5]
|
||||
|
||||
#### 3.9.6 **CorrespondenceModule (โมดูลศูนย์กลาง):**
|
||||
|
||||
* จัดการ correspondences, correspondence_revisions, correspondence_tags
|
||||
* **(สำคัญ)** Service นี้ต้อง Inject DocumentNumberingService เพื่อขอเลขที่เอกสารใหม่ก่อนการสร้าง
|
||||
* **(สำคัญ)** ตรรกะการสร้าง/อัปเดต Revision จะอยู่ใน Service นี้
|
||||
* จัดการ correspondence_attachments (ตารางเชื่อมไฟล์แนบ)
|
||||
* รับผิดชอบ Routing **Correspondence Routing** (correspondence_routings, correspondence_routing_template_steps, correspondence_routing_templates, correspondence_status_transitions) สำหรับการส่งต่อเอกสารทั่วไประหว่างองค์กร
|
||||
|
||||
#### 3.9.7 **RfaModule:**
|
||||
|
||||
* จัดการ rfas, rfa_revisions, rfa_items
|
||||
* รับผิดชอบเวิร์กโฟลว์ **"RFA Workflows"** (rfa_workflows, rfa_workflow_templates, rfa_workflow_template_steps, rfa_status_transitions) สำหรับการอนุมัติเอกสารทางเทคนิค
|
||||
|
||||
#### 3.9.8 **DrawingModule:**
|
||||
|
||||
* จัดการ shop_drawings, shop_drawing_revisions, contract_drawings, contract_drawing_volumes, contract_drawing_cats, contract_drawing_sub_cats, shop_drawing_main_categories, shop_drawing_sub_categories, contract_drawing_subcat_cat_maps, shop_drawing_revision_contract_refs
|
||||
* จัดการ shop_drawing_revision_attachments และ contract_drawing_attachments(ตารางเชื่อมไฟล์แนบ)
|
||||
|
||||
#### 3.9.9 **CirculationModule:**
|
||||
|
||||
* จัดการ circulations, circulation_templates, circulation_assignees
|
||||
* จัดการ circulation_attachments (ตารางเชื่อมไฟล์แนบ)
|
||||
* รับผิดชอบเวิร์กโฟลว์ **"Circulations"** (circulation_status_transitions, circulation_template_assignees, circulation_assignees, circulation_recipients, circulation_actions, circulation_action_documents)สำหรับการเวียนเอกสาร **ภายในองค์กร**
|
||||
|
||||
#### 3.9.10 **TransmittalModule:**
|
||||
|
||||
* จัดการ transmittals และ transmittal_items
|
||||
|
||||
#### 3.9.11 **SearchModule:**
|
||||
|
||||
* ให้บริการค้นหาขั้นสูง (Advanced Search) [cite: 6.2] โดยใช้ **Elasticsearch** เพื่อรองรับการค้นหาแบบ Full-text จากชื่อเรื่อง, รายละเอียด, เลขที่เอกสาร, ประเภท, วันที่, และ Tags
|
||||
* ระบบจะใช้ Elasticsearch Engine ในการจัดทำดัชนีเพื่อการค้นหาข้อมูลเชิงลึกจากเนื้อหาของเอกสาร โดยข้อมูลจะถูกส่งไปทำดัชนีจาก Backend (NestJS) ทุกครั้งที่มีการสร้างหรือแก้ไขเอกสาร
|
||||
|
||||
#### 3.9.12 **DocumentNumberingModule:**
|
||||
|
||||
* **สถานะ:** เป็น Module ภายใน (Internal Module) ไม่เปิด API สู่ภายนอก
|
||||
* **หน้าที่:** ให้บริการ `DocumentNumberingService` แบบ **Token-Based Generator**
|
||||
* **Logic ใหม่ (v1.4.4):**
|
||||
* รับ Context: `{ projectId, orgId, typeId, disciplineId?, subTypeId?, year }`
|
||||
* ดึง Template จาก DB
|
||||
* Parse Template เพื่อหาว่าต้องใช้ Key ใดบ้างในการทำ Grouping Counter (เช่น ถ้า Template มี `{DISCIPLINE}` ให้ใช้ `discipline_id` ในการ query counter)
|
||||
* ใช้ **Double-Lock Mechanism** (Redis + Optimistic DB Lock) ในการดึงและอัพเดทค่า `last_number`
|
||||
* **Features:**
|
||||
* Application-level locking เพื่อป้องกัน race condition
|
||||
* Retry mechanism ด้วย exponential backoff
|
||||
* Fallback mechanism เมื่อการขอเลขล้มเหลว
|
||||
* Audit log ทุกครั้งที่มีการ generate เลขที่เอกสารใหม่
|
||||
|
||||
#### 3.9.13 **CorrespondenceRoutingModule:**
|
||||
|
||||
* **สถานะ:** โมดูลหลักสำหรับจัดการการส่งต่อเอกสาร
|
||||
* **หน้าที่:** จัดการแม่แบบการส่งต่อและการส่งต่อจริง
|
||||
* **Entities:**
|
||||
* CorrespondenceRoutingTemplate
|
||||
* CorrespondenceRoutingTemplateStep
|
||||
* CorrespondenceRouting
|
||||
* **Features:**
|
||||
* สร้างและจัดการแม่แบบการส่งต่อ
|
||||
* ดำเนินการส่งต่อเอกสารตามแม่แบบ
|
||||
* ติดตามสถานะการส่งต่อ
|
||||
* คำนวณวันครบกำหนดอัตโนมัติ
|
||||
* ส่งการแจ้งเตือนเมื่อมีการส่งต่อใหม่
|
||||
|
||||
#### 3.9.14 **WorkflowEngineModule:**
|
||||
|
||||
* **สถานะ:** Internal Module สำหรับจัดการ workflow logic
|
||||
* **หน้าที่:** ประมวลผล state transitions และ business rules
|
||||
* **Features:**
|
||||
* State machine สำหรับสถานะเอกสาร
|
||||
* Validation rules สำหรับการเปลี่ยนสถานะ
|
||||
* Automatic status updates
|
||||
* Deadline management และ escalation
|
||||
|
||||
#### 3.9.15 **JsonSchemaModule:**
|
||||
|
||||
* **สถานะ:** Internal Module สำหรับจัดการ JSON schemas
|
||||
* **หน้าที่:** Validate, transform, และ manage JSON data structures
|
||||
* **Features:**
|
||||
* JSON schema validation ด้วย AJV
|
||||
* Schema versioning และ migration
|
||||
* Dynamic schema generation
|
||||
* Data transformation และ sanitization
|
||||
|
||||
#### 3.9.16 **DetailsService:**
|
||||
|
||||
* **สถานะ:** Shared Service สำหรับจัดการ details fields
|
||||
* **หน้าที่:** Centralized service สำหรับ JSON details operations
|
||||
* **Methods:**
|
||||
* validateDetails(type: string, data: any): ValidationResult
|
||||
* transformDetails(input: any, targetVersion: string): any
|
||||
* sanitizeDetails(data: any): any
|
||||
* getDefaultDetails(type: string): any
|
||||
|
||||
### **3.10 สถาปัตยกรรมระบบ (System Architecture)**
|
||||
|
||||
โครงสร้างโมดูล (Module Structure)
|
||||
|
||||
```bash
|
||||
📁 src
|
||||
├── 📄 app.module.ts
|
||||
├── 📄 main.ts
|
||||
├── 📁 common # @app/common (โมดูลส่วนกลาง)
|
||||
│ ├── 📁 auth # AuthModule (JWT, Guards)
|
||||
│ ├── 📁 config # Configuration
|
||||
│ ├── 📁 decorators # Custom Decorators (เช่น @RequirePermission)
|
||||
│ ├── 📁 entities # Shared Entities (User, Role, Permission)
|
||||
│ ├── 📁 exceptions # Global Exception Filters
|
||||
│ ├── 📁 file-storage # FileStorageService (Virus Scanning, Security)
|
||||
│ ├── 📁 guards # Custom Guards (RBAC Guard, RateLimitGuard)
|
||||
│ ├── 📁 interceptors # Interceptors (Audit Log, Transform, Performance)
|
||||
│ ├── 📁 resilience # Circuit Breaker, Retry Patterns
|
||||
│ └── 📁 services # Shared Services (NotificationService, CachingService)
|
||||
├── 📁 modules
|
||||
│ ├── 📁 user # UserModule (จัดการ Users, Roles, Permissions)
|
||||
│ ├── 📁 project # ProjectModule (จัดการ Projects, Organizations, Contracts)
|
||||
│ ├── 📁 correspondence # CorrespondenceModule (จัดการเอกสารโต้ตอบ)
|
||||
│ ├── 📁 rfa # RfaModule (จัดการเอกสารขออนุมัติ)
|
||||
│ ├── 📁 drawing # DrawingModule (จัดการแบบแปลน)
|
||||
│ ├── 📁 circulation # CirculationModule (จัดการใบเวียน)
|
||||
│ ├── 📁 transmittal # TransmittalModule (จัดการเอกสารนำส่ง)
|
||||
│ ├── 📁 search # SearchModule (ค้นหาขั้นสูงด้วย Elasticsearch)
|
||||
│ ├── 📁 monitoring # MonitoringModule (Metrics, Health Checks)
|
||||
│ └── 📁 document-numbering # DocumentNumberingModule (Internal Module)
|
||||
└── 📁 database # Database Migration & Seeding Scripts
|
||||
```
|
||||
|
||||
### **3.11 กลยุทธ์ความทนทานและการจัดการข้อผิดพลาด (Resilience & Error Handling Strategy)**
|
||||
|
||||
* **Circuit Breaker Pattern:** ใช้สำหรับ external service calls (Email, LINE, Elasticsearch)
|
||||
* **Retry Mechanism:** ด้วย exponential backoff สำหรับ transient failures
|
||||
* **Fallback Strategies:** Graceful degradation เมื่อบริการภายนอกล้มเหลว
|
||||
* **Error Handling:** Error messages ต้องไม่เปิดเผยข้อมูล sensitive
|
||||
* **Monitoring:** Centralized error monitoring และ alerting system
|
||||
|
||||
### **3.12 FileStorageService (ปรับปรุงใหม่):**
|
||||
|
||||
* **Virus Scanning:** Integrate ClamAV สำหรับ scan ไฟล์ที่อัปโหลดทั้งหมด
|
||||
* **File Type Validation:** ใช้ white-list approach (PDF, DWG, DOCX, XLSX, ZIP)
|
||||
* **File Size Limits:** 50MB ต่อไฟล์
|
||||
* **Security Measures:**
|
||||
* เก็บไฟล์นอก web root
|
||||
* Download ผ่าน authenticated endpoint เท่านั้น
|
||||
* Download links มี expiration time (24 ชั่วโมง)
|
||||
* File integrity checks (checksum)
|
||||
* Access control checks ก่อนดาวน์โหลด
|
||||
|
||||
### **3.13 เเทคโนโลยีที่ใช้ (Technology Stack)**
|
||||
|
||||
| ส่วน | Library/Tool | หมายเหตุ |
|
||||
| ----------------------- | ---------------------------------------------------- | -------------------------------------- |
|
||||
| **Framework** | `@nestjs/core`, `@nestjs/common` | Core Framework |
|
||||
| **Language** | `TypeScript` | ใช้ TypeScript ทั้งระบบ |
|
||||
| **Database** | `MariaDB 10.11` | ฐานข้อมูลหลัก |
|
||||
| **ORM** | `@nestjs/typeorm`, `typeorm` | 🗃️จัดการการเชื่อมต่อและ Query ฐานข้อมูล |
|
||||
| **Validation** | `class-validator`, `class-transformer` | 📦ตรวจสอบและแปลงข้อมูลใน DTO |
|
||||
| **Auth** | `@nestjs/jwt`, `@nestjs/passport`, `passport-jwt` | 🔐การยืนยันตัวตนด้วย JWT |
|
||||
| **Authorization** | `casl` | 🔐จัดการสิทธิ์แบบ RBAC |
|
||||
| **File Upload** | `multer` | 📁จัดการการอัปโหลดไฟล์ |
|
||||
| **Search** | `@nestjs/elasticsearch` | 🔍สำหรับการค้นหาขั้นสูง |
|
||||
| **Notification** | `nodemailer` | 📬ส่งอีเมลแจ้งเตือน |
|
||||
| **Scheduling** | `@nestjs/schedule` | 📬สำหรับ Cron Jobs (เช่น แจ้งเตือน Deadline) |
|
||||
| **Logging** | `winston` | 📊บันทึก Log ที่มีประสิทธิภาพ |
|
||||
| **Testing** | `@nestjs/testing`, `jest`, `supertest` | 🧪ทดสอบ Unit, Integration และ E2E |
|
||||
| **Documentation** | `@nestjs/swagger` | 🌐สร้าง API Documentation อัตโนมัติ |
|
||||
| **Security** | `helmet`, `rate-limiter-flexible` | 🛡️เพิ่มความปลอดภัยให้ API |
|
||||
| **Resilience** | `@nestjs/circuit-breaker` | 🔄 Circuit breaker pattern |
|
||||
| **Caching** | `@nestjs/cache-manager`, `cache-manager-redis-store` | 💾 Distributed caching |
|
||||
| **Security** | `helmet`, `csurf`, `rate-limiter-flexible` | 🛡️ Security enhancements |
|
||||
| **Validation** | `class-validator`, `class-transformer` | ✅ Input validation |
|
||||
| **Monitoring** | `@nestjs/monitoring`, `winston` | 📊 Application monitoring |
|
||||
| **File Processing** | `clamscan` | 🦠 Virus scanning |
|
||||
| **Cryptography** | `bcrypt`, `crypto` | 🔐 Password hashing และ checksums |
|
||||
| **JSON Validation** | `ajv`, `ajv-formats` | 🎯 JSON schema validation |
|
||||
| **JSON Processing** | `jsonpath`, `json-schema-ref-parser` | 🔧 JSON manipulation |
|
||||
| **Data Transformation** | `class-transformer` | 🔄 Object transformation |
|
||||
| **Compression** | `compression` | 📦 JSON compression |
|
||||
|
||||
### **3.14 Security Testing:**
|
||||
|
||||
* **Penetration Testing:** ทดสอบ OWASP Top 10 vulnerabilities
|
||||
* **Security Audit:** Review code สำหรับ security flaws
|
||||
* **Virus Scanning Test:** ทดสอบ file upload security
|
||||
* **Rate Limiting Test:** ทดสอบ rate limiting functionality
|
||||
|
||||
### **3.15 Performance Testing:**
|
||||
|
||||
* **Load Testing:** ทดสอบด้วย realistic workloads
|
||||
* **Stress Testing:** หา breaking points ของระบบ
|
||||
* **Endurance Testing:** ทดสอบการทำงานต่อเนื่องเป็นเวลานาน
|
||||
|
||||
### 🗄️**3.16 Backend State Management**
|
||||
|
||||
Backend (NestJS) ควรเป็น **Stateless** (ไม่เก็บสถานะ) "State" ทั้งหมดจะถูกจัดเก็บใน MariaDB
|
||||
|
||||
* **Request-Scoped State (สถานะภายใน Request เดียว):**
|
||||
* **ปัญหา:** จะส่งต่อข้อมูล (เช่น User ที่ล็อกอิน) ระหว่าง Guard และ Service ใน Request เดียวกันได้อย่างไร?
|
||||
* **วิธีแก้:** ใช้ **Request-Scoped Providers** ของ NestJS (เช่น AuthContextService) เพื่อเก็บข้อมูล User ปัจจุบันที่ได้จาก AuthGuard และให้ Service อื่น Inject ไปใช้
|
||||
* **Application-Scoped State (การ Caching):**
|
||||
* **ปัญหา:** ข้อมูล Master (เช่น roles, permissions, organizations) ถูกเรียกใช้บ่อย
|
||||
* **วิธีแก้:** ใช้ **Caching** (เช่น @nestjs/cache-manager) เพื่อ Caching ข้อมูลเหล่านี้ และลดภาระ Database
|
||||
|
||||
### **3.17 Caching Strategy (ตามข้อ 6.4.2):**
|
||||
|
||||
* **Master Data Cache:** Roles, Permissions, Organizations (TTL: 1 hour)
|
||||
* **User Session Cache:** User permissions และ profile (TTL: 30 minutes)
|
||||
* **Search Result Cache:** Frequently searched queries (TTL: 15 minutes)
|
||||
* **File Metadata Cache:** Attachment metadata (TTL: 1 hour)
|
||||
* **Cache Invalidation:** Clear cache on update/delete operations
|
||||
|
||||
### **3.18 การไหลของข้อมูล (Data Flow)**
|
||||
|
||||
#### **3.18.1 Main Flow:**
|
||||
|
||||
1. Request: ผ่าน Nginx Proxy Manager -> NestJS Controller
|
||||
2. **Rate Limiting:** RateLimitGuard ตรวจสอบ request limits
|
||||
3. **Input Validation:** Validation Pipe ตรวจสอบและ sanitize inputs
|
||||
4. Authentication: JWT Guard ตรวจสอบ Token และดึงข้อมูล User
|
||||
5. Authorization: RBAC Guard ตรวจสอบสิทธิ์
|
||||
6. **Security Checks:** Virus scanning (สำหรับ file upload), XSS protection
|
||||
7. Business Logic: Service Layer ประมวลผลตรรกะทางธุรกิจ
|
||||
8. **Resilience:** Circuit breaker และ retry logic สำหรับ external calls
|
||||
9. Data Access: Repository Layer ติดต่อกับฐานข้อมูล
|
||||
10. **Caching:** Cache frequently accessed data
|
||||
11. **Audit Log:** บันทึกการกระทำสำคัญ
|
||||
12. Response: ส่งกลับไปยัง Frontend
|
||||
|
||||
#### **3.18.2 Workflow Data Flow:**
|
||||
|
||||
1. User สร้างเอกสาร → เลือก routing template
|
||||
2. System สร้าง routing instances ตาม template
|
||||
3. สำหรับแต่ละ routing step:
|
||||
- กำหนด due date (จาก expected_days)
|
||||
- ส่ง notification ไปยังองค์กรผู้รับ
|
||||
- อัพเดทสถานะเป็น SENT
|
||||
4. เมื่อองค์กรผู้รับดำเนินการ:
|
||||
- อัพเดทสถานะเป็น ACTIONED/FORWARDED/REPLIED
|
||||
- บันทึก processed_by และ processed_at
|
||||
- ส่ง notification ไปยังขั้นตอนต่อไป (ถ้ามี)
|
||||
5. เมื่อครบทุกขั้นตอน → อัพเดทสถานะเอกสารเป็น COMPLETED
|
||||
|
||||
#### **3.18.3 JSON Details Processing Flow:**
|
||||
|
||||
1. **Receive Request** → Get JSON data from client
|
||||
2. **Schema Validation** → Validate against predefined schema
|
||||
3. **Data Sanitization** → Sanitize and transform data
|
||||
4. **Version Check** → Handle schema version compatibility
|
||||
5. **Storage** → Store validated JSON in database
|
||||
6. **Retrieval** → Retrieve and transform on demand
|
||||
|
||||
### 📊**3.19 Monitoring & Observability (ตามข้อ 6.8)**
|
||||
|
||||
#### **Application Monitoring:**
|
||||
|
||||
* **Health Checks:** `/health` endpoint สำหรับ load balancer
|
||||
* **Metrics Collection:** Response times, error rates, throughput
|
||||
* **Distributed Tracing:** สำหรับ request tracing across services
|
||||
* **Log Aggregation:** Structured logging ด้วย JSON format
|
||||
* **Alerting:** สำหรับ critical errors และ performance degradation
|
||||
|
||||
#### **Business Metrics:**
|
||||
|
||||
* จำนวน documents created ต่อวัน
|
||||
* Workflow completion rates
|
||||
* User activity metrics
|
||||
* System utilization rates
|
||||
* Search query performance
|
||||
|
||||
#### **Performance Targets:**
|
||||
|
||||
* API Response Time: < 200ms (90th percentile)
|
||||
* Search Query Performance: < 500ms
|
||||
* File Upload Performance: < 30 seconds สำหรับไฟล์ 50MB
|
||||
* Cache Hit Ratio: > 80%
|
||||
|
||||
## 🖥️ **4. ฟรอนต์เอนด์ (Next.js) - Implementation Details**
|
||||
|
||||
**โปรไฟล์นักพัฒนา (Developer Profile:** วิศวกร TypeScript + React/NextJS ระดับ Senior
|
||||
เชี่ยวชาญ TailwindCSS, Shadcn/UI, และ Radix สำหรับการพัฒนา UI
|
||||
|
||||
### **4.1 State Management & Offline Support**
|
||||
|
||||
#### **4.1.1 Auto-Save Drafts**
|
||||
|
||||
ใช้ `zustand` ร่วมกับ middleware `persist` (ลง LocalStorage) สำหรับฟอร์มที่มีขนาดใหญ่ (RFA, Correspondence) เพื่อป้องกันข้อมูลหายเมื่อเน็ตหลุด
|
||||
|
||||
```typescript
|
||||
// lib/stores/draft-store.ts
|
||||
export const useDraftStore = create(
|
||||
persist(
|
||||
(set) => ({
|
||||
drafts: {},
|
||||
saveDraft: (key, data) => set((state) => ({ drafts: { ...state.drafts, [key]: data } })),
|
||||
clearDraft: (key) => set((state) => {
|
||||
const newDrafts = { ...state.drafts };
|
||||
delete newDrafts[key];
|
||||
return { drafts: newDrafts };
|
||||
}),
|
||||
}),
|
||||
{ name: 'form-drafts' }
|
||||
)
|
||||
);
|
||||
```
|
||||
|
||||
### **4.2 Dynamic Form Generator**
|
||||
|
||||
เพื่อรองรับ JSON Schema หลากหลายรูปแบบ ให้สร้าง Component กลางที่รับ Schema แล้ว Gen Form ออกมา (ลดการแก้ Code บ่อยๆ)
|
||||
|
||||
* **Libraries:** แนะนำ `react-jsonschema-form` หรือสร้าง Wrapper บน `react-hook-form` ที่ Recursively render field ตาม Type
|
||||
* **Validation:** ใช้ `ajv` ที่ฝั่ง Client เพื่อ Validate JSON ก่อน Submit
|
||||
|
||||
### **4.3 Mobile Responsiveness (Card View)**
|
||||
|
||||
ตารางข้อมูล (`DataTable`) ต้องมีความฉลาดในการแสดงผล:
|
||||
|
||||
* **Desktop:** แสดงเป็น Table ปกติ
|
||||
* **Mobile:** แปลงเป็น **Card View** โดยอัตโนมัติ (ซ่อน Header, แสดง Label คู่ Value ในแต่ละ Card)
|
||||
|
||||
```tsx
|
||||
// components/ui/responsive-table.tsx
|
||||
<div className="hidden md:block">
|
||||
<Table>{/* Desktop View */}</Table>
|
||||
</div>
|
||||
<div className="md:hidden space-y-4">
|
||||
{data.map((item) => (
|
||||
<Card key={item.id}>
|
||||
{/* Mobile View: Render cells as list items */}
|
||||
</Card>
|
||||
))}
|
||||
</div>
|
||||
```
|
||||
|
||||
### **4.4 Optimistic Updates**
|
||||
|
||||
ใช้ความสามารถของ **TanStack Query** (`onMutate`) เพื่ออัปเดต UI ทันที (เช่น เปลี่ยนสถานะจาก "รออ่าน" เป็น "อ่านแล้ว") แล้วค่อยส่ง Request ไป Server ถ้า Failed ค่อย Rollback
|
||||
|
||||
### **4.5 แนวทางการพัฒนาโค้ด (Code Implementation Guidelines)**
|
||||
|
||||
* ใช้ **early returns** เพื่อความชัดเจน
|
||||
* ใช้คลาสของ **TailwindCSS** ในการกำหนดสไตล์เสมอ
|
||||
* ควรใช้ class: syntax แบบมีเงื่อนไข (หรือ utility clsx) มากกว่าการใช้ ternary operators ใน class strings
|
||||
* ใช้ **const arrow functions** สำหรับ components และ handlers
|
||||
* Event handlers ให้ขึ้นต้นด้วย handle... (เช่น handleClick, handleSubmit)
|
||||
* รวมแอตทริบิวต์สำหรับการเข้าถึง (accessibility) ด้วย:
|
||||
tabIndex="0", aria-label, onKeyDown, ฯลฯ
|
||||
* ตรวจสอบให้แน่ใจว่าโค้ดทั้งหมด **สมบูรณ์**, **ผ่านการทดสอบ**, และ **ไม่ซ้ำซ้อน (DRY)**
|
||||
* ต้อง import โมดูลที่จำเป็นต้องใช้อย่างชัดเจนเสมอ
|
||||
|
||||
### **4.6 UI/UX ด้วย React**
|
||||
|
||||
* ใช้ **semantic HTML**
|
||||
* ใช้คลาสของ **Tailwind** ที่รองรับ responsive (sm:, md:, lg:)
|
||||
* รักษาลำดับชั้นของการมองเห็น (visual hierarchy) ด้วยการใช้ typography และ spacing
|
||||
* ใช้ **Shadcn** components (Button, Input, Card, ฯลฯ) เพื่อ UI ที่สอดคล้องกัน
|
||||
* ทำให้ components มีขนาดเล็กและมุ่งเน้นการทำงานเฉพาะอย่าง
|
||||
* ใช้ utility classes สำหรับการจัดสไตล์อย่างรวดเร็ว (spacing, colors, text, ฯลฯ)
|
||||
* ตรวจสอบให้แน่ใจว่าสอดคล้องกับ **ARIA** และใช้ semantic markup
|
||||
|
||||
### **4.7 การตรวจสอบฟอร์มและข้อผิดพลาด (Form Validation & Errors)**
|
||||
|
||||
* ใช้ไลบรารีฝั่ง client เช่น zod และ react-hook-form
|
||||
* แสดงข้อผิดพลาดด้วย **alert components** หรือข้อความ inline
|
||||
* ต้องมี labels, placeholders, และข้อความ feedback
|
||||
|
||||
### **🧪4.8 Frontend Testing**
|
||||
|
||||
เราจะใช้ **React Testing Library (RTL)** สำหรับการทดสอบ Component และ **Playwright** สำหรับ E2E:
|
||||
|
||||
* **Unit Tests (การทดสอบหน่วยย่อย):**
|
||||
* **เครื่องมือ:** Vitest + RTL
|
||||
* **เป้าหมาย:** ทดสอบ Component ขนาดเล็ก (เช่น Buttons, Inputs) หรือ Utility functions
|
||||
* **Integration Tests (การทดสอบการบูรณาการ):**
|
||||
* **เครื่องมือ:** RTL + **Mock Service Worker (MSW)**
|
||||
* **เป้าหมาย:** ทดสอบว่า Component หรือ Page ทำงานกับ API (ที่จำลองขึ้น) ได้ถูกต้อง
|
||||
* **เทคนิค:** ใช้ MSW เพื่อจำลอง NestJS API และทดสอบว่า Component แสดงผลข้อมูลจำลองได้ถูกต้องหรือไม่ (เช่น ทดสอบหน้า Dashboard [cite: 5.3] ที่ดึงข้อมูลจาก v_user_tasks)
|
||||
* **E2E (End-to-End) Tests:**
|
||||
* **เครื่องมือ:** **Playwright**
|
||||
* **เป้าหมาย:** ทดสอบ User Flow ทั้งระบบโดยอัตโนมัติ (เช่น ล็อกอิน -> สร้าง RFA -> ตรวจสอบ Workflow Visualization [cite: 5.6])
|
||||
|
||||
### **🗄️4.9 Frontend State Management**
|
||||
|
||||
สำหรับ Next.js App Router เราจะแบ่ง State เป็น 4 ระดับ:
|
||||
|
||||
1. **Local UI State (สถานะ UI ชั่วคราว):**
|
||||
* **เครื่องมือ:** useState, useReducer
|
||||
* **ใช้เมื่อ:** จัดการสถานะเล็กๆ ที่จบใน Component เดียว (เช่น Modal เปิด/ปิด, ค่าใน Input)
|
||||
2. **Server State (สถานะข้อมูลจากเซิร์ฟเวอร์):**
|
||||
* **เครื่องมือ:** **React Query (TanStack Query)** หรือ SWR
|
||||
* **ใช้เมื่อ:** จัดการข้อมูลที่ดึงมาจาก NestJS API (เช่น รายการ correspondences, rfas, drawings)
|
||||
* **ทำไม:** React Query เป็น "Cache" ที่จัดการ Caching, Re-fetching, และ Invalidation ให้โดยอัตโนมัติ
|
||||
3. **Global Client State (สถานะส่วนกลางฝั่ง Client):**
|
||||
* **เครื่องมือ:** **Zustand** (แนะนำ) หรือ Context API
|
||||
* **ใช้เมื่อ:** จัดการข้อมูลที่ต้องใช้ร่วมกันทั่วทั้งแอป และ *ไม่ใช่* ข้อมูลจากเซิร์ฟเวอร์ (เช่น ข้อมูล User ที่ล็อกอิน, สิทธิ์ Permissions)
|
||||
4. **Form State (สถานะของฟอร์ม):**
|
||||
* **เครื่องมือ:** **React Hook Form** + **Zod**
|
||||
* **ใช้เมื่อ:** จัดการฟอร์มที่ซับซ้อน (เช่น ฟอร์มสร้าง RFA, ฟอร์ม Circulation [cite: 3.7])
|
||||
|
||||
## 🔐 **5. Security & Access Control (Full Stack Integration)**
|
||||
|
||||
### **5.1 CASL Integration (Shared Ability)**
|
||||
|
||||
* **Backend:** ใช้ CASL กำหนด Permission Rule
|
||||
* **Frontend:** ให้ดึง Rule (JSON) จาก Backend มา Load ใส่ `@casl/react` เพื่อให้ Logic การ Show/Hide ปุ่ม ตรงกัน 100%
|
||||
|
||||
### **5.2 Maintenance Mode**
|
||||
|
||||
เพิ่ม Middleware (ทั้ง NestJS และ Next.js) เพื่อตรวจสอบ Flag ใน Redis:
|
||||
|
||||
* ถ้า `MAINTENANCE_MODE = true`
|
||||
* **API:** Return `503 Service Unavailable` (ยกเว้น Admin IP)
|
||||
* **Frontend:** Redirect ไปหน้า `/maintenance`
|
||||
|
||||
### **5.3 Idempotency Client**
|
||||
|
||||
สร้าง Axios Interceptor เพื่อ Generate `Idempotency-Key` สำหรับ POST/PUT/DELETE requests ทุกครั้ง
|
||||
|
||||
```typescript
|
||||
// lib/api/client.ts
|
||||
import { v4 as uuidv4 } from 'uuid';
|
||||
|
||||
apiClient.interceptors.request.use((config) => {
|
||||
if (['post', 'put', 'delete'].includes(config.method)) {
|
||||
config.headers['Idempotency-Key'] = uuidv4();
|
||||
}
|
||||
return config;
|
||||
});
|
||||
```
|
||||
|
||||
### **5.4 RBAC และการควบคุมสิทธิ์ (RBAC & Permission Control)**
|
||||
|
||||
ใช้ Decorators เพื่อบังคับใช้สิทธิ์การเข้าถึง โดยอ้างอิงสิทธิ์จากตาราง permissions
|
||||
|
||||
```typescript
|
||||
@RequirePermission('rfas.respond') // ต้องตรงกับ 'permission_code'
|
||||
@Put(':id')
|
||||
updateRFA(@Param('id') id: string) {
|
||||
return this.rfaService.update(id);
|
||||
}
|
||||
```
|
||||
|
||||
#### **5.4.1 Roles (บทบาท)**
|
||||
|
||||
* **Superadmin**: ไม่มีข้อจำกัดใดๆ [cite: 4.3]
|
||||
* **Admin**: มีสิทธิ์เต็มที่ในองค์กร [cite: 4.3]
|
||||
* **Document Control**: เพิ่ม/แก้ไข/ลบ เอกสารในองค์กร [cite: 4.3]
|
||||
* **Editor**: สามารถ เพิ่ม/แก้ไข เอกสารที่กำหนด [cite: 4.3]
|
||||
* **Viewer**: สามารถดู เอกสาร [cite: 4.3]
|
||||
|
||||
#### **5.4.2 ตัวอย่าง Permissions (จากตาราง permissions)**
|
||||
|
||||
* rfas.view, rfas.create, rfas.respond, rfas.delete
|
||||
* drawings.view, drawings.upload, drawings.delete
|
||||
* corr.view, corr.manage
|
||||
* transmittals.manage
|
||||
* cirs.manage
|
||||
* project_parties.manage
|
||||
|
||||
การจับคู่ระหว่าง roles และ permissions **เริ่มต้น** จะถูก seed ผ่านสคริปต์ (ดังที่เห็นในไฟล์ SQL)**อย่างไรก็ตาม AuthModule/UserModule ต้องมี API สำหรับ Admin เพื่อสร้าง Role ใหม่และกำหนดสิทธิ์ (Permissions) เพิ่มเติมได้ในภายหลัง** [cite: 4.3]
|
||||
|
||||
## 📊 **6. Notification & Background Jobs**
|
||||
|
||||
### **6.1 Digest Notification**
|
||||
|
||||
ห้ามส่ง Email ทันทีที่เกิด Event ให้:
|
||||
|
||||
1. Push Event ลง Queue (Redis/BullMQ)
|
||||
2. มี Processor รอเวลา (เช่น 5 นาที) เพื่อ Group Events ที่คล้ายกัน (เช่น "คุณมีเอกสารรออนุมัติ 5 ฉบับ")
|
||||
3. ส่ง Email เดียว (Digest) เพื่อลด Spam
|
||||
|
||||
## 🔗 **7. แนวทางการบูรณาการ Full Stack (Full Stack Integration Guidelines)**
|
||||
|
||||
| Aspect (แง่มุม) | Backend (NestJS) | Frontend (NextJS) | UI Layer (Tailwind/Shadcn) |
|
||||
| :----------------------- | :------------------------- | :---------------------------- | :------------------------------------- |
|
||||
| API | REST / GraphQL Controllers | API hooks ผ่าน fetch/axios/SWR | Components ที่รับข้อมูล |
|
||||
| Validation (การตรวจสอบ) | class-validator DTOs | zod / react-hook-form | สถานะของฟอร์ม/input ใน Shadcn |
|
||||
| Auth (การยืนยันตัวตน) | Guards, JWT | NextAuth / cookies | สถานะ UI ของ Auth (loading, signed in) |
|
||||
| Errors (ข้อผิดพลาด) | Global filters | Toasts / modals | Alerts / ข้อความ feedback |
|
||||
| Testing (การทดสอบ) | Jest (unit/e2e) | Vitest / Playwright | Visual regression |
|
||||
| Styles (สไตล์) | Scoped modules (ถ้าจำเป็น) | Tailwind / Shadcn | Tailwind utilities |
|
||||
| Accessibility (การเข้าถึง) | Guards + filters | ARIA attributes | Semantic HTML |
|
||||
|
||||
## 🗂️ **8. ข้อตกลงเฉพาะสำหรับ DMS (LCBP3-DMS)**
|
||||
|
||||
ส่วนนี้ขยายแนวทาง FullStackJS ทั่วไปสำหรับโปรเจกต์ **LCBP3-DMS** โดยมุ่งเน้นไปที่เวิร์กโฟลว์การอนุมัติเอกสาร (Correspondence, RFA, Drawing, Contract, Transmittal, Circulation)
|
||||
|
||||
### 🧾**8.1 มาตรฐาน AuditLog (AuditLog Standard)**
|
||||
|
||||
บันทึกการดำเนินการ CRUD และการจับคู่ทั้งหมดลงในตาราง audit_logs
|
||||
|
||||
| Field (ฟิลด์) | Type (จาก SQL) | Description (คำอธิบาย) |
|
||||
| :----------- | :------------- | :----------------------------------------------- |
|
||||
| audit_id | BIGINT | Primary Key |
|
||||
| user_id | INT | ผู้ใช้ที่ดำเนินการ (FK -> users) |
|
||||
| action | VARCHAR(100) | rfa.create, correspondence.update, login.success |
|
||||
| entity_type | VARCHAR(50) | ชื่อตาราง/โมดูล เช่น 'rfa', 'correspondence' |
|
||||
| entity_id | VARCHAR(50) | Primary ID ของระเบียนที่ได้รับผลกระทบ |
|
||||
| details_json | JSON | ข้อมูลบริบท (เช่น ฟิลด์ที่มีการเปลี่ยนแปลง) |
|
||||
| ip_address | VARCHAR(45) | IP address ของผู้ดำเนินการ |
|
||||
| user_agent | VARCHAR(255) | User Agent ของผู้ดำเนินการ |
|
||||
| created_at | TIMESTAMP | Timestamp (UTC) |
|
||||
|
||||
### 📂**8.2 การจัดการไฟล์ (File Handling)**
|
||||
|
||||
#### **8.2.1 มาตรฐานการอัปโหลดไฟล์ (File Upload Standard)**
|
||||
|
||||
* **Security-First Approach:** การอัปโหลดไฟล์ทั้งหมดจะถูกจัดการโดย FileStorageService ที่มี security measures ครบถ้วน
|
||||
* ไฟล์จะถูกเชื่อมโยงไปยัง Entity ที่ถูกต้องผ่าน **ตารางเชื่อม (Junction Tables)** เท่านั้น:
|
||||
* correspondence_attachments (เชื่อม Correspondence กับ Attachments)
|
||||
* circulation_attachments (เชื่อม Circulation กับ Attachments)
|
||||
* shop_drawing_revision_attachments (เชื่อม Shop Drawing Revision กับ Attachments)
|
||||
* contract_drawing_attachments (เชื่อม Contract Drawing กับ Attachments)
|
||||
* เส้นทางจัดเก็บไฟล์ (Upload path): อ้างอิงจาก Requirement 2.1 คือ /share/dms-data [cite: 2.1] โดย FileStorageService จะสร้างโฟลเดอร์ย่อยแบบรวมศูนย์ (เช่น /share/dms-data/uploads/{YYYY}/{MM}/[stored_filename])
|
||||
* ประเภทไฟล์ที่อนุญาต: pdf, dwg, docx, xlsx, zip (ผ่าน white-list validation)
|
||||
* ขนาดสูงสุด: **50 MB**
|
||||
* จัดเก็บนอก webroot
|
||||
* ให้บริการไฟล์ผ่าน endpoint ที่ปลอดภัย /files/:attachment_id/download
|
||||
|
||||
#### **8.2.2 Security Controls สำหรับ File Access:**
|
||||
|
||||
การเข้าถึงไฟล์ไม่ใช่การเข้าถึงโดยตรง endpoint /files/:attachment_id/download จะต้อง:
|
||||
|
||||
1. ค้นหาระเบียน attachment
|
||||
2. ตรวจสอบว่า attachment_id นี้ เชื่อมโยงกับ Entity ใด (เช่น correspondence, circulation, shop_drawing_revision, contract_drawing) ผ่านตารางเชื่อม
|
||||
3. ตรวจสอบว่าผู้ใช้มีสิทธิ์ (permission) ในการดู Entity ต้นทางนั้นๆ หรือไม่
|
||||
4. ตรวจสอบ download token expiration (24 ชั่วโมง)
|
||||
5. บันทึก audit log การดาวน์โหลด
|
||||
|
||||
### 🔟**8.3 การจัดการเลขที่เอกสาร (Document Numbering) [cite: 3.10]**
|
||||
|
||||
* **เป้าหมาย:** สร้างเลขที่เอกสาร (เช่น correspondence_number) โดยอัตโนมัติ ตามรูปแบบที่กำหนด
|
||||
* **ตรรกะการนับ:** การนับ Running number (SEQ) จะนับแยกตาม Key: **Project + Originator Organization + Document Type + Year**
|
||||
* **ตาราง SQL (Updated):**
|
||||
* `document_number_formats`: เก็บ Template String (เช่น `{CONTRACT}-{TYPE}-{DISCIPLINE}-{SEQ:4}`)
|
||||
* `document_number_counters`: **Primary Key เปลี่ยนเป็น Composite Key ใหม่:** `(project_id, originator_id, type_id, discipline_id, current_year)` เพื่อรองรับการรันเลขแยกตามสาขา
|
||||
* **การทำงาน:**
|
||||
* Service ต้องรองรับการ Resolve Token พิเศษ เช่น `{SUBTYPE_NUM}` ที่ต้องไป Join กับตาราง `correspondence_sub_types`
|
||||
* DocumentNumberingModule จะให้บริการ DocumentNumberingService
|
||||
* เมื่อ CorrespondenceModule ต้องการสร้างเอกสารใหม่, มันจะเรียก documentNumberingService.generateNextNumber(...)
|
||||
* Service นี้จะใช้ **Redis distributed locking** แทน stored procedure ซึ่งจะจัดการ Database Transaction และ Row Locking ภายใน Application Layer เพื่อรับประกันการป้องกัน Race Condition
|
||||
* มี retry mechanism และ fallback strategies
|
||||
|
||||
### 📊**8.4 การรายงานและการส่งออก (Reporting & Exports)**
|
||||
|
||||
#### **8.4.1 วิวสำหรับการรายงาน (Reporting Views) (จาก SQL)**
|
||||
|
||||
การรายงานควรสร้างขึ้นจาก Views ที่กำหนดไว้ล่วงหน้าในฐานข้อมูลเป็นหลัก:
|
||||
|
||||
* v_current_correspondences: สำหรับ revision ปัจจุบันทั้งหมดของเอกสารที่ไม่ใช่ RFA
|
||||
* v_current_rfas: สำหรับ revision ปัจจุบันทั้งหมดของ RFA และข้อมูล master
|
||||
* v_contract_parties_all: สำหรับการตรวจสอบความสัมพันธ์ของ project/contract/organization
|
||||
* v_user_tasks: สำหรับ Dashboard "งานของฉัน"
|
||||
* v_audit_log_details: สำหรับ Activity Feed
|
||||
|
||||
Views เหล่านี้ทำหน้าที่เป็นแหล่งข้อมูลหลักสำหรับการรายงานฝั่งเซิร์ฟเวอร์และการส่งออกข้อมูล
|
||||
|
||||
#### **8.4.2 กฎการส่งออก (Export Rules)**
|
||||
|
||||
* Export formats: CSV, Excel, PDF.
|
||||
* จัดเตรียมมุมมองสำหรับพิมพ์ (Print view).
|
||||
* รวมลิงก์ไปยังต้นทาง (เช่น /rfas/:id).
|
||||
|
||||
## 🧮 **9. ฟรอนต์เอนด์: รูปแบบ DataTable และฟอร์ม (Frontend: DataTable & Form Patterns)**
|
||||
|
||||
### **9.1 DataTable (Server‑Side)**
|
||||
|
||||
* Endpoint: /api/{module}?page=1&pageSize=20&sort=...&filter=...
|
||||
* ต้องรองรับ: การแบ่งหน้า (pagination), การเรียงลำดับ (sorting), การค้นหา (search), การกรอง (filters)
|
||||
* แสดง revision ล่าสุดแบบ inline เสมอ (สำหรับ RFA/Drawing)
|
||||
|
||||
### **9.2 มาตรฐานฟอร์ม (Form Standards)**
|
||||
|
||||
* ต้องมีการใช้งาน Dropdowns แบบขึ้นต่อกัน (Dependent dropdowns) (ตามที่สคีมารองรับ):
|
||||
* Project → Contract Drawing Volumes
|
||||
* Contract Drawing Category → Sub-Category
|
||||
* RFA (ประเภท Shop Drawing) → Shop Drawing Revisions ที่เชื่อมโยงได้
|
||||
* **File Upload Security:** ต้องรองรับ **Multi-file upload (Drag-and-Drop)** [cite: 5.7] พร้อม virus scanning feedback
|
||||
* **File Type Indicators:** UI ต้องอนุญาตให้ผู้ใช้กำหนดว่าไฟล์ใดเป็น **"เอกสารหลัก"** หรือ "เอกสารแนบประกอบ" [cite: 5.7] พร้อมแสดง file type icons
|
||||
* **Security Feedback:** แสดง security warnings สำหรับ file types ที่เสี่ยงหรือ files ที่ fail virus scan
|
||||
* ส่ง (Submit) ผ่าน API พร้อม feedback แบบ toast
|
||||
|
||||
### **9.3 ข้อกำหนด Component เฉพาะ (Specific UI Requirements)**
|
||||
|
||||
* **Dashboard - My Tasks:** ต้องพัฒนา Component ตาราง "งานของฉัน" (My Tasks)ซึ่งดึงข้อมูลงานที่ผู้ใช้ล็อกอินอยู่ต้องรับผิดชอบ (Main/Action) จาก v_user_tasks [cite: 5.3]
|
||||
* **Workflow Visualization:** ต้องพัฒนา Component สำหรับแสดงผล Workflow (โดยเฉพาะ RFA)ที่แสดงขั้นตอนทั้งหมดเป็นลำดับ โดยขั้นตอนปัจจุบัน (active) เท่านั้นที่ดำเนินการได้ และขั้นตอนอื่นเป็น disabled [cite: 5.6] ต้องมีตรรกะสำหรับ Admin ในการ override หรือย้อนกลับขั้นตอนได้ [cite: 5.6]
|
||||
* **Admin Panel:** ต้องมีหน้า UI สำหรับ Superadmin/Admin เพื่อจัดการข้อมูลหลัก (Master Data [cite: 4.5]), การเริ่มต้นใช้งาน (Onboarding [cite: 4.6]), และ **รูปแบบเลขที่เอกสาร (Numbering Formats [cite: 3.10])**
|
||||
* **Security Dashboard:** แสดง security metrics และ audit logs สำหรับ administrators
|
||||
|
||||
## 🧭 **10. แดชบอร์ดและฟีดกิจกรรม (Dashboard & Activity Feed)**
|
||||
|
||||
### **10.1 การ์ดบนแดชบอร์ด (Dashboard Cards)**
|
||||
|
||||
* แสดง Correspondences, RFAs, Circulations, Shop Drawing Revision ล่าสุด
|
||||
* รวมสรุป KPI (เช่น "RFAs ที่รอการอนุมัติ", "Shop Drawing ที่รอการอนุมัติ") [cite: 5.3]
|
||||
* รวมลิงก์ด่วนไปยังโมดูลต่างๆ
|
||||
* **Security Metrics:** แสดงจำนวน files scanned, security incidents, failed login attempts
|
||||
|
||||
### **10.2 ฟีดกิจกรรม (Activity Feed)**
|
||||
|
||||
* แสดงรายการ v_audit_log_details ล่าสุด (10 รายการ) ที่เกี่ยวข้องกับผู้ใช้
|
||||
* รวม security-related activities (failed logins, permission changes)
|
||||
|
||||
```typescript
|
||||
// ตัวอย่าง API response
|
||||
[
|
||||
{ user: 'editor01', action: 'Updated RFA (LCBP3-RFA-001)', time: '2025-11-04T09:30Z' },
|
||||
{ user: 'system', action: 'Virus scan completed - 0 threats found', time: '2025-11-04T09:25Z' }
|
||||
]
|
||||
```
|
||||
|
||||
## 🛡️ **11. ข้อกำหนดที่ไม่ใช่ฟังก์ชันการทำงาน (Non-Functional Requirements)**
|
||||
|
||||
ส่วนนี้สรุปข้อกำหนด Non-Functional จาก requirements.md เพื่อให้ทีมพัฒนาทาน
|
||||
|
||||
* **Audit Log [cite: 6.1]:** ทุกการกระทำที่สำคัญ (C/U/D) ต้องถูกบันทึกใน audit_logs
|
||||
* **Performance [cite: 6.4]:** ต้องใช้ Caching สำหรับข้อมูลที่เรียกบ่อย และใช้ Pagination
|
||||
* **Security [cite: 6.5]:** ต้องมี Rate Limiting และจัดการ Secret ผ่าน docker-compose.yml (ไม่ใช่ .env)
|
||||
* **File Security [cite: 3.9.6]:** ต้องมี virus scanning, file type validation, access controls
|
||||
* **Resilience [cite: 6.5.3]:** ต้องมี circuit breaker, retry mechanisms, graceful degradation
|
||||
* **Backup & Recovery [cite: 6.6]:** ต้องมีแผนสำรองข้อมูลทั้ง Database (MariaDB) และ File Storage (/share/dms-data) อย่างน้อยวันละ 1 ครั้ง
|
||||
* **Notification Strategy [cite: 6.7]:** ระบบแจ้งเตือน (Email/Line) ต้องถูก Trigger เมื่อมีเอกสารใหม่ส่งถึง, มีการมอบหมายงานใหม่ (Circulation), หรือ (ทางเลือก) เมื่องานเสร็จ/ใกล้ถึงกำหนด
|
||||
* **Monitoring [cite: 6.8]:** ต้องมี health checks, metrics collection, alerting
|
||||
|
||||
## ✅ **12. มาตรฐานที่นำไปใช้แล้ว (จาก SQL v1.4.0) (Implemented Standards (from SQL v1.4.0))**
|
||||
|
||||
ส่วนนี้ยืนยันว่าแนวทางปฏิบัติที่ดีที่สุดต่อไปนี้เป็นส่วนหนึ่งของการออกแบบฐานข้อมูลอยู่แล้ว และควรถูกนำไปใช้ประโยชน์ ไม่ใช่สร้างขึ้นใหม่
|
||||
|
||||
* ✅ **Soft Delete:** นำไปใช้แล้วผ่านคอลัมน์ deleted_at ในตารางสำคัญ (เช่น correspondences, rfas, project_parties) ตรรกะการดึงข้อมูลต้องกรอง deleted_at IS NULL
|
||||
* ✅ **Database Indexes:** สคีมาได้มีการทำ index ไว้อย่างหนักหน่วงบน foreign keys และคอลัมน์ที่ใช้ค้นหาบ่อย (เช่น idx_rr_rfa, idx_cor_project, idx_cr_is_current) เพื่อประสิทธิภาพ
|
||||
* ✅ **โครงสร้าง RBAC:** มีระบบ users, roles, permissions, user_roles, และ user_project_roles ที่ครอบคลุมอยู่แล้ว
|
||||
* ✅ **Data Seeding:** ข้อมูล Master (roles, permissions, organization_roles, initial users, project parties) ถูกรวมอยู่ในสคริปต์สคีมาแล้ว
|
||||
* ✅ **Application-level Locking:** ใช้ Redis distributed lock แทน stored procedure
|
||||
* ✅ **File Security:** Virus scanning, file type validation, access control
|
||||
* ✅ **Resilience Patterns:** Circuit breaker, retry, fallback mechanisms
|
||||
* ✅ **Security Measures:** Input validation, rate limiting, security headers
|
||||
* ✅ **Monitoring:** Health checks, metrics collection, distributed tracing
|
||||
|
||||
## 🧩 **13. การปรับปรุงที่แนะนำ (สำหรับอนาคต) (Recommended Enhancements (Future))**
|
||||
|
||||
* ✅ สร้าง Background job (โดยใช้ **n8n** เพื่อเชื่อมต่อกับ **Line** [cite: 2.7] และ/หรือใช้สำหรับการแจ้งเตือน RFA ที่ใกล้ถึงกำหนด due_date [cite: 6.7])
|
||||
* ✅ เพิ่ม job ล้างข้อมูลเป็นระยะสำหรับ attachments ที่ไม่ถูกเชื่อมโยงกับ Entity ใดๆ เลย (ไฟล์กำพร้า)
|
||||
* 🔄 **AI-Powered Document Classification:** ใช้ machine learning สำหรับ automatic document categorization
|
||||
* 🔄 **Advanced Analytics:** Predictive analytics สำหรับ workflow optimization
|
||||
* 🔄 **Mobile App:** Native mobile application สำหรับ field workers
|
||||
* 🔄 **Blockchain Integration:** สำหรับ document integrity verification ที่ต้องการความปลอดภัยสูงสุด
|
||||
|
||||
## ✅ **14. Summary Checklist for Developers**
|
||||
|
||||
ก่อนส่ง PR (Pull Request) นักพัฒนาต้องตรวจสอบหัวข้อต่อไปนี้:
|
||||
|
||||
* [ ] **Security:** ไม่มี Secrets ใน Code, ใช้ `docker-compose.override.yml` แล้ว
|
||||
* [ ] **Concurrency:** ใช้ Optimistic Lock ใน Entity ที่เสี่ยง Race Condition แล้ว
|
||||
* [ ] **Idempotency:** API รองรับ Idempotency Key แล้ว
|
||||
* [ ] **File Upload:** ใช้ Flow Two-Phase (Temp -> Perm) แล้ว
|
||||
* [ ] **Mobile:** หน้าจอแสดงผลแบบ Card View บนมือถือได้ถูกต้อง
|
||||
* [ ] **Performance:** สร้าง Index สำหรับ JSON Virtual Columns แล้ว (ถ้ามี)
|
||||
|
||||
---
|
||||
|
||||
## 📋 **15. Summary of Key Changes from Previous Version**
|
||||
|
||||
### **Security Enhancements:**
|
||||
|
||||
1. **File Upload Security** - Virus scanning, file type validation, access controls
|
||||
2. **Input Validation** - OWASP Top 10 protection, XSS/CSRF prevention
|
||||
3. **Rate Limiting** - Comprehensive rate limiting strategy
|
||||
4. **Secrets Management** - Secure handling of sensitive configuration
|
||||
|
||||
### **Architecture Improvements:**
|
||||
|
||||
1. **Document Numbering** - Changed from Stored Procedure to Application-level Locking
|
||||
2. **Resilience Patterns** - Circuit breaker, retry mechanisms, fallback strategies
|
||||
3. **Monitoring & Observability** - Health checks, metrics, distributed tracing
|
||||
4. **Caching Strategy** - Comprehensive caching with proper invalidation
|
||||
|
||||
### **Performance Targets :**
|
||||
|
||||
1. **API Response Time** - < 200ms (90th percentile)
|
||||
2. **Search Performance** - < 500ms
|
||||
3. **File Upload** - < 30 seconds for 50MB files
|
||||
4. **Cache Hit Ratio** - > 80%
|
||||
|
||||
### **Operational Excellence:**
|
||||
|
||||
1. **Disaster Recovery** - RTO < 4 hours, RPO < 1 hour
|
||||
2. **Backup Procedures** - Comprehensive backup and restoration
|
||||
3. **Security Testing** - Penetration testing and security audits
|
||||
4. **Performance Testing** - Load testing with realistic workloads
|
||||
|
||||
เอกสารนี้สะท้อนถึงความมุ่งมั่นในการสร้างระบบที่มีความปลอดภัย, มีความทนทาน, และมีประสิทธิภาพสูง พร้อมรองรับการเติบโตในอนาคตและความต้องการทางธุรกิจที่เปลี่ยนแปลงไป
|
||||
|
||||
**หมายเหตุ:** แนวทางนี้จะถูกทบทวนและปรับปรุงเป็นระยะตาม feedback จากทีมพัฒนาและความต้องการทางธุรกิจที่เปลี่ยนแปลงไป
|
||||
|
||||
## **Document Control:**
|
||||
|
||||
* **Document:** FullStackJS v1.4.4
|
||||
* **Version:** 1.4
|
||||
* **Date:** 2025-11-26
|
||||
* **Author:** NAP LCBP3-DMS & Gemini
|
||||
* **Status:** FINAL-Rev.04
|
||||
* **Classification:** Internal Technical Documentation
|
||||
* **Approved By:** Nattanin
|
||||
|
||||
---
|
||||
|
||||
`End of FullStackJS Guidelines v1.4.4`
|
||||
@@ -0,0 +1,565 @@
|
||||
# 📋 **แผนการพัฒนา Backend (NestJS) - LCBP3-DMS v1.4.4 (ฉบับปรับปรุง)**
|
||||
|
||||
**สถานะ:** FINAL GUIDELINE Rev.04
|
||||
**วันที่:** 2025-11-26
|
||||
**อ้างอิง:** Requirements v1.4.3 & FullStackJS Guidelines v1.4.3
|
||||
**Classification:** Internal Technical Documentation
|
||||
|
||||
-----
|
||||
|
||||
## 🎯 **ภาพรวมโครงการ**
|
||||
|
||||
พัฒนา Backend สำหรับระบบบริหารจัดการเอกสารโครงการ (Document Management System) ที่มีความปลอดภัยสูง รองรับการทำงานพร้อมกัน (Concurrency) ได้อย่างถูกต้องแม่นยำ มีสถาปัตยกรรมที่ยืดหยุ่นต่อการขยายตัว และรองรับการจัดการเอกสารที่ซับซ้อน มีระบบ Workflow การอนุมัติ และการควบคุมสิทธิ์แบบ RBAC 4 ระดับ พร้อมมาตรการความปลอดภัยที่ทันสมัย
|
||||
|
||||
-----
|
||||
|
||||
## 📐 **สถาปัตยกรรมระบบ**
|
||||
|
||||
### **Technology Stack (Updated)**
|
||||
|
||||
- **Framework:** NestJS (TypeScript, ESM)
|
||||
- **Database:** MariaDB 10.11 (ใช้ Virtual Columns)
|
||||
- **ORM:** TypeORM (ใช้ Optimistic Locking)
|
||||
- **Authentication:** JWT + Passport
|
||||
- **Authorization:** CASL (RBAC 4-level)
|
||||
- **File Upload:** Multer + Virus Scanning (ClamAV) + Two-Phase Storage
|
||||
- **Search:** Elasticsearch
|
||||
- **Notification:** Nodemailer + n8n (Line Integration) + BullMQ Queue
|
||||
- **Caching/Locking:** Redis (Redlock) สำหรับ Distributed Locking
|
||||
- **Queue:** BullMQ (Redis) สำหรับ Notification Batching และ Async Jobs
|
||||
- **Resilience:** Circuit Breaker, Retry Patterns
|
||||
- **Security:** Helmet, CSRF Protection, Rate Limiting, Idempotency
|
||||
- **Monitoring:** Winston, Health Checks, Metrics
|
||||
- **Scheduling:** @nestjs/schedule (Cron Jobs)
|
||||
- **Documentation:** Swagger
|
||||
- **Validation:** Zod / Class-validator
|
||||
|
||||
### **โครงสร้างโมดูล (Domain-Driven)**
|
||||
|
||||
```tree
|
||||
src/
|
||||
├── common/ # Shared Module
|
||||
│ ├── auth/ # JWT, Guards, RBAC
|
||||
│ ├── config/ # Configuration Management
|
||||
│ ├── decorators/ # @RequirePermission, @RateLimit
|
||||
│ ├── entities/ # Base Entities
|
||||
│ ├── exceptions/ # Global Filters
|
||||
│ ├── file-storage/ # FileStorageService (Virus Scanning + Two-Phase)
|
||||
│ ├── guards/ # RBAC Guard, RateLimitGuard
|
||||
│ ├── interceptors/ # Audit, Transform, Performance, Idempotency
|
||||
│ ├── resilience/ # Circuit Breaker, Retry Patterns
|
||||
│ ├── security/ # Input Validation, XSS Protection
|
||||
│ ├── idempotency/ # [New] Idempotency Logic
|
||||
│ └── maintenance/ # [New] Maintenance Mode Guard
|
||||
├── modules/
|
||||
│ ├── user/ # Users, Roles, Permissions
|
||||
│ ├── project/ # Projects, Contracts, Organizations
|
||||
│ ├── master/ # Master Data Management
|
||||
│ ├── correspondence/ # Correspondence Management
|
||||
│ ├── rfa/ # RFA & Workflows
|
||||
│ ├── drawing/ # Shop/Contract Drawings
|
||||
│ ├── circulation/ # Internal Circulation
|
||||
│ ├── transmittal/ # Transmittals
|
||||
│ ├── search/ # Elasticsearch
|
||||
│ ├── monitoring/ # Metrics, Health Checks
|
||||
│ ├── workflow-engine/ # [New] Unified Workflow Logic
|
||||
│ ├── document-numbering/ # [Update] Double-Locking Logic
|
||||
│ ├── notification/ # [Update] Queue & Digest
|
||||
│ └── file-storage/ # [Update] Two-Phase Commit
|
||||
└── database/ # Migrations & Seeds
|
||||
```
|
||||
|
||||
-----
|
||||
|
||||
## 🗓️ **แผนการพัฒนาแบบ Phase-Based**
|
||||
|
||||
- *(Dependency Diagram ถูกละไว้เพื่อประหยัดพื้นที่ เนื่องจากมีการอ้างอิงจากแผนเดิม)*
|
||||
|
||||
## **Phase 0: Infrastructure & Configuration (สัปดาห์ที่ 1)**
|
||||
|
||||
**Milestone:** โครงสร้างพื้นฐานพร้อม รองรับ Secrets ที่ปลอดภัย และ Redis พร้อมใช้งาน
|
||||
|
||||
### **Phase 0: Tasks**
|
||||
|
||||
- **[ ] T0.1 Secure Configuration Setup**
|
||||
|
||||
- [ ] ปรับปรุง `ConfigModule` ให้รองรับการอ่านค่าจาก Environment Variables
|
||||
- [ ] สร้าง Template `docker-compose.override.yml.example` สำหรับ Dev
|
||||
- [ ] Validate Config ด้วย Joi/Zod ตอน Start App (Throw error ถ้าขาด Secrets)
|
||||
- [ ] **Security:** Setup network segmentation และ firewall rules
|
||||
- [ ] **Deliverable:** Configuration Management พร้อมใช้งานอย่างปลอดภัย
|
||||
- [ ] **Dependencies:** None (Task เริ่มต้น)
|
||||
|
||||
- **[ ] T0.2 Redis & Queue Infrastructure**
|
||||
|
||||
- [ ] Setup Redis Container
|
||||
- [ ] Setup BullMQ Module ใน NestJS สำหรับจัดการ Background Jobs
|
||||
- [ ] Setup Redis Client สำหรับ Distributed Lock (Redlock)
|
||||
- [ ] **Security:** Setup Redis authentication และ encryption
|
||||
- [ ] **Deliverable:** Redis และ Queue System พร้อมใช้งาน
|
||||
- [ ] **Dependencies:** T0.1
|
||||
|
||||
- **[ ] T0.3 Setup Database Connection**
|
||||
|
||||
- [ ] Import SQL Schema v1.4.2 เข้า MariaDB
|
||||
- [ ] Run Seed Data (organizations, users, roles, permissions)
|
||||
- [ ] Configure TypeORM ใน AppModule
|
||||
- [ ] **Security:** Setup database connection encryption
|
||||
- [ ] ทดสอบ Connection
|
||||
- [ ] **Deliverable:** Database พร้อมใช้งาน, มี Seed Data
|
||||
- [ ] **Dependencies:** T0.1
|
||||
|
||||
- **[ ] T0.4 Setup Git Repository**
|
||||
|
||||
- [ ] สร้าง Repository ใน Gitea (git.np-dms.work)
|
||||
- [ ] Setup .gitignore, README.md, SECURITY.md
|
||||
- [ ] Commit Initial Project
|
||||
- [ ] **Deliverable:** Code อยู่ใน Version Control
|
||||
- [ ] **Dependencies:** T0.1, T0.2, T0.3
|
||||
|
||||
-----
|
||||
|
||||
## **Phase 1: Core Foundation & Security (สัปดาห์ที่ 2-3)**
|
||||
|
||||
**Milestone:** ระบบ Authentication, Authorization, Idempotency พื้นฐาน และ Security Baseline
|
||||
|
||||
### **Phase 1: Tasks**
|
||||
|
||||
- **[ ] T1.1 CommonModule - Base Infrastructure**
|
||||
|
||||
- [ ] สร้าง Base Entity (id, created_at, updated_at, deleted_at)
|
||||
- [ ] สร้าง Global Exception Filter (ไม่เปิดเผย sensitive information)
|
||||
- [ ] สร้าง Response Transform Interceptor
|
||||
- [ ] สร้าง Audit Log Interceptor
|
||||
- [ ] **[New] Idempotency Interceptor:** ตรวจสอบ Header `Idempotency-Key` และ Cache Response เดิมใน Redis
|
||||
- [ ] **[New] Maintenance Mode Middleware:** ตรวจสอบ Flag ใน **Redis Key** เพื่อ Block API ระหว่างปรับปรุงระบบ **(Admin ใช้ Redis/Admin UI ในการ Toggle สถานะ)**
|
||||
- [ ] สร้าง RequestContextService - สำหรับเก็บข้อมูลระหว่าง Request
|
||||
- [ ] สร้าง ConfigService - Centralized configuration management
|
||||
- [ ] สร้าง CryptoService - สำหรับ encryption/decryption
|
||||
- [ ] **Security:** Implement input validation pipeline
|
||||
- [ ] **Deliverable:** Common Services พร้อมใช้ รวมถึง Idempotency และ Maintenance Mode
|
||||
- [ ] **Dependencies:** T0.2, T0.3
|
||||
|
||||
- **[ ] T1.2 AuthModule - JWT Authentication**
|
||||
|
||||
- [ ] สร้าง Entity: User
|
||||
- [ ] สร้าง AuthService:
|
||||
- [ ] login(username, password) → JWT Token
|
||||
- [ ] validateUser(username, password) → User | null
|
||||
- [ ] Password Hashing (bcrypt) + salt
|
||||
- [ ] สร้าง JWT Strategy (Passport)
|
||||
- [ ] สร้าง JwtAuthGuard
|
||||
- [ ] สร้าง Controllers:
|
||||
- [ ] POST /auth/login → { access_token, refresh_token }
|
||||
- [ ] POST /auth/register → Create User (Admin only)
|
||||
- [ ] POST /auth/refresh → Refresh token
|
||||
- [ ] POST /auth/logout → Revoke token
|
||||
- [ ] GET /auth/profile (Protected)
|
||||
- [ ] **Security:** Implement rate limiting สำหรับ authentication endpoints
|
||||
- [ ] **Deliverable:** ล็อกอิน/ล็อกเอาต์ทำงานได้อย่างปลอดภัย
|
||||
- [ ] **Dependencies:** T1.1, T0.3
|
||||
|
||||
- **[ ] T1.3 UserModule - User Management**
|
||||
|
||||
- [ ] สร้าง Entities: User, Role, Permission, UserRole, UserAssignment, **UserPreference**
|
||||
- [ ] สร้าง UserService CRUD (พร้อม soft delete)
|
||||
- [ ] สร้าง RoleService CRUD
|
||||
- [ ] สร้าง PermissionService (Read-Only, จาก Seed)
|
||||
- [ ] สร้าง UserAssignmentService - สำหรับจัดการ user assignments ตาม scope
|
||||
- [ ] สร้าง **UserPreferenceService** - สำหรับจัดการการตั้งค่า Notification และ UI
|
||||
- [ ] สร้าง Controllers:
|
||||
- [ ] GET /users → List Users (Paginated)
|
||||
- [ ] GET /users/:id → User Detail
|
||||
- [ ] POST /users → Create User (ต้องบังคับเปลี่ยน password ครั้งแรก)
|
||||
- [ ] PUT /users/:id → Update User
|
||||
- [ ] DELETE /users/:id → Soft Delete
|
||||
- [ ] GET /roles → List Roles
|
||||
- [ ] POST /roles → Create Role (Admin)
|
||||
- [ ] PUT /roles/:id/permissions → Assign Permissions
|
||||
- [ ] **Security:** Implement permission checks สำหรับ user management
|
||||
- [ ] **Deliverable:** จัดการผู้ใช้, Role, และ Preferences ได้
|
||||
- [ ] **Dependencies:** T1.1, T1.2
|
||||
|
||||
- **[ ] T1.4 RBAC Guard - 4-Level Authorization**
|
||||
|
||||
- [ ] สร้าง @RequirePermission() Decorator
|
||||
- [ ] สร้าง RbacGuard ที่ตรวจสอบ 4 ระดับ:
|
||||
- [ ] Global Permissions
|
||||
- [ ] Organization Permissions
|
||||
- [ ] Project Permissions
|
||||
- [ ] Contract Permissions
|
||||
- [ ] Permission Hierarchy Logic
|
||||
- [ ] Integration กับ CASL
|
||||
- [ ] **Security:** Implement audit logging สำหรับ permission checks
|
||||
- [ ] **Deliverable:** ระบบสิทธิ์ทำงานได้ทั้ง 4 ระดับ
|
||||
- [ ] **Dependencies:** T1.1, T1.3
|
||||
|
||||
- **[ ] T1.5 ProjectModule - Base Structures**
|
||||
|
||||
- [ ] สร้าง Entities:
|
||||
- [ ] Organization
|
||||
- [ ] Project
|
||||
- [ ] Contract
|
||||
- [ ] ProjectOrganization (Junction)
|
||||
- [ ] ContractOrganization (Junction)
|
||||
- [ ] สร้าง Services & Controllers:
|
||||
- [ ] GET /organizations → List
|
||||
- [ ] POST /projects → Create (Superadmin)
|
||||
- [ ] GET /projects/:id/contracts → List Contracts
|
||||
- [ ] POST /projects/:id/contracts → Create Contract
|
||||
- [ ] **Security:** Implement data isolation ระหว่าง organizations
|
||||
- [ ] **Deliverable:** จัดการโครงสร้างโปรเจกต์ได้
|
||||
- [ ] **Dependencies:** T1.1, T1.2, T0.3
|
||||
|
||||
-----
|
||||
|
||||
## **Phase 2: High-Integrity Data & File Management (สัปดาห์ที่ 4)**
|
||||
|
||||
**Milestone:** Master Data, ระบบจัดการไฟล์แบบ Transactional, Document Numbering ที่ไม่มี Race Condition, JSON details system พร้อมใช้งาน
|
||||
|
||||
### **Phase 2: Tasks**
|
||||
|
||||
- **[ ] T2.1 Virtual Columns for JSON**
|
||||
|
||||
- [ ] ออกแบบ Migration Script สำหรับตารางที่มี JSON Details
|
||||
- [ ] เพิ่ม **Generated Columns (Virtual)** สำหรับฟิลด์ที่ใช้ Search บ่อยๆ (เช่น `project_id`, `type`) พร้อม Index
|
||||
- [ ] **Security:** Implement admin-only access สำหรับ master data
|
||||
- [ ] **Deliverable:** JSON Data Search Performance ดีขึ้น
|
||||
- [ ] **Dependencies:** T0.3, T1.1, T1.5
|
||||
|
||||
- **[ ] T2.2 FileStorageService - Two-Phase Storage**
|
||||
|
||||
- [ ] สร้าง Attachment Entity
|
||||
- [ ] สร้าง FileStorageService:
|
||||
- [ ] **Phase 1 (Upload):** API รับไฟล์ → Scan Virus → Save ลง `temp/` → Return `temp_id`
|
||||
- [ ] **Phase 2 (Commit):** Method `commitFiles(tempIds[])` → ย้ายจาก `temp/` ไป `permanent/{YYYY}/{MM}/` → Update DB
|
||||
- [ ] File type validation (white-list: PDF, DWG, DOCX, XLSX, PPTX, ZIP)
|
||||
- [ ] File size check (max 50MB)
|
||||
- [ ] Generate checksum (SHA-256)
|
||||
- [ ] **Cleanup Job:** สร้าง Cron Job ลบไฟล์ใน `temp/` ที่ค้างเกิน 24 ชม. **โดยตรวจสอบจากคอลัมน์ `expires_at` ในตาราง `attachments`**
|
||||
- [ ] สร้าง Controller:
|
||||
- [ ] POST /files/upload → { temp_id } (Protected)
|
||||
- [ ] POST /files/commit → { attachment_id, url } (Protected)
|
||||
- [ ] GET /files/:id/download → File Stream (Protected + Expiration)
|
||||
- [ ] **Security:** Access Control - ตรวจสอบสิทธิ์ผ่าน Junction Table
|
||||
- [ ] **Deliverable:** อัปโหลด/ดาวน์โหลดไฟล์ได้อย่างปลอดภัย แบบ Transactional
|
||||
- [ ] **Dependencies:** T1.1, T1.4
|
||||
|
||||
- **[ ] T2.3 DocumentNumberingModule - Double-Lock Mechanism**
|
||||
|
||||
- [ ] สร้าง Entities:
|
||||
- [ ] DocumentNumberFormat
|
||||
- [ ] DocumentNumberCounter
|
||||
- [ ] สร้าง DocumentNumberingService:
|
||||
- [ ] generateNextNumber(projectId, orgId, typeId, year) → string
|
||||
- [ ] ใช้ **Double-Lock Mechanism**:
|
||||
1. Acquire **Redis Lock** (Key: `doc_num:{project}:{type}`)
|
||||
2. Read DB & Calculate Next Number
|
||||
3. Update DB with **Optimistic Lock** Check (ใช้ `@VersionColumn()`)
|
||||
4. Release Redis Lock
|
||||
5. Retry on Failure ด้วย exponential backoff
|
||||
- [ ] Fallback mechanism เมื่อการขอเลขล้มเหลว
|
||||
- [ ] Format ตาม Template: {ORG_CODE}-{TYPE_CODE}-{YEAR_SHORT}-{SEQ:4}
|
||||
- **ไม่มี Controller** (Internal Service เท่านั้น)
|
||||
- [ ] **Security:** Implement audit log ทุกครั้งที่มีการ generate เลขที่
|
||||
- [ ] **Deliverable:** Service สร้างเลขที่เอกสารได้ถูกต้องและปลอดภัย ไม่มี Race Condition
|
||||
- [ ] **Dependencies:** T1.1, T0.3
|
||||
|
||||
* **[ ] T2.3 DocumentNumberingModule - Token-Based & Double-Lock** (Updated)
|
||||
* [ ] Update Entity: `DocumentNumberCounter` (Add `discipline_id` to PK)
|
||||
* [ ] Implement Token Parser & Replacer Logic (`{DISCIPLINE}`, `{SUBTYPE_NUM}`)
|
||||
* [ ] Update `generateNextNumber` to handle optional keys (Discipline/SubType)
|
||||
* [ ] **Deliverable:** Flexible Numbering System
|
||||
|
||||
- **[ ] T2.4 SecurityModule - Enhanced Security**
|
||||
|
||||
- [ ] สร้าง Input Validation Service:
|
||||
- [ ] XSS Prevention
|
||||
- [ ] SQL Injection Prevention
|
||||
- [ ] CSRF Protection
|
||||
- [ ] สร้าง RateLimitGuard:
|
||||
- [ ] Implement rate limiting ตาม strategy (anonymous: 100/hr, authenticated: 500-5000/hr)
|
||||
- [ ] Different limits สำหรับ endpoints ต่างๆ
|
||||
- [ ] สร้าง Security Headers Middleware
|
||||
- [ ] **Security:** Implement content security policy (CSP)
|
||||
- [ ] **Deliverable:** Security layers ทำงานได้
|
||||
- [ ] **Dependencies:** T1.1
|
||||
|
||||
- **[ ] T2.5 JSON Details & Schema Management**
|
||||
|
||||
- [ ] T2.5.1 JsonSchemaModule - Schema Management: สร้าง Service สำหรับ Validate, get, register JSON schemas
|
||||
- [ ] T2.5.2 DetailsService - Data Processing: สร้าง Service สำหรับ sanitize, transform, compress/decompress JSON
|
||||
- [ ] T2.5.3 JSON Security & Validation: Implement security checks และ validation rules
|
||||
- [ ] **Deliverable:** JSON schema system ทำงานได้
|
||||
- [ ] **Dependencies:** T1.1
|
||||
|
||||
* **[ ] T2.6 MasterModule - Advanced Data (Req 6B)** (New)
|
||||
* [ ] Update Entities: `Discipline`, `CorrespondenceSubType`
|
||||
* [ ] Create Services/Controllers for CRUD Operations (Admin Panel Support)
|
||||
* [ ] Implement Seeding Logic for initial 6B data
|
||||
* [ ] **Deliverable:** API for managing Disciplines and Sub-types
|
||||
* [ ] **Dependencies:** T1.1, T0.3
|
||||
|
||||
-----
|
||||
|
||||
## **Phase 3: Unified Workflow Engine (สัปดาห์ที่ 5-6)**
|
||||
|
||||
**Milestone:** ระบบ Workflow กลางที่รองรับทั้ง Routing ปกติ และ RFA
|
||||
|
||||
### **Phase 3: Tasks**
|
||||
|
||||
- **[ ] T3.1 WorkflowEngineModule (New)**
|
||||
|
||||
- [ ] ออกแบบ Generic Schema สำหรับ Workflow State Machine
|
||||
- [ ] Implement Service: `initializeWorkflow()`, `processAction()`, `getNextStep()`
|
||||
- [ ] รองรับ Logic การ "ข้ามขั้นตอน" และ "ส่งกลับ" ภายใน Engine เดียว
|
||||
- [ ] **Security:** Implement audit logging สำหรับ workflow actions
|
||||
- [ ] **Deliverable:** Unified Workflow Engine พร้อมใช้งาน
|
||||
- [ ] **Dependencies:** T1.1
|
||||
|
||||
- **[ ] T3.2 CorrespondenceModule - Basic CRUD**
|
||||
|
||||
- [ ] สร้าง Entities (Correspondence, Revision, Recipient, Tag, Reference, Attachment)
|
||||
- [ ] สร้าง CorrespondenceService (Create with Document Numbering, Update with new Revision, Soft Delete)
|
||||
- [ ] สร้าง Controllers (POST/GET/PUT/DELETE /correspondences)
|
||||
- [ ] [New] Implement Impersonation Logic: ตรวจสอบ originatorId ใน DTO หากมีการส่งมา ต้องเช็คว่า User ปัจจุบันมีสิทธิ์กระทำการแทนหรือไม่ (Superadmin)
|
||||
- [ ] **Security:** Implement permission checks สำหรับ document access
|
||||
- [ ] **Deliverable:** สร้าง/แก้ไข/ดูเอกสารได้
|
||||
- [ ] **Dependencies:** T1.1, T1.2, T1.3, T1.4, T1.5, T2.3, T2.2, T2.5
|
||||
|
||||
- **[ ] T3.3 CorrespondenceModule - Advanced Features**
|
||||
|
||||
- [ ] Implement Status Transitions (DRAFT → SUBMITTED)
|
||||
- [ ] Implement References (Link Documents)
|
||||
- [ ] Implement Search (Basic)
|
||||
- [ ] **Security:** Implement state transition validation
|
||||
- [ ] **Deliverable:** Workflow พื้นฐานทำงานได้
|
||||
- [ ] **Dependencies:** T3.2
|
||||
|
||||
- **[ ] T3.4 Correspondence Integration with Workflow**
|
||||
|
||||
- [ ] เชื่อมต่อ `CorrespondenceService` เข้ากับ `WorkflowEngineModule`
|
||||
- [ ] ย้าย Logic การ Routing เดิมมาใช้ Engine ใหม่
|
||||
- [ ] สร้าง API endpoints สำหรับ Frontend (Templates, Pending Tasks, Bulk Action)
|
||||
- [ ] **Security:** Implement permission checks สำหรับ workflow operations
|
||||
- [ ] **Deliverable:** ระบบส่งต่อเอกสารทำงานได้สมบูรณ์ด้วย Unified Engine
|
||||
- [ ] **Dependencies:** T3.1, T3.2
|
||||
|
||||
-----
|
||||
|
||||
## **Phase 4: Drawing & Advanced Workflows (สัปดาห์ที่ 7-8)**
|
||||
|
||||
**Milestone:** การจัดการแบบและ RFA โดยใช้ Unified Engine
|
||||
|
||||
### **Phase 4: Tasks**
|
||||
|
||||
- **[ ] T4.1 DrawingModule - Contract Drawings**
|
||||
|
||||
- [ ] สร้าง Entities (ContractDrawing, Volume, Category, SubCategory, Attachment)
|
||||
- [ ] สร้าง ContractDrawingService CRUD
|
||||
- [ ] สร้าง Controllers (GET/POST /drawings/contract)
|
||||
- [ ] **Security:** Implement access control สำหรับ contract drawings
|
||||
- [ ] **Deliverable:** จัดการ Contract Drawings ได้
|
||||
- [ ] **Dependencies:** T1.1, T1.2, T1.4, T1.5, T2.2
|
||||
|
||||
- **[ ] T4.2 DrawingModule - Shop Drawings**
|
||||
|
||||
- [ ] สร้าง Entities (ShopDrawing, Revision, Main/SubCategory, ContractRef, RevisionAttachment)
|
||||
- [ ] สร้าง ShopDrawingService CRUD (รวมการสร้าง Revision)
|
||||
- [ ] สร้าง Controllers (GET/POST /drawings/shop, /drawings/shop/:id/revisions)
|
||||
- [ ] Link Shop Drawing Revision → Contract Drawings
|
||||
- [ ] **Security:** Implement virus scanning สำหรับ drawing files
|
||||
- [ ] **Deliverable:** จัดการ Shop Drawings และ Revisions ได้
|
||||
- [ ] **Dependencies:** T4.1
|
||||
|
||||
- **[ ] T5.1 RfaModule with Unified Workflow**
|
||||
|
||||
- [ ] สร้าง Entities (Rfa, RfaRevision, RfaItem, RfaWorkflowTemplate/Step)
|
||||
- [ ] สร้าง RfaService (Create RFA, Link Shop Drawings)
|
||||
- [ ] Implement RFA Workflow โดยใช้ Configuration ของ `WorkflowEngineModule`
|
||||
- [ ] สร้าง Controllers (POST/GET /rfas, POST /rfas/:id/workflow/...)
|
||||
- [ ] **Resilience:** Implement circuit breaker สำหรับ notification services
|
||||
- [ ] **Deliverable:** RFA Workflow ทำงานได้ด้วย Unified Engine
|
||||
- [ ] **Dependencies:** T3.2, T4.2, T2.5, T6.2
|
||||
|
||||
-----
|
||||
|
||||
## **Phase 5: Workflow Systems & Resilience (สัปดาห์ที่ 8-9)**
|
||||
|
||||
**Milestone:** ระบบ Workflow ทั้งหมดพร้อม Resilience Patterns
|
||||
|
||||
### **Phase 5: Tasks**
|
||||
|
||||
- **[ ] T5.2 CirculationModule - Internal Routing**
|
||||
|
||||
- [ ] สร้าง Entities (Circulation, Template, Routing, Attachment)
|
||||
- [ ] สร้าง CirculationService (Create 1:1 with Correspondence, Assign User, Complete/Close Step)
|
||||
- [ ] สร้าง Controllers (POST/GET /circulations, POST /circulations/:id/steps/...)
|
||||
- [ ] **Resilience:** Implement retry mechanism สำหรับ assignment notifications
|
||||
- [ ] **Deliverable:** ใบเวียนภายในองค์กรทำงานได้
|
||||
- [ ] **Dependencies:** T3.2, T2.5, T6.2
|
||||
|
||||
- **[ ] T5.3 TransmittalModule - Document Forwarding**
|
||||
|
||||
- [ ] สร้าง Entities (Transmittal, TransmittalItem)
|
||||
- [ ] สร้าง TransmittalService (Create Correspondence + Transmittal, Link Multiple Correspondences)
|
||||
- [ ] สร้าง Controllers (POST/GET /transmittals)
|
||||
- [ ] **Security:** Implement access control สำหรับ transmittal items
|
||||
- [ ] **Deliverable:** สร้าง Transmittal ได้
|
||||
- [ ] **Dependencies:** T3.2
|
||||
|
||||
-----
|
||||
|
||||
## **Phase 6: Notification & Resilience (สัปดาห์ที่ 9)**
|
||||
|
||||
**Milestone:** ระบบแจ้งเตือนแบบ Digest และการจัดการข้อมูลขนาดใหญ่
|
||||
|
||||
### **Phase 6: Tasks**
|
||||
|
||||
- **[ ] T6.1 SearchModule - Elasticsearch Integration**
|
||||
|
||||
- [ ] Setup Elasticsearch Container
|
||||
- [ ] สร้าง SearchService (index/update/delete documents, search)
|
||||
- [ ] Index ทุก Document Type
|
||||
- [ ] สร้าง Controllers (GET /search)
|
||||
- [ ] **Resilience:** Implement circuit breaker สำหรับ Elasticsearch
|
||||
- [ ] **Deliverable:** ค้นหาขั้นสูงทำงานได้
|
||||
- [ ] **Dependencies:** T3.2, T5.1, T4.2, T5.2, T5.3
|
||||
|
||||
- **[ ] T6.2 Notification Queue & Digest**
|
||||
|
||||
- [ ] สร้าง NotificationService (sendEmail/Line/System)
|
||||
- [ ] **Producer:** Push Event ลง BullMQ Queue
|
||||
- [ ] **Consumer:** จัดกลุ่ม Notification (Digest Message) และส่งผ่าน Email/Line
|
||||
- [ ] Integrate กับ Workflow Events (แจ้ง Recipients, Assignees, Deadline)
|
||||
- [ ] สร้าง Controllers (GET /notifications, PUT /notifications/:id/read)
|
||||
- [ ] **Resilience:** Implement retry mechanism ด้วย exponential backoff
|
||||
- [ ] **Deliverable:** ระบบแจ้งเตือนทำงานได้แบบ Digest
|
||||
- [ ] **Dependencies:** T1.1, T6.4
|
||||
|
||||
- **[ ] T6.3 MonitoringModule - Observability**
|
||||
|
||||
- [ ] สร้าง Health Check Controller (GET /health)
|
||||
- [ ] สร้าง Metrics Service (API response times, Error rates)
|
||||
- [ ] สร้าง Performance Interceptor (Track request duration)
|
||||
- [ ] สร้าง Logging Service (Structured logging)
|
||||
- [ ] **Deliverable:** Monitoring system ทำงานได้
|
||||
- [ ] **Dependencies:** T1.1
|
||||
|
||||
- **[ ] T6.4 ResilienceModule - Circuit Breaker & Retry**
|
||||
|
||||
- [ ] สร้าง Circuit Breaker Service (@CircuitBreaker() decorator)
|
||||
- [ ] สร้าง Retry Service (@Retry() decorator)
|
||||
- [ ] สร้าง Fallback Strategies
|
||||
- [ ] Implement สำหรับ Email, LINE, Elasticsearch, Virus Scanning
|
||||
- [ ] **Deliverable:** Resilience patterns ทำงานได้
|
||||
- [ ] **Dependencies:** T1.1
|
||||
|
||||
- **[ ] T6.5 Data Partitioning Strategy**
|
||||
|
||||
- [ ] ออกแบบ Table Partitioning สำหรับ `audit_logs` และ `notifications` (แบ่งตาม Range: Year)
|
||||
- [ ] เขียน Raw SQL Migration สำหรับสร้าง Partition Table
|
||||
- [ ] **Deliverable:** Database Performance และ Scalability ดีขึ้น
|
||||
- [ ] **Dependencies:** T0.3
|
||||
|
||||
-----
|
||||
|
||||
## **Phase 7: Testing & Hardening (สัปดาห์ที่ 10-12)**
|
||||
|
||||
**Milestone:** ทดสอบความทนทานต่อ Race Condition, Security, และ Performance
|
||||
|
||||
### **Phase 7: Tasks**
|
||||
|
||||
- **[ ] T7.1 Concurrency Testing**
|
||||
|
||||
- [ ] เขียน Test Scenarios ยิง Request ขอเลขที่เอกสารพร้อมกัน 100 Request (ต้องไม่ซ้ำและไม่ข้าม)
|
||||
- [ ] ทดสอบ Optimistic Lock ทำงานถูกต้องเมื่อ Redis ถูกปิด
|
||||
- [ ] ทดสอบ File Upload พร้อมกันหลายไฟล์
|
||||
- [ ] **Deliverable:** ระบบทนทานต่อ Concurrency Issues
|
||||
|
||||
- **[ ] T7.2 Transaction Integrity Testing**
|
||||
|
||||
- [ ] ทดสอบ Upload ไฟล์แล้ว Kill Process ก่อน Commit
|
||||
- [ ] ทดสอบ Two-Phase File Storage ทำงานถูกต้อง
|
||||
- [ ] ทดสอบ Database Transaction Rollback Scenarios
|
||||
- [ ] **Deliverable:** Data Integrity รับประกันได้
|
||||
|
||||
- **[ ] T7.3 Security & Idempotency Test**
|
||||
|
||||
- [ ] ทดสอบ Replay Attack โดยใช้ `Idempotency-Key` ซ้ำ
|
||||
- [ ] ทดสอบ Maintenance Mode Block API ได้จริง
|
||||
- [ ] ทดสอบ RBAC 4-Level ทำงานถูกต้อง 100%
|
||||
- [ ] **Deliverable:** Security และ Idempotency ทำงานได้ตาม设计要求
|
||||
|
||||
- **[ ] T7.4 Unit Testing (80% Coverage)**
|
||||
|
||||
- **[ ] T7.5 Integration Testing**
|
||||
|
||||
- **[ ] T7.6 E2E Testing**
|
||||
|
||||
- **[ ] T7.7 Performance Testing**
|
||||
|
||||
- [ ] Load Testing: 100 concurrent users
|
||||
- [ ] **(สำคัญ)** การจูนและทดสอบ Load Test จะต้องทำในสภาพแวดล้อมที่จำลอง Spec ของ QNAP Server (TS-473A, AMD Ryzen V1500B) เพื่อให้ได้ค่า Response Time และ Connection Pool ที่เที่ยงตรง
|
||||
- [ ] Stress Testing
|
||||
- [ ] Endurance Testing
|
||||
- [ ] **Deliverable:** Performance targets บรรลุ
|
||||
|
||||
- **[ ] T7.8 Security Testing**
|
||||
|
||||
- [ ] Penetration Testing (OWASP Top 10)
|
||||
- [ ] Security Audit (Code review, Dependency scanning)
|
||||
- [ ] File Upload Security Testing
|
||||
- [ ] **Deliverable:** Security tests ผ่าน
|
||||
|
||||
- **[ ] T7.9 Performance Optimization**
|
||||
|
||||
- [ ] Implement Caching (Master Data, User Permissions, Search Results)
|
||||
- [ ] Database Optimization (Review Indexes, Query Optimization, Pagination)
|
||||
- [ ] **Deliverable:** Response Time < 200ms (90th percentile)
|
||||
|
||||
-----
|
||||
|
||||
## **Phase 8: Documentation & Deployment (สัปดาห์ที่ 14)**
|
||||
|
||||
**Milestone:** เอกสารและ Deploy สู่ Production พร้อม Security Hardening
|
||||
|
||||
### **Phase 8: Tasks**
|
||||
|
||||
- **[ ] T8.1 API Documentation (Swagger)**
|
||||
- **[ ] T8.2 Technical Documentation**
|
||||
- **[ ] T8.3 Security Hardening**
|
||||
- **[ ] T8.4 Deployment Preparation (QNAP Setup, Nginx Proxy Manager)**
|
||||
- **[ ] T8.5 Production Deployment**
|
||||
- **[ ] T8.6 Handover to Frontend Team**
|
||||
|
||||
-----
|
||||
|
||||
## 📊 **สรุป Timeline**
|
||||
|
||||
| Phase | ระยะเวลา | จำนวนงาน | Output หลัก |
|
||||
| :------ | :----------- | :----------- | :--------------------------------------------- |
|
||||
| Phase 0 | 1 สัปดาห์ | 4 | Infrastructure Ready + Security Base |
|
||||
| Phase 1 | 2 สัปดาห์ | 5 | Auth & User Management + RBAC + Idempotency |
|
||||
| Phase 2 | 1 สัปดาห์ | 5 | High-Integrity Data & File Management |
|
||||
| Phase 3 | 2 สัปดาห์ | 4 | Unified Workflow Engine + Correspondence |
|
||||
| Phase 4 | 2 สัปดาห์ | 3 | Drawing Management + RFA with Unified Workflow |
|
||||
| Phase 5 | 2 สัปดาห์ | 2 | Workflow Systems + Resilience |
|
||||
| Phase 6 | 1 สัปดาห์ | 5 | Notification & Resilience + Data Partitioning |
|
||||
| Phase 7 | 3 สัปดาห์ | 9 | Testing & Hardening |
|
||||
| Phase 8 | 1 สัปดาห์ | 6 | Documentation & Deploy |
|
||||
| **รวม** | **15 สัปดาห์** | **39 Tasks** | **Production-Ready Backend v1.4.2** |
|
||||
|
||||
## **Document Control:**
|
||||
|
||||
- **Document:** Backend Development Plan v1.4.3
|
||||
- **Version:** 1.4
|
||||
- **Date:** 2025-11-26
|
||||
- **Author:** NAP LCBP3-DMS & Gemini
|
||||
- **Status:** FINAL-Rev.04
|
||||
- **Classification:** Internal Technical Documentation
|
||||
- **Approved By:** Nattanin
|
||||
|
||||
-----
|
||||
|
||||
`End of Backend Development Plan v1.4.4`
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
+191
@@ -0,0 +1,191 @@
|
||||
# Special requirements for document-numbering
|
||||
การใช้งานจริงต้องการความยืดหยุ่นสูง สำหรับ ระบบ document-numbering ดังนี้
|
||||
|
||||
## 1. ต้องให้ admin สามารถกำหนดรูปแบบในถายหลังได้
|
||||
## 2. มีรูปแบบเริ่มต้นดังนี้
|
||||
* 2.1 สำหรับ correspondence ทั่วไป
|
||||
* ใช้รูปแบบ [organizations.organization_code]-[organizations.organization_code]-[sequence]-[year]
|
||||
* **_ตัวอย่าง: คคง.-ผรม.2-0123-2568_**
|
||||
* 2.2 สำหรับ correspondence type = transmittal
|
||||
* to OWNER ใช้รูปแบบ [organizations.organization_code]-[organizations.organization_code]-[codecorrespondence_sub_types.sub_type_number]-[seq]-[year]
|
||||
* **_ตัวอย่าง: คคง.-สคฉ.3-22-0123-2568_**
|
||||
* to CONTRACTOR ใช้รูปแบบ [organizations.organization_code]-[organizations.organization_code]-[codecorrespondence_sub_types.sub_type_number]-[seq]-[year]
|
||||
* **_ตัวอย่าง: คคง.-สคฉ.3-22-0123-2568_**
|
||||
* 2.3 สำหรับ correspondence type = rfi
|
||||
* ใช้รูปแบบ [contrcts.contract_code]-[correspondences_types.type_code]-[disciplines_code]-[seq]-[revision]
|
||||
* **_ตัวอย่าง: LCBP3-C2-RFI-TER-2345-A_**
|
||||
* 2.4 สำหรับ rfa ใช้แบบเลขแยกกัน
|
||||
* ใช้รูปแบบ [contrcts.contract_code]-[correspondences_types.type_code]-[disciplines_code]-[rfa_types.type_code]-[seq]-[revision]
|
||||
* **_ตัวอย่าง: LCBP3-C1-RFA-TER-MAT-1234-A_**
|
||||
และตรวจสอบ 01_lcbp3_v1_4_3.sql, 4_Data_Dictionary_V1_4_3.md
|
||||
## ตาราง correspondence_sub_types
|
||||
|
||||
| contract_code | correspondence_types.type_code | sub_type_code | sub_type_name | sub_type_number |
|
||||
| ------------- | ------------------------------ | ------------- | ------------------------------ | --------------- |
|
||||
| LCBP3-C1 | RFA | MAT | Material Approval | 11 |
|
||||
| LCBP3-C1 | RFA | SHP | Shop Drawing Submittal | 12 |
|
||||
| LCBP3-C1 | RFA | DWG | Document Approval | 13 |
|
||||
| LCBP3-C1 | RFA | MET | Engineering Document Submittal | 14 |
|
||||
| LCBP3-C2 | RFA | MAT | Material Approval | 21 |
|
||||
| LCBP3-C2 | RFA | SHP | Shop Drawing Submittal | 22 |
|
||||
| LCBP3-C2 | RFA | DWG | Document Approval | 23 |
|
||||
| LCBP3-C2 | RFA | MET | Engineering Document Submittal | 24 |
|
||||
| LCBP3-C3 | RFA | MAT | Material Approval | 31 |
|
||||
| LCBP3-C3 | RFA | SHP | Shop Drawing Submittal | 32 |
|
||||
| LCBP3-C3 | RFA | DWG | Document Approval | 33 |
|
||||
| LCBP3-C4 | RFA | MET | Engineering Document Submittal | 34 |
|
||||
| LCBP3-C4 | RFA | MAT | Material Approval | 41 |
|
||||
| LCBP3-C4 | RFA | SHP | Shop Drawing Submittal | 42 |
|
||||
| LCBP3-C4 | RFA | DWG | Document Approval | 43 |
|
||||
| LCBP3-C4 | RFA | MET | Engineering Document Submittal | 44 |
|
||||
|
||||
## ตาราง disciplines
|
||||
|
||||
| contract_code | disciplines_code | code_name_th | code_name_en |
|
||||
| ------------- | ---------------- | ----------------------------- | ------------------------------------------ |
|
||||
| LCBP3-C1 | GEN | งานบริหารโครงการ | General Management |
|
||||
| LCBP3-C1 | COD | สัญญาและข้อโต้แย้ง | Contracting |
|
||||
| LCBP3-C1 | QSB | สำรวจปริมาณและควบคุมงบประมาณ | Quantity Survey and Budget Control |
|
||||
| LCBP3-C1 | PPG | บริหารแผนและความก้าวหน้า | Plan and Progress Management |
|
||||
| LCBP3-C1 | PRC | งานจัดซื้อ | Procurement |
|
||||
| LCBP3-C1 | SUB | ผู้รับเหมาช่วง | Subcontractor |
|
||||
| LCBP3-C1 | ODC | สำนักงาน-ควบคุมเอกสาร | Operation Docment Control |
|
||||
| LCBP3-C1 | LAW | กฎหมาย | Law |
|
||||
| LCBP3-C1 | TRF | จราจร | Traffic |
|
||||
| LCBP3-C1 | BIM | BIM | Building information modeling |
|
||||
| LCBP3-C1 | SRV | งานสำรวจ | Survey |
|
||||
| LCBP3-C1 | SFT | ความปลอดภัย | Safety |
|
||||
| LCBP3-C1 | BST | งานโครงสร้างอาคาร | Building Structure Work |
|
||||
| LCBP3-C1 | TEM | งานชั่วคราว | Temporary Work |
|
||||
| LCBP3-C1 | UTL | งานระบบสาธารณูปโภค | Utility |
|
||||
| LCBP3-C1 | EPW | งานระบบไฟฟ้า | Electrical Power Work |
|
||||
| LCBP3-C1 | ECM | งานระบบไฟฟ้าสื่อสาร | Electrical Communication Work |
|
||||
| LCBP3-C1 | ENV | สิ่งแวดล้อม | Environment |
|
||||
| LCBP3-C1 | AQV | คุณภาพอากาศและความสั่นสะเทือน | Air quality and vibration |
|
||||
| LCBP3-C1 | WAB | คุณภาพน้ำและชีววิทยาทางน้ำ | Water quality and Aquatic biology |
|
||||
| LCBP3-C1 | ONS | วิศวกรรมชายฝั่ง | Onshore Engineer Work |
|
||||
| LCBP3-C1 | PPR | มวลชนสัมพันธ์และการประชาสัมพันธ์ | Public Relations |
|
||||
| LCBP3-C1 | OSW | งานก่อสร้างงานทางทะเล | Offshore Work |
|
||||
| LCBP3-C1 | DRE | งานขุดและถมทะเล | Dredging and Reclamation |
|
||||
| LCBP3-C1 | REV | งานคันหินล้อมพื้นที่ถมทะเล | Revetment |
|
||||
| LCBP3-C1 | BRW | งานเขื่อนกันคลื่น | Breakwater |
|
||||
| LCBP3-C1 | SOI | ปรับปรุงคุณภาพดิน | Soil Improvement |
|
||||
| LCBP3-C1 | BLC | งานปรับปรุงคลองบางละมุง | Bang Lamung Canal Bank Protection |
|
||||
| LCBP3-C1 | FUP | งานประตูระบายน้ำและท่อลอด | Floodgate & Under Ground Piping Works |
|
||||
| LCBP3-C1 | SWP | งานอาคารควบคุมสถานีสูบน้ำทะเล | Sea Water Pumping Station Control BuilDing |
|
||||
| LCBP3-C1 | NAV | งานติดตั้งเครื่องหมายช่วงการเดินเรือ | Navigations Aids |
|
||||
| LCBP3-C1 | GEO | งานด้านธรณีเทคนิค | Geotechnical |
|
||||
| LCBP3-C1 | CRW | งานด้านโยธา - Rock Works | Civil-Rock work |
|
||||
| LCBP3-C1 | DVR | ทีมนักประดาน้ำ | Dive Work |
|
||||
| LCBP3-C1 | MTS | งานทดสอบวัสดุและธรณีเทคนิค | Materials and Geotechnical Testing |
|
||||
| LCBP3-C1 | OTH | อื่นๆ | Other |
|
||||
| LCBP3-C2 | GEN | งานบริหารโครงการ | Project Management |
|
||||
| LCBP3-C2 | COD | สัญญาและข้อโต้แย้ง | Contracts and arguments |
|
||||
| LCBP3-C2 | QSB | สำรวจปริมาณและควบคุมงบประมาณ | Survey the quantity and control the budget |
|
||||
| LCBP3-C2 | PPM | บริหารแผนและความก้าวหน้า | Plan Management & Progress |
|
||||
| LCBP3-C2 | ODC | สำนักงาน-ควบคุมเอกสาร | Document Control Office |
|
||||
| LCBP3-C2 | LAW | กฎหมาย | Law |
|
||||
| LCBP3-C2 | TRF | จราจร | Traffic |
|
||||
| LCBP3-C2 | BIM | Building Information Modeling | Building Information Modeling |
|
||||
| LCBP3-C2 | SRV | งานสำรวจ | Survey |
|
||||
| LCBP3-C2 | SFT | ความปลอดภัย | Safety |
|
||||
| LCBP3-C2 | BST | งานโครงสร้างอาคาร | Building Structure |
|
||||
| LCBP3-C2 | UTL | งานะบบสาธารณูปโภค | Public Utilities |
|
||||
| LCBP3-C2 | EPW | งานระบบไฟฟ้า | Electrical Systems |
|
||||
| LCBP3-C2 | ECM | งานระบบไฟฟ้าสื่อสาร | Electrical Communication System |
|
||||
| LCBP3-C2 | ENV | สิ่งแวดล้อม | Environment |
|
||||
| LCBP3-C2 | AQV | คุณภาพอากาศและความสั่นสะเทือน | Air Quality and Vibration |
|
||||
| LCBP3-C2 | WAB | คุณภาพน้ำและชีววิทยาทางน้ำ | Water Quality and Aquatic Biology |
|
||||
| LCBP3-C2 | ONS | วิศวกรรมชายฝั่ง | Coastal Engineering |
|
||||
| LCBP3-C2 | PPR | มวลชนสัมพันธ์และประชาสัมพันธ์ | Mass Relations and Public Relations |
|
||||
| LCBP3-C2 | OFW | งานก่อสร้างทางทะเล | Marine Construction |
|
||||
| LCBP3-C2 | EXR | งานขุดและถมทะเล | Excavation and reclamation |
|
||||
| LCBP3-C2 | GEO | งานด้านธรณีเทคนิค | Geotechnical work |
|
||||
| LCBP3-C2 | CRW | งานด้านโยธา - Rock Works | Civil Works - Rock Works |
|
||||
| LCBP3-C2 | DVW | ทีมนักประดาน้ำ | Team of Divers |
|
||||
| LCBP3-C2 | MTT | งานทดสอบวัสดุ | Materials Testing |
|
||||
| LCBP3-C2 | ARC | งานสถาปัตยกรรม | Architecture |
|
||||
| LCBP3-C2 | STR | งานโครงสร้าง | Structural work |
|
||||
| LCBP3-C2 | SAN | งานระบบสุขาภิบาล | Sanitation System |
|
||||
| LCBP3-C2 | DRA | งานระบบระบายน้ำ | Drainage system work |
|
||||
| LCBP3-C2 | TER | งานท่าเทียบเรือ | Terminal Work work |
|
||||
| LCBP3-C2 | BUD | งานอาคาร | Building |
|
||||
| LCBP3-C2 | ROW | งานถนนและสะพาน | Road and Bridge Work |
|
||||
| LCBP3-C2 | MEC | งานเคริองกล | Mechanical work |
|
||||
| LCBP3-C2 | OTH | อื่น ๆ | Others |
|
||||
|
||||
## 📌ตาราง rfa_types
|
||||
|
||||
| contract_code | type_code | type_name_en | type_name_th |
|
||||
| ------------- | --------- | ---------------------------------------------- | ------------------------------------------------ |
|
||||
| LCBP3-C1 | ADW | As Built Drawing | แบบร่างหลังการก่อสร้าง |
|
||||
| LCBP3-C1 | BC | Box Culvert | ท่อระบายน้ำรูปกล่อง |
|
||||
| LCBP3-C1 | BM | Benchmark | หมุดหลักฐาน |
|
||||
| LCBP3-C1 | CER | Certificates | ใบรับรอง |
|
||||
| LCBP3-C1 | CN | Canal Drainage | ระบบระบายน้ำในคลอง |
|
||||
| LCBP3-C1 | CON | Contract | สัญญา |
|
||||
| LCBP3-C1 | DDS | Design Data Submission | นำส่งข้อมูลการออกแบบ |
|
||||
| LCBP3-C1 | DDW | Draft Drawing | แบบร่าง |
|
||||
| LCBP3-C1 | DRW | Drawings (All Types) | แบบก่อสร้าง |
|
||||
| LCBP3-C1 | DSN | Design/Calculation/Manual (All Stages) | ออกแบบ / คำนวณ / คู่มือ |
|
||||
| LCBP3-C1 | GEN | General | ทั่วไป |
|
||||
| LCBP3-C1 | ICR | Incident Report | รายงานการเกิดอุบัติเหตุและการบาดเจ็บ |
|
||||
| LCBP3-C1 | INS | Insurances/Bond/Guarantee | การประกัน / พันธบัตร / การค้ำประกัน |
|
||||
| LCBP3-C1 | INR | Inspection/Audit/Surveillance Report | รายงานการตรวจสอบ / การตรวจสอบ / รายงานการเฝ้าระวัง |
|
||||
| LCBP3-C1 | ITP | Inspection and Test Plan | แผนการตรวจสอบและทดสอบ |
|
||||
| LCBP3-C1 | JSA | Jobs Analysis | รายงานการวิเคราะห์ความปลอดภัย |
|
||||
| LCBP3-C1 | MAN | Manual | คู่มือ |
|
||||
| LCBP3-C1 | MAT | Materials/Equipment/Plant | วัสดุ / อุปกรณ์ / โรงงาน |
|
||||
| LCBP3-C1 | MOM | Minutes of Meeting | รายงานการประชุม |
|
||||
| LCBP3-C1 | MPR | Monthly Progress Report | รายงานความคืบหน้าประจำเดือน |
|
||||
| LCBP3-C1 | MST | Method Statement for Construction/Installation | ขั้นตอนการก่อสร้าง / ติดตั้ง |
|
||||
| LCBP3-C1 | NDS | Non-Design Data Submission | นำส่งข้อมูลที่ไม่เกี่ยวข้องกับการออกแบบ |
|
||||
| LCBP3-C1 | PMA | Payment/Invoice/Retention/Estimate | การชำระเงิน / ใบแจ้งหนี้ / ประกันผลงาน / ประมาณการ |
|
||||
| LCBP3-C1 | PRD | Procedure | ระเบียบปฏิบัติ |
|
||||
| LCBP3-C1 | PRG | Progress of Construction | ความคืบหน้าของการก่อสร้าง / ภาพถ่าย / วิดีโอ |
|
||||
| LCBP3-C1 | QMS | Quality Document (Plan/Work Instruction) | เอกสารด้านคุณภาพ (แผนงาน / ข้อแนะนำในการทำงาน) |
|
||||
| LCBP3-C1 | RPT | Report | รายงาน |
|
||||
| LCBP3-C1 | SAR | Semi Annual Report | รายงานประจำหกเดือน |
|
||||
| LCBP3-C1 | SCH | Schedule and Program | แผนงาน |
|
||||
| LCBP3-C1 | SDW | Shop Drawing | แบบขยายรายละเอียด |
|
||||
| LCBP3-C1 | SI | Soil Investigation | การตรวจสอบดิน |
|
||||
| LCBP3-C1 | SPE | Specification | ข้อกำหนด |
|
||||
| LCBP3-C1 | TNR | Training Report | รายงานการฝึกปฏิบัติ |
|
||||
| LCBP3-C1 | UC | Underground Construction | โครงสร้างใต้ดิน |
|
||||
| LCBP3-C1 | VEN | Vendor | ผู้ขาย |
|
||||
| LCBP3-C1 | VRO | Variation Request/Instruction/Order | คำขอเปลี่ยนแปลง / ข้อเสนอแนะ / ข้อเรียกร้อง |
|
||||
| LCBP3-C1 | WTY | Warranty | การประกัน |
|
||||
| LCBP3-C2 | GEN | General | ทั่วไป |
|
||||
| LCBP3-C2 | CON | Contract | สัญญา |
|
||||
| LCBP3-C2 | INS | Insurances/Bond/Guarantee | การประกัน / พันธบัตร / การค้ำประกัน |
|
||||
| LCBP3-C2 | SCH | Schedule and Program | แผนงาน |
|
||||
| LCBP3-C2 | PMA | Payment/Invoice/Retention/Estimate | การชำระเงิน / ใบแจ้งหนี้ / ประกันผลงาน / ประมาณการ |
|
||||
| LCBP3-C2 | VRO | Variation Request/Instruction/Order | คำขอเปลี่ยนแปลง / ข้อเสนอแนะ / ข้อเรียกร้อง |
|
||||
| LCBP3-C2 | VEN | Vendor | ผู้ขาย |
|
||||
| LCBP3-C2 | WTY | Warranty | การประกัน |
|
||||
| LCBP3-C2 | DRW | Drawings (All Types) | แบบก่อสร้าง |
|
||||
| LCBP3-C2 | DDW | Draft Drawing | แบบร่าง |
|
||||
| LCBP3-C2 | SDW | Shop Drawing | แบบขยายรายละเอียด |
|
||||
| LCBP3-C2 | ADW | As Built Drawing | แบบร่างหลังการก่อสร้าง |
|
||||
| LCBP3-C2 | DDS | Design Data Submission | นำส่งข้อมูลการออกแบบ |
|
||||
| LCBP3-C2 | DSN | Design/Calculation/Manual (All Stages) | ออกแบบ / คำนวณ / คู่มือ |
|
||||
| LCBP3-C2 | NDS | Non-Design Data Submission | นำส่งข้อมูลที่ไม่เกี่ยวข้องกับการออกแบบ |
|
||||
| LCBP3-C2 | PRD | Procedure | ระเบียบปฏิบัติ |
|
||||
| LCBP3-C2 | MST | Method Statement for Construction/Installation | ขั้นตอนการก่อสร้าง / ติดตั้ง |
|
||||
| LCBP3-C2 | QMS | Quality Document (Plan/Work Instruction) | เอกสารด้านคุณภาพ (แผนงาน / ข้อแนะนำในการทำงาน) |
|
||||
| LCBP3-C2 | INR | Inspection/Audit/Surveillance Report | รายงานการตรวจสอบ / การตรวจสอบ / รายงานการเฝ้าระวัง |
|
||||
| LCBP3-C2 | ITP | Inspection and Test Plan | แผนการตรวจสอบและทดสอบ |
|
||||
| LCBP3-C2 | MAT | Materials/Equipment/Plant | วัสดุ / อุปกรณ์ / โรงงาน |
|
||||
| LCBP3-C2 | SPE | Specification | ข้อกำหนด |
|
||||
| LCBP3-C2 | MAN | Manual | คู่มือ |
|
||||
| LCBP3-C2 | CER | Certificates | ใบรับรอง |
|
||||
| LCBP3-C2 | SAR | Semi Annual Report | รายงานประจำหกเดือน |
|
||||
| LCBP3-C2 | JSA | Jobs Analysis | รายงานการวิเคราะห์ความปลอดภัย |
|
||||
| LCBP3-C2 | MOM | Minutes of Meeting | รายงานการประชุม |
|
||||
| LCBP3-C2 | MPR | Monthly Progress Report | รายงานความคืบหน้าประจำเดือน |
|
||||
| LCBP3-C2 | ICR | Incident Report | รายงานการเกิดอุบัติเหตุและการบาดเจ็บ |
|
||||
| LCBP3-C2 | PRG | Progress of Construction | ความคืบหน้าของการก่อสร้าง / ภาพถ่าย / วิดีโอ |
|
||||
| LCBP3-C2 | RPT | Report | รายงาน |
|
||||
| LCBP3-C2 | TNR | Training Report | รายงานการฝึกปฏิบัติ |
|
||||
|
||||
---
|
||||
@@ -0,0 +1,397 @@
|
||||
# “Phase 6A + Technical Design Document : Workflow DSL (Mini-Language)”**
|
||||
ออกแบบสำหรับระบบ Workflow Engine กลางของโครงการ
|
||||
**ไม่มีโค้ดผูกกับ Framework** เพื่อให้สามารถนำไป Implement ใน NestJS หรือ Microservice ใด ๆ ได้
|
||||
|
||||
---
|
||||
|
||||
## 📌 **Phase 6A – Workflow DSL Implementation Plan**
|
||||
|
||||
### 🎯 เป้าหมายของ Phase 6A
|
||||
|
||||
ใน Phase นี้ จะเริ่มสร้าง “Workflow DSL (Domain-Specific Language)” สำหรับนิยามกฎการเดินงาน (Workflow Transition Rules) ให้สามารถ:
|
||||
|
||||
* แยก **Business Workflow Logic** ออกจาก Source Code
|
||||
* แก้ไขกฎ Workflow ได้โดย **ไม่ต้องแก้โค้ดและไม่ต้อง Deploy ใหม่**
|
||||
* รองรับ Document หลายประเภท เช่น
|
||||
|
||||
* Correspondence
|
||||
* RFA
|
||||
* Internal Circulation
|
||||
* Document Transmittal
|
||||
* รองรับ Multi-step routing, skip, reject, rollback, parallel assignments
|
||||
* สามารถนำไปใช้งานทั้งใน
|
||||
|
||||
* Backend (NestJS)
|
||||
* Frontend (UI Driven)
|
||||
* External Microservices
|
||||
|
||||
---
|
||||
|
||||
### 📅 ระยะเวลา
|
||||
|
||||
**1 สัปดาห์ (หลัง Phase 6.5)**
|
||||
|
||||
---
|
||||
|
||||
### 🧩 Output ของ Phase 6A
|
||||
|
||||
* DSL Specification (Grammar)
|
||||
* JSON Schema for Workflow Definition
|
||||
* Workflow Rule Interpreter (Parser + Executor)
|
||||
* Validation Engine (Compile-time and Runtime)
|
||||
* Storage (DB Table / Registry)
|
||||
* Execution API:
|
||||
|
||||
| Action | Description |
|
||||
| -------------------------------- | ------------------------------- |
|
||||
| compile() | ตรวจ DSL → สร้าง Execution Tree |
|
||||
| evaluate(state, action, context) | ประมวลผลและส่งสถานะใหม่ |
|
||||
| preview(state) | คำนวณ Next Possible Transitions |
|
||||
| validate() | ตรวจว่า DSL ถูกต้อง |
|
||||
|
||||
---
|
||||
|
||||
## 📘 **Technical Specification – Workflow DSL**
|
||||
|
||||
---
|
||||
|
||||
### 1️⃣ Requirements
|
||||
|
||||
#### Functional Requirements
|
||||
|
||||
* นิยาม Workflow เป็นภาษาคล้าย State Machine
|
||||
* แต่ละเอกสารมี **State, Actions, Entry/Exit Events**
|
||||
* สามารถมี:
|
||||
|
||||
* Required approvals
|
||||
* Conditional transition
|
||||
* Auto-transition
|
||||
* Parallel approval
|
||||
* Return/rollback
|
||||
|
||||
####
|
||||
* Running time: < 20ms ต่อคำสั่ง
|
||||
* Hot reload ไม่ต้อง Compile ใหม่ทั้ง Backend
|
||||
* DSL ต้อง Debug ได้ง่าย
|
||||
* ต้อง Versioned
|
||||
* ต้องรองรับ Audit 100%
|
||||
|
||||
---
|
||||
|
||||
### 2️⃣ DSL Format (Human Friendly)
|
||||
|
||||
```yaml
|
||||
workflow: RFA
|
||||
version: 1.0
|
||||
|
||||
states:
|
||||
- name: DRAFT
|
||||
initial: true
|
||||
on:
|
||||
SUBMIT:
|
||||
to: IN_REVIEW
|
||||
require:
|
||||
- role: ENGINEER
|
||||
events:
|
||||
- notify: reviewer
|
||||
|
||||
- name: IN_REVIEW
|
||||
on:
|
||||
APPROVE:
|
||||
to: APPROVED
|
||||
REJECT:
|
||||
to: DRAFT
|
||||
events:
|
||||
- notify: creator
|
||||
|
||||
- name: APPROVED
|
||||
terminal: true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3️⃣ Compiled Execution Model (Normalized JSON)
|
||||
|
||||
```json
|
||||
{
|
||||
"workflow": "RFA",
|
||||
"version": "1.0",
|
||||
"states": {
|
||||
"DRAFT": {
|
||||
"initial": true,
|
||||
"transitions": {
|
||||
"SUBMIT": {
|
||||
"to": "IN_REVIEW",
|
||||
"requirements": [
|
||||
{ "role": "ENGINEER" }
|
||||
],
|
||||
"events": [
|
||||
{ "type": "notify", "target": "reviewer" }
|
||||
]
|
||||
}
|
||||
}
|
||||
},
|
||||
"IN_REVIEW": {
|
||||
"transitions": {
|
||||
"APPROVE": { "to": "APPROVED" },
|
||||
"REJECT": {
|
||||
"to": "DRAFT",
|
||||
"events": [
|
||||
{ "type": "notify", "target": "creator" }
|
||||
]
|
||||
}
|
||||
}
|
||||
},
|
||||
"APPROVED": {
|
||||
"terminal": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Frontend และ Backend สามารถแชร์ JSON นี้ร่วมกันได้
|
||||
|
||||
---
|
||||
|
||||
### 4️⃣ DSL Grammar Definition (EBNF)
|
||||
|
||||
```ebnf
|
||||
workflow = "workflow" ":" identifier ;
|
||||
version = "version" ":" number ;
|
||||
|
||||
states = "states:" state_list ;
|
||||
state_list = { state } ;
|
||||
|
||||
state = "- name:" identifier
|
||||
[ "initial:" boolean ]
|
||||
[ "terminal:" boolean ]
|
||||
[ "on:" transition_list ] ;
|
||||
|
||||
transition_list = { transition } ;
|
||||
|
||||
transition = action ":"
|
||||
indent "to:" identifier
|
||||
[ indent "require:" requirements ]
|
||||
[ indent "events:" event_list ] ;
|
||||
|
||||
requirements = "- role:" identifier | "- user:" identifier ;
|
||||
|
||||
event_list = { event } ;
|
||||
event = "- notify:" identifier ;
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5️⃣ Validation Rules (Compile-Time)
|
||||
|
||||
#### 5.1 State Rules
|
||||
|
||||
* ต้องมีอย่างน้อย 1 state ที่ `initial: true`
|
||||
* หาก `terminal: true` → ต้องไม่มี transition ต่อไป
|
||||
|
||||
#### 5.2 Transition Rules
|
||||
|
||||
ตรวจสอบว่า:
|
||||
|
||||
* `to` ชี้ไปยัง state ที่มีอยู่
|
||||
* `require.role` ต้องเป็น role ที่ระบบรู้จัก
|
||||
* Action name ต้องเป็น **UPPER_CASE**
|
||||
|
||||
#### 5.3 Version Safety
|
||||
|
||||
* ทุกชุด Workflow DSL ต้องขึ้นกับ version
|
||||
* แก้ไขต้องสร้าง version ใหม่
|
||||
* ไม่ overwrite version เก่า
|
||||
* “Document ที่กำลังอยู่ใน step เดิมยังต้องใช้กฎเดิมได้”
|
||||
|
||||
---
|
||||
|
||||
### 6️⃣ Runtime Validation Rules
|
||||
|
||||
เมื่อ execute(action):
|
||||
|
||||
```
|
||||
input: current_state, action, context
|
||||
|
||||
1) ตรวจว่า state มี transition "action"
|
||||
2) ตรวจว่าผู้ใช้มีสิทธิ์ตาม require[]
|
||||
3) Compute next state
|
||||
4) Execute events[]
|
||||
5) Return next_state
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 7️⃣ Context Model
|
||||
|
||||
```ts
|
||||
interface WorkflowContext {
|
||||
userId: string;
|
||||
roles: string[];
|
||||
documentId: string;
|
||||
now: Date;
|
||||
payload?: any;
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 8️⃣ Execution API (Abstract)
|
||||
|
||||
```ts
|
||||
class WorkflowEngine {
|
||||
|
||||
load(dsl: string | object): CompiledWorkflow
|
||||
|
||||
compile(dsl: string | object): CompiledWorkflow
|
||||
|
||||
evaluate(state: string, action: string, context: WorkflowContext): EvalResult
|
||||
|
||||
getAvailableActions(state: string, context: WorkflowContext): string[]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 9️⃣ Interpreter Execution Flow
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Receive Action] --> B[Load Compiled Workflow]
|
||||
B --> C[Check allowed actions]
|
||||
C -->|Invalid| E[Return Error]
|
||||
C --> D[Evaluate Requirements]
|
||||
D --> F[Transition to Next State]
|
||||
F --> G[Run Events]
|
||||
G --> H[Return Success]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 🔟 Events System
|
||||
|
||||
รองรับ event หลายประเภท:
|
||||
|
||||
| event.type | ตัวอย่าง |
|
||||
| ----------- | ------------------------- |
|
||||
| notify | ส่ง Email/Line |
|
||||
| assign | เปลี่ยนผู้รับผิดชอบ |
|
||||
| webhook | ยิง Webhook ไปยังระบบอื่น |
|
||||
| auto_action | ทำ action ซ้ำโดยอัตโนมัติ |
|
||||
|
||||
---
|
||||
|
||||
### 11️⃣ Database Schema
|
||||
|
||||
#### Table: `workflow_definition`
|
||||
|
||||
| Field | Type | Description |
|
||||
| ------------- | ----------- | --------------------- |
|
||||
| id | UUID | PK |
|
||||
| workflow_code | varchar(50) | เช่น `RFA`, `CORR` |
|
||||
| version | int | Version number |
|
||||
| dsl | JSON | YAML/JSON DSL เก็บดิบ |
|
||||
| compiled | JSON | JSON ที่ Compile แล้ว |
|
||||
| created_at | timestamp | |
|
||||
| is_active | boolean | ใช้อยู่หรือไม่ |
|
||||
|
||||
#### Table: `workflow_history`
|
||||
|
||||
เก็บ audit แบบ immutable append-only
|
||||
|
||||
| Field | Description |
|
||||
| ----------- | --------------- |
|
||||
| workflow | Document Type |
|
||||
| document_id | เอกสารไหน |
|
||||
| from_state | เดิม |
|
||||
| to_state | ใหม่ |
|
||||
| action | คำสั่ง |
|
||||
| user | ใครเป็นคนทำ |
|
||||
| timestamp | เวลา |
|
||||
| metadata | เหตุการณ์อื่น ๆ |
|
||||
|
||||
---
|
||||
|
||||
### 12️⃣ Error Codes
|
||||
|
||||
| Code | Meaning |
|
||||
| ----------------------- | ---------------------- |
|
||||
| WF_NO_TRANSITION | Action นี้ไม่ถูกต้อง |
|
||||
| WF_RESTRICTED | User ไม่มีสิทธิ์ |
|
||||
| WF_MISSING_REQUIREMENTS | ไม่ผ่านเงื่อนไข |
|
||||
| WF_STATE_NOT_FOUND | ไม่มี state ที่อ้างอิง |
|
||||
| WF_SYNTAX_ERROR | DSL ผิดรูปแบบ |
|
||||
|
||||
---
|
||||
|
||||
### 13️⃣ Testing Strategy
|
||||
|
||||
#### Unit Tests
|
||||
|
||||
* Parse DSL → JSON
|
||||
* Invalid syntax → throw error
|
||||
* Invalid transitions → throw error
|
||||
|
||||
#### Integration Tests
|
||||
|
||||
* Evaluate() ผ่าน 20+ cases
|
||||
* RFA ย้อนกลับ
|
||||
* Approve chain
|
||||
* Parallel review
|
||||
|
||||
#### Load Tests
|
||||
|
||||
* 1,000 documents running workflow
|
||||
* Evaluate < 20ms ต่อ action
|
||||
|
||||
---
|
||||
|
||||
### 14️⃣ Deployment Strategy
|
||||
|
||||
#### Hot Reload Options
|
||||
|
||||
* DSL stored in DB
|
||||
* Cache in Redis
|
||||
* Touched timestamp triggers:
|
||||
|
||||
```
|
||||
invalidate cache → recompile
|
||||
```
|
||||
|
||||
#### No downtime required
|
||||
|
||||
---
|
||||
|
||||
### 15️⃣ Microservice-Ready
|
||||
|
||||
DSL Engine แยกเป็น:
|
||||
|
||||
* `workflow-engine-core` → Pure JS library
|
||||
* `workflow-service` → NestJS module
|
||||
* API public:
|
||||
|
||||
```
|
||||
POST /workflow/evaluate
|
||||
GET /workflow/preview
|
||||
POST /workflow/compile
|
||||
```
|
||||
|
||||
ภายหลังสามารถนำไปวางบน:
|
||||
|
||||
* Kubernetes
|
||||
* Worker Node
|
||||
* API Gateway
|
||||
|
||||
---
|
||||
|
||||
## 🎉 Summary
|
||||
|
||||
### สิ่งที่ Phase 6A เพิ่มเข้าในระบบ
|
||||
|
||||
✔ Workflow DSL ที่แก้ไขได้โดยไม่ต้อง Deploy
|
||||
✔ Parser + Validator + Runtime Interpreter
|
||||
✔ Database storage + Versioning
|
||||
✔ Execution API สำหรับ Backend และ Frontend
|
||||
✔ รองรับ Business Workflow ซับซ้อนทั้งหมด
|
||||
✔ Ready สำหรับ Microservice model ในอนาคต
|
||||
|
||||
+198
@@ -224,3 +224,201 @@ npm install --save-dev @nestjs/testing jest @types/jest @types/passport-jwt @typ
|
||||
2. **`src/common/file-storage/file-storage.service.ts`** (เพื่อดู Logic การจัดการไฟล์และการ Commit)
|
||||
|
||||
หรือถ้าต้องการให้ผมเริ่มเขียน Code ส่วนไหนที่ยังขาดอยู่ (เช่น Workflow DSL Parser) สามารถแจ้งได้เลยครับ
|
||||
|
||||
|
||||
สวัสดีครับ ในฐานะ Programmer ที่ดูแลระบบ LCBP3-DMS ผมได้ทำการ **Review เอกสาร `6B.md` (Special requirements for document-numbering)** โดยเทียบกับโครงสร้างฐานข้อมูลและแผนงานที่มีอยู่ (v1.4.3) พบประเด็นสำคัญและการปรับปรุงทางเทคนิคที่จำเป็นดังนี้ครับ
|
||||
|
||||
-----
|
||||
|
||||
# 📝 ผลการ Review เอกสาร 6B.md และแนวทางการ Implement
|
||||
|
||||
## 1\. บทวิเคราะห์และผลกระทบ (Analysis & Impact)
|
||||
|
||||
เอกสาร `6B.md` ระบุความต้องการที่ **ซับซ้อนกว่า** ระบบ Running Number ทั่วไป (ที่มักเป็น `ORG-TYPE-YEAR-SEQ`) โดยมีประเด็นสำคัญคือ:
|
||||
|
||||
1. **Requirement 1 (Flexibility):** Admin ต้องแก้ format ได้ → **รองรับได้** ด้วยตาราง `document_number_formats` ที่มีอยู่ แต่ต้องปรับ Logic การแทนค่าตัวแปร (Token Replacement) ให้ฉลาดขึ้น
|
||||
2. **Requirement 2.1 (Correspondence ทั่วไป):** รูปแบบมาตรฐาน → **รองรับได้** ด้วยโครงสร้างปัจจุบัน
|
||||
3. **Requirement 2.2 (Transmittal):** มีเงื่อนไข "To OWNER" vs "To CONTRACTOR" ใช้เลขต่างกัน และมีการ mapping `sub_type_number` → **Impact:** ต้องเพิ่ม Logic ในการเลือก Format Template ตาม "ผู้รับ" (Recipient Role) และต้องมีตารางเก็บ Mapping `sub_type_number`
|
||||
4. **Requirement 2.3 (RFI) & 2.4 (RFA):** มีการใช้ `disciplines_code` (เช่น GEN, STR, ARC) และไม่มีปี (Year) ใน Format → **Impact:**
|
||||
* ฐานข้อมูลปัจจุบันขาดตาราง `disciplines`
|
||||
* ตาราง `document_number_counters` ปัจจุบัน Key คือ `(Project, Org, Type, Year)` แต่ RFA/RFI อาจจะต้องนับแยกตาม **Discipline** ด้วย หากไม่เพิ่ม Column ใน Counter อาจจะเกิดปัญหาเลขซ้ำหรือเลขกระโดดข้ามหมวดงาน
|
||||
|
||||
-----
|
||||
|
||||
## 2\. การออกแบบฐานข้อมูลเพิ่มเติม (Database Schema Updates)
|
||||
|
||||
เพื่อให้รองรับ Requirement นี้ ต้องมีการเพิ่มตารางและแก้ไขตาราง `01_lcbp3_v1_4_3.sql` ดังนี้:
|
||||
|
||||
### 2.1 เพิ่มตาราง `disciplines` และ `correspondence_sub_types`
|
||||
|
||||
```sql
|
||||
-- File: 01_lcbp3_v1_4_3_patch_6b.sql
|
||||
-- เพิ่มตารางหมวดงาน (Disciplines) ตาม Req 6B
|
||||
CREATE TABLE disciplines (
|
||||
id INT PRIMARY KEY AUTO_INCREMENT,
|
||||
project_id INT NOT NULL,
|
||||
discipline_code VARCHAR(10) NOT NULL COMMENT 'เช่น GEN, STR, ARC',
|
||||
name_th VARCHAR(255) COMMENT 'ชื่อไทย',
|
||||
name_en VARCHAR(255) COMMENT 'ชื่ออังกฤษ',
|
||||
is_active BOOLEAN DEFAULT TRUE,
|
||||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE,
|
||||
UNIQUE KEY uk_discipline_project (project_id, discipline_code)
|
||||
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
|
||||
|
||||
-- เพิ่มตาราง Sub Types (สำหรับ Transmittal/RFA mapping)
|
||||
CREATE TABLE correspondence_sub_type_codes (
|
||||
id INT PRIMARY KEY AUTO_INCREMENT,
|
||||
project_id INT NOT NULL,
|
||||
correspondence_type_id INT NOT NULL,
|
||||
sub_type_code VARCHAR(20) NOT NULL COMMENT 'เช่น MAT, SHP',
|
||||
sub_type_number VARCHAR(10) COMMENT 'เลขรหัส เช่น 11, 22',
|
||||
description VARCHAR(255),
|
||||
FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE,
|
||||
FOREIGN KEY (correspondence_type_id) REFERENCES correspondence_types(id) ON DELETE CASCADE
|
||||
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci;
|
||||
```
|
||||
|
||||
### 2.2 ปรับปรุงตาราง `rfas` และ `document_number_counters`
|
||||
|
||||
เนื่องจาก RFA/RFI ต้องวิ่งเลขตาม Discipline เราจึงต้องเก็บ Discipline ไว้ใน RFA และต้องใช้เป็นส่วนหนึ่งของ Key ในการนับเลข
|
||||
|
||||
```sql
|
||||
-- เพิ่ม discipline_id ในตาราง RFAs
|
||||
ALTER TABLE rfas
|
||||
ADD COLUMN discipline_id INT NULL AFTER rfa_type_id,
|
||||
ADD CONSTRAINT fk_rfa_discipline FOREIGN KEY (discipline_id) REFERENCES disciplines(id);
|
||||
|
||||
-- เพิ่ม discipline_id ในตาราง Correspondences (สำหรับ RFI)
|
||||
ALTER TABLE correspondences
|
||||
ADD COLUMN discipline_id INT NULL AFTER correspondence_type_id,
|
||||
ADD CONSTRAINT fk_corr_discipline FOREIGN KEY (discipline_id) REFERENCES disciplines(id);
|
||||
|
||||
-- ปรับปรุงตาราง Counter ให้รองรับ Discipline และ SubType (ใช้เป็น Dynamic Key หรือเพิ่ม Column)
|
||||
-- เพื่อความ Performance และ Integrity แนะนำให้เพิ่ม Column
|
||||
ALTER TABLE document_number_counters
|
||||
ADD COLUMN discipline_id INT NULL DEFAULT NULL AFTER correspondence_type_id,
|
||||
DROP PRIMARY KEY,
|
||||
ADD PRIMARY KEY (project_id, originator_organization_id, correspondence_type_id, discipline_id, current_year);
|
||||
-- หมายเหตุ: ถ้า discipline_id เป็น NULL ให้ถือว่าเป็น Counter ทั่วไป
|
||||
```
|
||||
|
||||
-----
|
||||
|
||||
## 3\. แนวทางการ Implement ใน NestJS (Backend Logic)
|
||||
|
||||
เราต้องปรับ `DocumentNumberingService` ให้เป็น **Token-Based Generator** ที่มีความยืดหยุ่นสูง
|
||||
|
||||
### 3.1 รูปแบบ Template (Format Templates)
|
||||
|
||||
Admin จะบันทึก Template ลง DB ในรูปแบบ:
|
||||
|
||||
* General: `{ORG}-{ORG}-{SEQ:4}-{YEAR}`
|
||||
* Transmittal: `{ORG}-{ORG}-{SUBTYPE_NUM}-{SEQ:4}-{YEAR}`
|
||||
* RFA: `{CONTRACT}-{TYPE}-{DISCIPLINE}-{SUBTYPE}-{SEQ:4}-{REV}`
|
||||
|
||||
### 3.2 Logic การ Generate (Pseudo Code)
|
||||
|
||||
```typescript
|
||||
// File: src/modules/document-numbering/document-numbering.service.ts
|
||||
|
||||
/**
|
||||
* Strategy:
|
||||
* 1. รับค่า Context (Project, Org, Type, Discipline, SubType, Year)
|
||||
* 2. ดึง Format Template จาก DB ตาม Type
|
||||
* 3. ถ้าเป็น Transmittal ต้องเช็คเงื่อนไขพิเศษเพื่อเลือก Template (Owner vs Contractor)
|
||||
* 4. Parse Template เพื่อหาว่าต้องใช้ Key ไหนบ้างในการ Lock และ Count
|
||||
* 5. Run Redlock + Optimistic Lock
|
||||
* 6. Replace Tokens
|
||||
*/
|
||||
|
||||
async generateNextNumber(ctx: GenerateNumberContext): Promise<string> {
|
||||
// 1. Get Template
|
||||
let template = await this.formatRepo.findOne({ ... });
|
||||
|
||||
// 2. Handle Special Logic (Requirement 2.2 Transmittal)
|
||||
if (ctx.typeCode === 'TRANSMITTAL') {
|
||||
// Logic: ถ้าส่งให้ Owner ใช้ Template A, ถ้า Contractor ใช้ Template B
|
||||
// หรือดึง sub_type_number มาเตรียมไว้
|
||||
}
|
||||
|
||||
// 3. Resolve Tokens Values
|
||||
const tokens = {
|
||||
'{ORG}': ctx.orgCode,
|
||||
'{CONTRACT}': ctx.contractCode,
|
||||
'{TYPE}': ctx.typeCode,
|
||||
'{DISCIPLINE}': ctx.disciplineCode, // จากตาราง disciplines
|
||||
'{SUBTYPE}': ctx.subTypeCode, // จาก rfa_types หรือ sub_type_codes
|
||||
'{SUBTYPE_NUM}': ctx.subTypeNumber, // จาก correspondence_sub_type_codes
|
||||
'{YEAR}': ctx.year.toString(),
|
||||
'{YEAR_SHORT}': ctx.year.toString().slice(-2),
|
||||
};
|
||||
|
||||
// 4. Construct Counter Key
|
||||
// ถ้า Template มี {DISCIPLINE} ต้องเอา discipline_id มาเป็นส่วนหนึ่งของ Composite Key ใน DB Counter
|
||||
const counterKey = {
|
||||
projectId: ctx.projectId,
|
||||
orgId: ctx.orgId,
|
||||
typeId: ctx.typeId,
|
||||
disciplineId: template.includes('{DISCIPLINE}') ? ctx.disciplineId : null,
|
||||
year: template.includes('{YEAR}') ? ctx.year : 0 // ถ้าไม่ใช้ปี ให้ใช้ 0
|
||||
};
|
||||
|
||||
// 5. Execute Double-Lock Mechanism (Redis + DB Optimistic)
|
||||
const seq = await this.runDistributedCounter(counterKey);
|
||||
|
||||
// 6. Final Replace
|
||||
let finalNumber = template.formatTemplate;
|
||||
for (const [key, value] of Object.entries(tokens)) {
|
||||
finalNumber = finalNumber.replace(key, value || '00'); // Fallback if missing
|
||||
}
|
||||
// Replace SEQ with padding
|
||||
finalNumber = finalNumber.replace(/{SEQ:(\d+)}/, (_, width) =>
|
||||
String(seq).padStart(Number(width), '0')
|
||||
);
|
||||
|
||||
return finalNumber;
|
||||
}
|
||||
```
|
||||
|
||||
-----
|
||||
|
||||
## 4\. แผนการดำเนินการ (Action Plan)
|
||||
|
||||
เพื่อให้รองรับ `6B.md` ได้สมบูรณ์ ผมขอเสนอให้ดำเนินการดังนี้:
|
||||
|
||||
1. **Database Migration:**
|
||||
* รัน SQL Script เพื่อเพิ่มตาราง `disciplines`, `correspondence_sub_type_codes`.
|
||||
* Alter ตาราง `rfas`, `correspondences` และ `document_number_counters` ตามข้อ 2.2
|
||||
2. **Seed Data:**
|
||||
* นำข้อมูลจากตารางใน `6B.md` (Disciplines, RFA Types, Sub Types) มาเขียนเป็น Seed Script ลงฐานข้อมูล เพื่อให้เริ่มต้นระบบมีข้อมูลพร้อมใช้ทันที
|
||||
3. **Backend Implementation:**
|
||||
* Update `DocumentNumberingService` ให้รองรับ Dynamic Token Replacement
|
||||
* Update `CreateRfaDto` และ `CreateCorrespondenceDto` ให้รับค่า `discipline_id` และ `sub_type_id` (ถ้ามี)
|
||||
4. **Admin Panel:**
|
||||
* ต้องมีหน้า UI ให้ Admin จัดการ Mapping ของ `Format Template` และ `Sub Type Codes` ได้ (ตาม Requirement ข้อ 1)
|
||||
|
||||
**ต้องการให้ผมเริ่มเขียน SQL Migration Script และ Seed Data สำหรับข้อมูลใน 6B.md เลยหรือไม่ครับ?** (ข้อมูลในตารางค่อนข้างเยอะ การทำ Seed ไว้จะช่วยลดเวลา Admin ในการกรอกข้อมูลเริ่มต้นได้มากครับ)
|
||||
|
||||
จาก แผนการดำเนินการ (Action Plan): Database Migration และ Seed Data, ผมได้อัพเดท Basic data ข้อ 5. Data files ให้แล้ว, ช่วย review และ ปรับปรุง 4_Data_Dictionary_V1_4_3.md ,
|
||||
|
||||
เตรียม Backend Implementation, Admin Panel
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### **Phase 2: High-Integrity Data & File Management (สัปดาห์ที่ 4)**
|
||||
|
||||
* **[ ] T2.3 DocumentNumberingModule - Token-Based & Double-Lock** (Updated)
|
||||
* [ ] Update Entity: `DocumentNumberCounter` (Add `discipline_id` to PK)
|
||||
* [ ] Implement Token Parser & Replacer Logic (`{DISCIPLINE}`, `{SUBTYPE_NUM}`)
|
||||
* [ ] Update `generateNextNumber` to handle optional keys (Discipline/SubType)
|
||||
* [ ] **Deliverable:** Flexible Numbering System
|
||||
|
||||
* **[ ] T2.6 MasterModule - Advanced Data (Req 6B)** (New)
|
||||
* [ ] Update Entities: `Discipline`, `CorrespondenceSubType`
|
||||
* [ ] Create Services/Controllers for CRUD Operations (Admin Panel Support)
|
||||
* [ ] Implement Seeding Logic for initial 6B data
|
||||
* [ ] **Deliverable:** API for managing Disciplines and Sub-types
|
||||
* [ ] **Dependencies:** T1.1, T0.3
|
||||
-188
@@ -1,188 +0,0 @@
|
||||
# Special requirements for document-numbering
|
||||
การใช้งานจริงต้องการความยืดหยุ่นสูง สำหรับ ระบบ document-numbering ดังนี้
|
||||
|
||||
## 1. ต้องให้ admin สามารถกำหนดรูปแบบในถายหลังได้
|
||||
## 2. มีรูปแบบเริ่มต้นดังนี้
|
||||
* 2.1 สำหรับ correspondence ทั่วไป
|
||||
* ใช้รูปแบบ [organizations.organization_code]-[organizations.organization_code]-[sequence]-[year]
|
||||
* **_ตัวอย่าง: คคง.-ผรม.2-0123-2568_**
|
||||
* 2.2 สำหรับ correspondence type = transmittal
|
||||
* ใช้รูปแบบ [organizations.organization_code]-[organizations.organization_code]-[codecorrespondence_sub_types.sub_type_number]-[seq]-[year]
|
||||
* **_ตัวอย่าง: คคง.-สคฉ.3-22-0123-2568_**
|
||||
* 2.3 สำหรับ correspondence type = rfi
|
||||
* ใช้รูปแบบ [contrcts.contract_code]-[correspondences_types.type_code]-[disciplines_code]-[seq]-[revision]
|
||||
* **_ตัวอย่าง: LCBP3-C2-RFI-TER-2345-A_**
|
||||
* 2.4 สำหรับ rfa ใช้แบบเลขแยกกัน
|
||||
* ใช้รูปแบบ [contrcts.contract_code]-[correspondences_types.type_code]-[disciplines_code]-[rfa_types.type_code]-[seq]-[revision]
|
||||
* **_ตัวอย่าง: LCBP3-C1-RFA-TER-MAT-1234-A_**
|
||||
|
||||
## ตาราง correspondence_sub_types
|
||||
|
||||
| id | correspondence_types.type_code | sub_type_code | sub_type_name | sub_type_number |
|
||||
| --- | ------------------------------ | ------------- | -------------- | --------------- |
|
||||
| 1 | RFA | MAT | Material Approval | 11 |
|
||||
| 2 | RFA | SHP | Shop Drawing Submittal | 12 |
|
||||
| 3 | RFA | DWG | Document Approval | 13 |
|
||||
| 4 | RFA | MET | Engineering Document Submittal | 14 |
|
||||
| 5 | RFA | MAT | Material Approval | 21 |
|
||||
| 6 | RFA | SHP | Shop Drawing Submittal | 22 |
|
||||
| 7 | RFA | DWG | Document Approval | 23 |
|
||||
| 8 | RFA | MET | Engineering Document Submittal | 24 |
|
||||
| 9 | RFA | MAT | Material Approval | 31 |
|
||||
| 10 | RFA | SHP | Shop Drawing Submittal | 32 |
|
||||
| 11 | RFA | DWG | Document Approval | 33 |
|
||||
| 12 | RFA | MET | Engineering Document Submittal | 34 |
|
||||
| 13 | RFA | MAT | Material Approval | 41 |
|
||||
| 14 | RFA | SHP | Shop Drawing Submittal | 42 |
|
||||
| 15 | RFA | DWG | Document Approval | 43 |
|
||||
| 16 | RFA | MET | Engineering Document Submittal | 44 |
|
||||
|
||||
## ตาราง disciplines
|
||||
|
||||
| contract_code | code | code_name_th | code_name_en |
|
||||
|---------------|------|---------------------------------------|--------------------------------------------|
|
||||
| LCBP3-C1 | GEN | งานบริหารโครงการ | General Management |
|
||||
| LCBP3-C1 | COD | สัญญาและข้อโต้แย้ง | Contracting |
|
||||
| LCBP3-C1 | QSB | สำรวจปริมาณและควบคุมงบประมาณ | Quantity Survey and Budget Control |
|
||||
| LCBP3-C1 | PPG | บริหารแผนและความก้าวหน้า | Plan and Progress Management |
|
||||
| LCBP3-C1 | PRC | งานจัดซื้อ | Procurement |
|
||||
| LCBP3-C1 | SUB | ผู้รับเหมาช่วง | Subcontractor |
|
||||
| LCBP3-C1 | ODC | สำนักงาน-ควบคุมเอกสาร | Operation Docment Control |
|
||||
| LCBP3-C1 | LAW | กฎหมาย | Law |
|
||||
| LCBP3-C1 | TRF | จราจร | Traffic |
|
||||
| LCBP3-C1 | BIM | BIM | Building information modeling |
|
||||
| LCBP3-C1 | SRV | งานสำรวจ | Survey |
|
||||
| LCBP3-C1 | SFT | ความปลอดภัย | Safety |
|
||||
| LCBP3-C1 | BST | งานโครงสร้างอาคาร | Building Structure Work |
|
||||
| LCBP3-C1 | TEM | งานชั่วคราว | Temporary Work |
|
||||
| LCBP3-C1 | UTL | งานระบบสาธารณูปโภค | Utility |
|
||||
| LCBP3-C1 | EPW | งานระบบไฟฟ้า | Electrical Power Work |
|
||||
| LCBP3-C1 | ECM | งานระบบไฟฟ้าสื่อสาร | Electrical Communication Work |
|
||||
| LCBP3-C1 | ENV | สิ่งแวดล้อม | Environment |
|
||||
| LCBP3-C1 | AQV | คุณภาพอากาศและความสั่นสะเทือน | Air quality and vibration |
|
||||
| LCBP3-C1 | WAB | คุณภาพน้ำและชีววิทยาทางน้ำ | Water quality and Aquatic biology |
|
||||
| LCBP3-C1 | ONS | วิศวกรรมชายฝั่ง | Onshore Engineer Work |
|
||||
| LCBP3-C1 | PPR | มวลชนสัมพันธ์และการประชาสัมพันธ์ | Public Relations |
|
||||
| LCBP3-C1 | OSW | งานก่อสร้างงานทางทะเล | Offshore Work |
|
||||
| LCBP3-C1 | DRE | งานขุดและถมทะเล | Dredging and Reclamation |
|
||||
| LCBP3-C1 | REV | งานคันหินล้อมพื้นที่ถมทะเล | Revetment |
|
||||
| LCBP3-C1 | BRW | งานเขื่อนกันคลื่น | Breakwater |
|
||||
| LCBP3-C1 | SOI | ปรับปรุงคุณภาพดิน | Soil Improvement |
|
||||
| LCBP3-C1 | BLC | งานปรับปรุงคลองบางละมุง | Bang Lamung Canal Bank Protection |
|
||||
| LCBP3-C1 | FUP | งานประตูระบายน้ำและท่อลอด | Floodgate & Under Ground Piping Works |
|
||||
| LCBP3-C1 | SWP | งานอาคารควบคุมสถานีสูบน้ำทะเล | Sea Water Pumping Station Control BuilDing |
|
||||
| LCBP3-C1 | NAV | งานติดตั้งเครื่องหมายช่วงการเดินเรือ | Navigations Aids |
|
||||
| LCBP3-C1 | GEO | งานด้านธรณีเทคนิค | Geotechnical |
|
||||
| LCBP3-C1 | CRW | งานด้านโยธา - Rock Works | Civil-Rock work |
|
||||
| LCBP3-C1 | DVR | ทีมนักประดาน้ำ | Dive Work |
|
||||
| LCBP3-C1 | MTS | งานทดสอบวัสดุและธรณีเทคนิค | Materials and Geotechnical Testing |
|
||||
| LCBP3-C1 | OTH | อื่นๆ | Other |
|
||||
| LCBP3-C2 | GEN | งานบริหารโครงการ | Project Management |
|
||||
| LCBP3-C2 | COD | สัญญาและข้อโต้แย้ง | Contracts and arguments |
|
||||
| LCBP3-C2 | QSB | สำรวจปริมาณและควบคุมงบประมาณ | Survey the quantity and control the budget |
|
||||
| LCBP3-C2 | PPM | บริหารแผนและความก้าวหน้า | Plan Management & Progress |
|
||||
| LCBP3-C2 | ODC | สำนักงาน-ควบคุมเอกสาร | Document Control Office |
|
||||
| LCBP3-C2 | LAW | กฎหมาย | Law |
|
||||
| LCBP3-C2 | TRF | จราจร | Traffic |
|
||||
| LCBP3-C2 | BIM | Building Information Modeling | Building Information Modeling |
|
||||
| LCBP3-C2 | SRV | งานสำรวจ | Survey |
|
||||
| LCBP3-C2 | SFT | ความปลอดภัย | Safety |
|
||||
| LCBP3-C2 | BST | งานโครงสร้างอาคาร | Building Structure |
|
||||
| LCBP3-C2 | UTL | งานะบบสาธารณูปโภค | Public Utilities |
|
||||
| LCBP3-C2 | EPW | งานระบบไฟฟ้า | Electrical Systems |
|
||||
| LCBP3-C2 | ECM | งานระบบไฟฟ้าสื่อสาร | Electrical Communication System |
|
||||
| LCBP3-C2 | ENV | สิ่งแวดล้อม | Environment |
|
||||
| LCBP3-C2 | AQV | คุณภาพอากาศและความสั่นสะเทือน | Air Quality and Vibration |
|
||||
| LCBP3-C2 | WAB | คุณภาพน้ำและชีววิทยาทางน้ำ | Water Quality and Aquatic Biology |
|
||||
| LCBP3-C2 | ONS | วิศวกรรมชายฝั่ง | Coastal Engineering |
|
||||
| LCBP3-C2 | PPR | มวลชนสัมพันธ์และประชาสัมพันธ์ | Mass Relations and Public Relations |
|
||||
| LCBP3-C2 | OFW | งานก่อสร้างทางทะเล | Marine Construction |
|
||||
| LCBP3-C2 | EXR | งานขุดและถมทะเล | Excavation and reclamation |
|
||||
| LCBP3-C2 | GEO | งานด้านธรณีเทคนิค | Geotechnical work |
|
||||
| LCBP3-C2 | CRW | งานด้านโยธา - Rock Works | Civil Works - Rock Works |
|
||||
| LCBP3-C2 | DVW | ทีมนักประดาน้ำ | Team of Divers |
|
||||
| LCBP3-C2 | MTT | งานทดสอบวัสดุ | Materials Testing |
|
||||
| LCBP3-C2 | ARC | งานสถาปัตยกรรม | Architecture |
|
||||
| LCBP3-C2 | STR | งานโครงสร้าง | Structural work |
|
||||
| LCBP3-C2 | SAN | งานระบบสุขาภิบาล | Sanitation System |
|
||||
| LCBP3-C2 | DRA | งานระบบระบายน้ำ | Drainage system work |
|
||||
| LCBP3-C2 | TER | งานท่าเทียบเรือ | Wharf work |
|
||||
| LCBP3-C2 | BUD | งานอาคาร | Building |
|
||||
| LCBP3-C2 | ROW | งานถนนและสะพาน | Road and Bridge Work |
|
||||
| LCBP3-C2 | MEC | งานเคริองกล | Mechanical work |
|
||||
| LCBP3-C2 | OTH | อื่น ๆ | Others |
|
||||
|
||||
## ตาราง doccument_types
|
||||
|
||||
| contract_code | code | name_en | name_th |
|
||||
|---------------|------|----------------------------------------------|----------------------------------------------|
|
||||
| LCBP3-C1 | ADW | As Built Drawing | แบบร่างหลังการก่อสร้าง |
|
||||
| LCBP3-C1 | BC | Box culvert | ท่อระบายน้ํารูปกล่อง |
|
||||
| LCBP3-C1 | BM | Benchmark | หมุดหลักฐาน |
|
||||
| LCBP3-C1 | CER | Certificates | ใบรับรอง |
|
||||
| LCBP3-C1 | CN | Canal Drainage | ระบบระบายน้ําในคลอง |
|
||||
| LCBP3-C1 | CON | Contract | สัญญา |
|
||||
| LCBP3-C1 | DDS | Design Data Submission | นำส่งข้อมูลการออกแบบ |
|
||||
| LCBP3-C1 | DDW | Draft Drawing | แบบร่าง |
|
||||
| LCBP3-C1 | DRW | Drawings (All Types) | แบบก่อสร้าง |
|
||||
| LCBP3-C1 | DSN | Design/Calculation/Manual (All Stages) | ออกแบบ / คำนวณ / คู่มือ |
|
||||
| LCBP3-C1 | GEN | General | ทั่วไป |
|
||||
| LCBP3-C1 | ICR | Incident Report | รายงานการเกิดอุบัติเหตุและการบาดเจ็บ |
|
||||
| LCBP3-C1 | INS | Insurances/Bond/Guarantee | การประกัน / พันธบัตร / การค้ำประกัน |
|
||||
| LCBP3-C1 | INS | Inspection/Audit/Surveillance Report | รายงานการตรวจสอบ / การตรวจสอบ / รายงานการเฝ้าระวัง |
|
||||
| LCBP3-C1 | ITP | Inspection and Test Plan | แผนการตรวจสอบและทดสอบ |
|
||||
| LCBP3-C1 | JSA | Jobs Alalysis | รายงานการวิเคราะห์ความปลอดภัย |
|
||||
| LCBP3-C1 | MAN | Manual | คู่มือ |
|
||||
| LCBP3-C1 | MAT | Materials/Equipment/Plant | วัสดุ / อุปกรณ์ / โรงงาน |
|
||||
| LCBP3-C1 | MOM | Minute of Meeting | รายงานการประชุม |
|
||||
| LCBP3-C1 | MPR | Monthly Progress Report | รายงานความคืบหน้าประจำเดือน |
|
||||
| LCBP3-C1 | MST | Method Statement for Construction/Installation| ขั้นตอนการก่อสร้าง / ติดตั้ง |
|
||||
| LCBP3-C1 | NDS | Non-Design Data Submission | นำส่งข้อมูลที่ไม่เกี่ยวข้องกับการออกแบบ |
|
||||
| LCBP3-C1 | PMA | Payment/Invoice/Retention/Estimate | การชำระเงิน / ใบแจ้งหนี้ / ประกันผลงาน / ประมาณการ |
|
||||
| LCBP3-C1 | PRD | Procedure | ระเบียบปฏิบัติ |
|
||||
| LCBP3-C1 | PRG | Progress of Construc | ความคืบหน้าของการก่อสร้าง / ภาพถ่าย / วิดีโอ |
|
||||
| LCBP3-C1 | QMS | Quality Document (Plan//Work Instruction) | เอกสารด้านคุณภาพ (โรงงาน / ข้อแนะนำในการทำงาน) |
|
||||
| LCBP3-C1 | RPT | Report | รายงาน |
|
||||
| LCBP3-C1 | SAR | Semi Annual Report | รายงานประจำหกเดือน |
|
||||
| LCBP3-C1 | SCH | Schedule and Program | แผนงาน |
|
||||
| LCBP3-C1 | SDW | Shop Drawing | แบบขยายรายละเอียด |
|
||||
| LCBP3-C1 | SI | Soil Investigation | การตรวจสอบดิน |
|
||||
| LCBP3-C1 | SPE | Specification | ข้อกำหนด |
|
||||
| LCBP3-C1 | TNR | Training report | รายงานการฝึกปฏิบัติ |
|
||||
| LCBP3-C1 | UC | Underground Constructon | โครงสร้างใต้ดิน |
|
||||
| LCBP3-C1 | VEN | Vendor | ผู้ขาย |
|
||||
| LCBP3-C1 | VRO | Variation Request/Instruction/Order | คำขอเปลี่ยนแปลง / ข้อเสนอแนะ / ข้อเรียกร้อง |
|
||||
| LCBP3-C1 | WTY | Warranty | การประกัน |
|
||||
| LCBP3-C2 | GEN | General | ทั่วไป |
|
||||
| LCBP3-C2 | CON | Contract | สัญญา |
|
||||
| LCBP3-C2 | INS | Insurances/Bond/Guarantee | การประกัน / พันธบัตร / การค้ำประกัน |
|
||||
| LCBP3-C2 | SCH | Schedule and Program | แผนงาน |
|
||||
| LCBP3-C2 | PMA | Payment/Invoice/Retention/Estimate | การชำระเงิน / ใบแจ้งหนี้ / ประกันผลงาน / ประมาณการ |
|
||||
| LCBP3-C2 | VRO | Variation Request/Instruction/Order | คำขอเปลี่ยนแปลง / ข้อเสนอแนะ / ข้อเรียกร้อง |
|
||||
| LCBP3-C2 | VEN | Vendor | ผู้ขาย |
|
||||
| LCBP3-C2 | WTY | Warranty | การประกัน |
|
||||
| LCBP3-C2 | DRW | Drawings (All Types) | แบบก่อสร้าง |
|
||||
| LCBP3-C2 | DDW | Draft Drawing | แบบร่าง |
|
||||
| LCBP3-C2 | SDW | Shop Drawing | แบบขยายรายละเอียด |
|
||||
| LCBP3-C2 | ADW | As Built Drawing | แบบร่างหลังการก่อสร้าง |
|
||||
| LCBP3-C2 | DDS | Design Data Submission | นำส่งข้อมูลการออกแบบ |
|
||||
| LCBP3-C2 | DSN | Design/Calculation/Manual (All Stages) | ออกแบบ / คำนวณ / คู่มือ |
|
||||
| LCBP3-C2 | NDS | Non-Design Data Submission | นำส่งข้อมูลที่ไม่เกี่ยวข้องกับการออกแบบ |
|
||||
| LCBP3-C2 | PRD | Procedure | ระเบียบปฏิบัติ |
|
||||
| LCBP3-C2 | MST | Method Statement for Construction/Installation| ขั้นตอนการก่อสร้าง / ติดตั้ง |
|
||||
| LCBP3-C2 | QMS | Quality Document (Plan//Work Instruction) | เอกสารด้านคุณภาพ (โรงงาน / ข้อแนะนำในการทำงาน) |
|
||||
| LCBP3-C2 | INS | Inspection/Audit/Surveillance Report | รายงานการตรวจสอบ / การตรวจสอบ / รายงานการเฝ้าระวัง |
|
||||
| LCBP3-C2 | ITP | Inspection and Test Plan | แผนการตรวจสอบและทดสอบ |
|
||||
| LCBP3-C2 | MAT | Materials/Equipment/Plant | วัสดุ / อุปกรณ์ / โรงงาน |
|
||||
| LCBP3-C2 | SPE | Specification | ข้อกำหนด |
|
||||
| LCBP3-C2 | MAN | Manual | คู่มือ |
|
||||
| LCBP3-C2 | CER | Certificates | ใบรับรอง |
|
||||
| LCBP3-C2 | SAR | Semi Annual Report | รายงานประจำหกเดือน |
|
||||
| LCBP3-C2 | JSA | Jobs Alalysis | รายงานการวิเคราะห์ความปลอดภัย |
|
||||
| LCBP3-C2 | MOM | Minute of Meeting | รายงานการประชุม |
|
||||
| LCBP3-C2 | MPR | Monthly Progress Report | รายงานความคืบหน้าประจำเดือน |
|
||||
| LCBP3-C2 | ICR | Incident Report | รายงานการเกิดอุบัติเหตุและการบาดเจ็บ |
|
||||
| LCBP3-C2 | PRG | Progress of Construc | ความคืบหน้าของการก่อสร้าง / ภาพถ่าย / วิดีโอ |
|
||||
| LCBP3-C2 | RPT | Report | รายงาน |
|
||||
| LCBP3-C2 | TNR | Training report
|
||||
|
||||
BIN
Binary file not shown.
Reference in New Issue
Block a user