251119:0100 update requirements
This commit is contained in:
763
Documnets/Project/0_Requirements_V1_4_2.md
Normal file
763
Documnets/Project/0_Requirements_V1_4_2.md
Normal file
@@ -0,0 +1,763 @@
|
||||
# 📝 **Documents Management System Version 1.4.2: Application Requirements Specification**
|
||||
|
||||
**สถานะ:** FINAL
|
||||
**วันที่:** 2025-11-19
|
||||
**อ้างอิงพื้นฐาน:** v1.4.1 และผลการ Review สถาปัตยกรรม
|
||||
**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.4, 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.4. การอ้างอิงและจัดกลุ่ม: การจัดการ 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.5. Workflow การอนุมัติ: ต้องรองรับกระบวนการอนุมัติที่ซับซ้อนและเป็นลำดับ เช่น
|
||||
- ส่งจาก Originator -> Organization 1 -> Organization 2 -> Organization 3 แล้วส่งผลกลับตามลำดับเดิม (โดยถ้า องกรณ์ใดใน Workflow ให้ส่งกลับ ก็สามารถส่งผลกลับตามลำดับเดิมโดยไม่ต้องรอให้ถึง องกรณืในลำดับถัดไป)
|
||||
- 3.5.6. การจัดการ: มีการจัดการอย่างน้อยดังนี้
|
||||
- สามารถกำหนดวันแล้วเสร็จ (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. ระบบต้องสามารถสร้างเลขที่เอกสาร (เช่น correspondence_number) ได้โดยอัตโนมัติ
|
||||
- 3.10.2. การนับเลข Running Number (SEQ) จะต้องนับแยกตาม Key ดังนี้: **โครงการ (Project)**, **องค์กรผู้ส่ง (Originator Organization)**, **ประเภทเอกสาร (Document Type)** และ **ปีปัจจุบัน (Year)**
|
||||
- 3.10.3. ผู้ดูแลระบบ (Admin) ต้องสามารถกำหนด "รูปแบบ" (Format Template) ของเลขที่เอกสารได้ (เช่น {ORG_CODE}-{TYPE_CODE}-{YEAR_SHORT}-{SEQ:4}) โดยกำหนดแยกตามโครงการและประเภทเอกสาร
|
||||
- 3.10.4. **กลไก:** ใช้ **Redis Distributed Lock** เป็นด่านแรก
|
||||
- 3.10.5. **Safety Net:** เพิ่ม **Optimistic Locking** (ตรวจสอบ Version/Last Number ใน DB ขณะ Update) เพื่อป้องกันกรณี Redis ล่ม หรือ Race Condition หลุดรอด
|
||||
- 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
|
||||
|
||||
## **🔐 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 DMS v1.4.2
|
||||
- **Version:** 1.4.2
|
||||
- **Date:** 2025-11-19
|
||||
- **Author:** System Architecture Team
|
||||
- **Status:** FINAL
|
||||
- **Classification:** Internal Technical Documentation
|
||||
- **Approved By:** System Architect Team
|
||||
|
||||
---
|
||||
|
||||
`End of Requirements Specification v1.4.2`
|
||||
File diff suppressed because it is too large
Load Diff
539
Documnets/Project/2_Backend_Plan_V1_4_2.md
Normal file
539
Documnets/Project/2_Backend_Plan_V1_4_2.md
Normal file
@@ -0,0 +1,539 @@
|
||||
# 📋 **แผนการพัฒนา Backend (NestJS) - LCBP3-DMS v1.4.2 (ฉบับปรับปรุง)**
|
||||
|
||||
**อ้างอิง:** Requirements v1.4.2 & FullStackJS Guidelines v1.4.2
|
||||
**จุดเน้นสำคัญ:** Concurrency Control, Data Integrity, Unified Workflow, Idempotency
|
||||
|
||||
-----
|
||||
|
||||
## 🎯 **ภาพรวมโครงการ**
|
||||
|
||||
พัฒนา 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.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
|
||||
|
||||
-----
|
||||
|
||||
## **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)
|
||||
- [ ] **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** |
|
||||
|
||||
-----
|
||||
|
||||
`End of Backend Development Plan v1.4.2 (ฉบับปรับปรุง)`
|
||||
982
Documnets/Project/3_Frontend_Plan_V1_4_2.md
Normal file
982
Documnets/Project/3_Frontend_Plan_V1_4_2.md
Normal file
@@ -0,0 +1,982 @@
|
||||
# 📋 **แผนการพัฒนา Frontend (Next.js) - LCBP3-DMS v1.4.2**
|
||||
|
||||
**อ้างอิง:** Requirements v1.4.2 & FullStackJS Guidelines v1.4.2
|
||||
**จุดเน้นสำคัญ:** Responsive Design, Dynamic Forms, Offline Support, Optimistic Updates
|
||||
|
||||
## 🎯 **ภาพรวมโครงการ**
|
||||
|
||||
พัฒนา Frontend สำหรับระบบบริหารจัดการเอกสารโครงการ (Document Management System) ที่มีความทันสมัย รองรับการทำงานบนอุปกรณ์ต่างๆ ได้อย่างสมบูรณ์ มีประสบการณ์ผู้ใช้ที่ราบรื่น และรองรับการทำงานแบบ Offline เบื้องต้น
|
||||
|
||||
---
|
||||
|
||||
## 📐 **สถาปัตยกรรมระบบ**
|
||||
|
||||
### **Technology Stack**
|
||||
|
||||
- **Framework:** Next.js 14+ (App Router, React 18, TypeScript, ESM)
|
||||
- **Styling:** Tailwind CSS + PostCSS
|
||||
- **UI Components:** shadcn/ui + Radix UI Primitives
|
||||
- **State Management:**
|
||||
- **Server State:** TanStack Query (React Query)
|
||||
- **Client State:** Zustand
|
||||
- **Form State:** React Hook Form + Zod
|
||||
- **API Client:** Axios (พร้อม Idempotency Interceptor)
|
||||
- **Authentication:** NextAuth.js (รองรับ JWT)
|
||||
- **File Upload:** Custom Hook + Drag & Drop
|
||||
- **Testing:**
|
||||
- **Unit/Integration:** Vitest + React Testing Library
|
||||
- **E2E:** Playwright
|
||||
- **Mocking:** MSW (Mock Service Worker)
|
||||
- **Development:**
|
||||
- **Package Manager:** pnpm
|
||||
- **Linting:** ESLint + Prettier
|
||||
- **Type Checking:** TypeScript Strict Mode
|
||||
|
||||
### **โครงสร้างโปรเจกต์**
|
||||
|
||||
```tree
|
||||
app/
|
||||
├── (auth)/
|
||||
│ ├── login/
|
||||
│ └── register/
|
||||
├── (dashboard)/
|
||||
│ ├── layout.tsx
|
||||
│ ├── page.tsx
|
||||
│ └── components/
|
||||
├── admin/
|
||||
│ ├── users/
|
||||
│ ├── roles/
|
||||
│ └── numbering-formats/
|
||||
├── correspondences/
|
||||
│ ├── page.tsx
|
||||
│ ├── [id]/
|
||||
│ └── new/
|
||||
├── rfas/
|
||||
│ ├── page.tsx
|
||||
│ ├── [id]/
|
||||
│ └── new/
|
||||
├── drawings/
|
||||
├── circulations/
|
||||
├── transmittals/
|
||||
├── search/
|
||||
└── profile/
|
||||
|
||||
components/
|
||||
├── ui/ # shadcn/ui components
|
||||
├── forms/ # Dynamic form components
|
||||
├── tables/ # Responsive data tables
|
||||
├── workflow/ # Workflow visualization
|
||||
├── file-upload/ # File upload with security
|
||||
├── notifications/ # Notification system
|
||||
└── layout/ # App layout components
|
||||
|
||||
lib/
|
||||
├── api/ # API clients & interceptors
|
||||
├── auth/ # Authentication utilities
|
||||
├── stores/ # Zustand stores
|
||||
├── hooks/ # Custom React hooks
|
||||
├── utils/ # Utility functions
|
||||
├── constants/ # App constants
|
||||
└── types/ # TypeScript type definitions
|
||||
|
||||
styles/
|
||||
├── globals.css
|
||||
└── components/
|
||||
|
||||
__tests__/
|
||||
├── unit/
|
||||
├── integration/
|
||||
└── e2e/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🗓️ **แผนการพัฒนาแบบ Phase-Based**
|
||||
|
||||
### **Dependency Diagram (ภาพรวม)**
|
||||
|
||||
```mermaid
|
||||
%% Phase 0: Foundation Setup
|
||||
subgraph Phase0 [Phase 0: Foundation & Configuration]
|
||||
F0_1[F0.1: Project Setup & Tooling]
|
||||
F0_2[F0.2: Design System & UI Components]
|
||||
F0_3[F0.3: API Client & Authentication]
|
||||
F0_4[F0.4: State Management Setup]
|
||||
end
|
||||
|
||||
%% Phase 1: Core Layout & Navigation
|
||||
subgraph Phase1 [Phase 1: Core Application Structure]
|
||||
F1_1[F1.1: Main Layout & Navigation]
|
||||
F1_2[F1.2: Authentication Pages]
|
||||
F1_3[F1.3: Dashboard & Landing]
|
||||
F1_4[F1.4: Responsive Design System]
|
||||
end
|
||||
|
||||
%% Phase 2: User Management & Profile
|
||||
subgraph Phase2 [Phase 2: User Management & Security]
|
||||
F2_1[F2.1: User Profile & Settings]
|
||||
F2_2[F2.2: Admin Panel - User Management]
|
||||
F2_3[F2.3: Admin Panel - Role Management]
|
||||
F2_4[F2.4: Permission Integration]
|
||||
end
|
||||
|
||||
%% Phase 3: Project & Organization Management
|
||||
subgraph Phase3 [Phase 3: Project Structure]
|
||||
F3_1[F3.1: Project Management UI]
|
||||
F3_2[F3.2: Organization Management]
|
||||
F3_3[F3.3: Contract Management]
|
||||
end
|
||||
|
||||
%% Phase 4: Correspondence Management
|
||||
subgraph Phase4 [Phase 4: Correspondence System]
|
||||
F4_1[F4.1: Correspondence List & Search]
|
||||
F4_2[F4.2: Correspondence Creation Form]
|
||||
F4_3[F4.3: Correspondence Detail View]
|
||||
F4_4[F4.4: File Upload Integration]
|
||||
end
|
||||
|
||||
%% Phase 5: Workflow & Routing System
|
||||
subgraph Phase5 [Phase 5: Workflow Management]
|
||||
F5_1[F5.1: Workflow Visualization Component]
|
||||
F5_2[F5.2: Routing Template Management]
|
||||
F5_3[F5.3: Workflow Step Actions]
|
||||
F5_4[F5.4: Real-time Status Updates]
|
||||
end
|
||||
|
||||
%% Phase 6: Drawing Management
|
||||
subgraph Phase6 [Phase 6: Drawing System]
|
||||
F6_1[F6.1: Contract Drawings Management]
|
||||
F6_2[F6.2: Shop Drawings Management]
|
||||
F6_3[F6.3: Drawing Revision System]
|
||||
F6_4[F6.4: Drawing References]
|
||||
end
|
||||
|
||||
%% Phase 7: RFA & Approval Workflows
|
||||
subgraph Phase7 [Phase 7: RFA System]
|
||||
F7_1[F7.1: RFA List & Dashboard]
|
||||
F7_2[F7.2: RFA Creation with Dynamic Forms]
|
||||
F7_3[F7.3: RFA Workflow Integration]
|
||||
F7_4[F7.4: RFA Approval Interface]
|
||||
end
|
||||
|
||||
%% Phase 8: Circulation & Internal Routing
|
||||
subgraph Phase8 [Phase 8: Internal Workflows]
|
||||
F8_1[F8.1: Circulation Management]
|
||||
F8_2[F8.2: Task Assignment Interface]
|
||||
F8_3[F8.3: Internal Approval Flows]
|
||||
end
|
||||
|
||||
%% Phase 9: Advanced Features
|
||||
subgraph Phase9 [Phase 9: Advanced Features]
|
||||
F9_1[F9.1: Advanced Search Interface]
|
||||
F9_2[F9.2: Notification System]
|
||||
F9_3[F9.3: Reporting & Analytics]
|
||||
F9_4[F9.4: Mobile Optimization]
|
||||
end
|
||||
|
||||
%% Phase 10: Testing & Optimization
|
||||
subgraph Phase10 [Phase 10: Testing & Polish]
|
||||
F10_1[F10.1: Comprehensive Testing]
|
||||
F10_2[F10.2: Performance Optimization]
|
||||
F10_3[F10.3: Security Hardening]
|
||||
F10_4[F10.4: Documentation]
|
||||
end
|
||||
|
||||
%% Dependencies
|
||||
F0_1 --> F0_2
|
||||
F0_1 --> F0_3
|
||||
F0_1 --> F0_4
|
||||
|
||||
F0_2 --> F1_1
|
||||
F0_3 --> F1_1
|
||||
F0_4 --> F1_1
|
||||
F1_1 --> F1_2
|
||||
F1_1 --> F1_3
|
||||
F1_1 --> F1_4
|
||||
|
||||
F1_1 --> F2_1
|
||||
F1_3 --> F2_1
|
||||
F0_3 --> F2_1
|
||||
F2_1 --> F2_2
|
||||
F2_2 --> F2_3
|
||||
F2_3 --> F2_4
|
||||
|
||||
F1_1 --> F3_1
|
||||
F2_4 --> F3_1
|
||||
F3_1 --> F3_2
|
||||
F3_2 --> F3_3
|
||||
|
||||
F1_1 --> F4_1
|
||||
F3_1 --> F4_1
|
||||
F4_1 --> F4_2
|
||||
F4_2 --> F4_3
|
||||
F4_2 --> F4_4
|
||||
|
||||
F4_1 --> F5_1
|
||||
F4_2 --> F5_2
|
||||
F4_3 --> F5_3
|
||||
F5_1 --> F5_4
|
||||
|
||||
F3_1 --> F6_1
|
||||
F4_4 --> F6_1
|
||||
F6_1 --> F6_2
|
||||
F6_2 --> F6_3
|
||||
F6_3 --> F6_4
|
||||
|
||||
F4_1 --> F7_1
|
||||
F5_1 --> F7_1
|
||||
F6_2 --> F7_1
|
||||
F7_1 --> F7_2
|
||||
F7_2 --> F7_3
|
||||
F7_3 --> F7_4
|
||||
|
||||
F4_1 --> F8_1
|
||||
F5_3 --> F8_1
|
||||
F8_1 --> F8_2
|
||||
F8_2 --> F8_3
|
||||
|
||||
F4_1 --> F9_1
|
||||
F7_1 --> F9_1
|
||||
F1_3 --> F9_2
|
||||
F5_4 --> F9_2
|
||||
F1_3 --> F9_3
|
||||
F1_4 --> F9_4
|
||||
|
||||
F1_1 --> F10_1
|
||||
F4_1 --> F10_1
|
||||
F7_1 --> F10_1
|
||||
F10_1 --> F10_2
|
||||
F10_2 --> F10_3
|
||||
F10_3 --> F10_4
|
||||
```
|
||||
|
||||
## **Phase 0: Foundation & Configuration (สัปดาห์ที่ 1)**
|
||||
|
||||
**Milestone:** โครงสร้างพื้นฐานพร้อม รองรับ Development Workflow ที่มีประสิทธิภาพ
|
||||
|
||||
### **Phase 0: Tasks**
|
||||
|
||||
- **[ ] F0.1 Project Setup & Tooling**
|
||||
- [ ] Initialize Next.js 14+ project with TypeScript
|
||||
- [ ] Configure pnpm workspace
|
||||
- [ ] Setup ESLint, Prettier, and pre-commit hooks
|
||||
- [ ] Configure Tailwind CSS with PostCSS
|
||||
- [ ] Setup shadcn/ui components
|
||||
- [ ] Configure absolute imports and path aliases
|
||||
- [ ] **Deliverable:** Development environment ready
|
||||
- [ ] **Dependencies:** None
|
||||
|
||||
- **[ ] F0.2 Design System & UI Components**
|
||||
- [ ] Setup color palette and design tokens
|
||||
- [ ] Create responsive design breakpoints
|
||||
- [ ] Implement core shadcn/ui components:
|
||||
- [ ] Button, Input, Label, Form
|
||||
- [ ] Card, Table, Badge
|
||||
- [ ] Dialog, Dropdown, Select
|
||||
- [ ] Tabs, Accordion
|
||||
- [ ] Create custom design system components:
|
||||
- [ ] DataTable (responsive)
|
||||
- [ ] FileUpload zone
|
||||
- [ ] Workflow visualization
|
||||
- [ ] **Deliverable:** Consistent UI component library
|
||||
- [ ] **Dependencies:** F0.1
|
||||
|
||||
- **[ ] F0.3 API Client & Authentication**
|
||||
- [ ] Setup Axios client with interceptors:
|
||||
- [ ] Idempotency-Key header injection
|
||||
- [ ] Authentication token management
|
||||
- [ ] Error handling and retry logic
|
||||
- [ ] Configure NextAuth.js for JWT authentication
|
||||
- [ ] Create auth hooks (useAuth, usePermissions)
|
||||
- [ ] Setup API route handlers for auth callbacks
|
||||
- [ ] **Security:** Implement secure token storage
|
||||
- [ ] **Deliverable:** Secure API communication layer
|
||||
- [ ] **Dependencies:** F0.1
|
||||
|
||||
- **[ ] F0.4 State Management Setup**
|
||||
- [ ] Configure TanStack Query for server state:
|
||||
- [ ] Query client setup
|
||||
- [ ] Default configurations
|
||||
- [ ] Error boundaries
|
||||
- [ ] Create Zustand stores:
|
||||
- [ ] Auth store (user, permissions)
|
||||
- [ ] UI store (theme, sidebar state)
|
||||
- [ ] Draft store (form auto-save)
|
||||
- [ ] Setup React Hook Form with Zod integration
|
||||
- [ ] Create form validation schemas
|
||||
- [ ] **Deliverable:** Robust state management system
|
||||
- [ ] **Dependencies:** F0.1, F0.3
|
||||
|
||||
### **Phase 0: Testing - Foundation**
|
||||
|
||||
#### **F0.T1 Component Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** Core UI components (Button, Input, Card)
|
||||
- [ ] **Integration Tests:** Form validation, API client interceptors
|
||||
- [ ] **Visual Tests:** Component styling and responsive behavior
|
||||
|
||||
#### **F0.T2 Authentication Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** Auth hooks, token management
|
||||
- [ ] **Integration Tests:** Login/logout flow, permission checks
|
||||
- [ ] **Security Tests:** Token security, API authentication
|
||||
|
||||
---
|
||||
|
||||
## **Phase 1: Core Application Structure (สัปดาห์ที่ 2)**
|
||||
|
||||
**Milestone:** Layout หลักพร้อมใช้งาน การนำทางและ Authentication ทำงานได้
|
||||
|
||||
### **Phase 1: Tasks**
|
||||
|
||||
- **[ ] F1.1 Main Layout & Navigation**
|
||||
- [ ] Create App Shell layout:
|
||||
- [ ] Navbar with user menu and notifications
|
||||
- [ ] Collapsible sidebar with navigation
|
||||
- [ ] Main content area with responsive design
|
||||
- [ ] Implement navigation menu structure:
|
||||
- [ ] Dashboard, Correspondences, RFAs, Drawings, etc.
|
||||
- [ ] Dynamic menu based on user permissions
|
||||
- [ ] Create breadcrumb navigation component
|
||||
- [ ] Implement mobile-responsive sidebar (drawer)
|
||||
- [ ] Maintenance Mode Integration:
|
||||
- [ ] Implement a Global Middleware/Wrapper ที่ตรวจสอบสถานะ Maintenance Mode ผ่าน API/Service ก่อนการ Render หน้า หากสถานะเป็น true ให้ Redirect ผู้ใช้ (ยกเว้น Admin) ไปยังหน้า /maintenance ทันที เพื่อให้สอดคล้องกับ Logic ของ Backend.
|
||||
- [ ] **Accessibility:** Ensure keyboard navigation and screen reader support
|
||||
- [ ] **Deliverable:** Fully functional application layout
|
||||
- [ ] **Dependencies:** F0.2, F0.3
|
||||
|
||||
- **[ ] F1.2 Authentication Pages**
|
||||
- [ ] Create login page with form validation
|
||||
- [ ] Implement forgot password flow
|
||||
- [ ] Create registration page (admin-only)
|
||||
- [ ] Setup protected route middleware
|
||||
- [ ] Implement route-based permission checks
|
||||
- [ ] **Security:** Rate limiting on auth attempts, secure password requirements
|
||||
- [ ] **Deliverable:** Complete authentication flow
|
||||
- [ ] **Dependencies:** F0.3, F1.1
|
||||
|
||||
- **[ ] F1.3 Dashboard & Landing**
|
||||
- [ ] Create public landing page for non-authenticated users
|
||||
- [ ] Implement main dashboard with:
|
||||
- [ ] KPI cards (document counts, pending tasks)
|
||||
- [ ] "My Tasks" table from v_user_tasks
|
||||
- [ ] Recent activity feed
|
||||
- [ ] Security metrics display
|
||||
- [ ] Create dashboard widgets system
|
||||
- [ ] Implement data fetching with TanStack Query
|
||||
- [ ] **Performance:** Optimize dashboard data loading
|
||||
- [ ] **Deliverable:** Functional dashboard with real data
|
||||
- [ ] **Dependencies:** F0.4, F1.1
|
||||
|
||||
- **[ ] F1.4 Responsive Design System**
|
||||
- [ ] Implement mobile-first responsive design
|
||||
- [ ] Create card view components for mobile tables
|
||||
- [ ] Setup touch-friendly interactions
|
||||
- [ ] Optimize images and assets for mobile
|
||||
- [ ] Test across multiple device sizes
|
||||
- [ ] **UX:** Ensure seamless mobile experience
|
||||
- [ ] **Deliverable:** Fully responsive application
|
||||
- [ ] **Dependencies:** F0.2, F1.1
|
||||
|
||||
### **Phase 1: Testing - Core Structure**
|
||||
|
||||
#### **F1.T1 Layout Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** Navigation components, layout responsiveness
|
||||
- [ ] **Integration Tests:** Route protection, permission-based navigation
|
||||
- [ ] **E2E Tests:** Complete user navigation flow
|
||||
|
||||
#### **F1.T2 Dashboard Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** Dashboard components, data formatting
|
||||
- [ ] **Integration Tests:** Data fetching and display, real-time updates
|
||||
- [ ] **Performance Tests:** Dashboard loading performance
|
||||
|
||||
---
|
||||
|
||||
## **Phase 2: User Management & Security (สัปดาห์ที่ 3)**
|
||||
|
||||
**Milestone:** การจัดการผู้ใช้และสิทธิ์แบบสมบูรณ์
|
||||
|
||||
### **Phase 2: Tasks**
|
||||
|
||||
- **[ ] F2.1 User Profile & Settings**
|
||||
- [ ] Create user profile page:
|
||||
- [ ] Personal information display/edit
|
||||
- [ ] Password change functionality
|
||||
- [ ] Notification preferences
|
||||
- [ ] Implement profile picture upload
|
||||
- [ ] Create user settings page
|
||||
- [ ] **Security:** Secure password change with current password verification
|
||||
- [ ] **Deliverable:** Complete user self-service management
|
||||
- [ ] **Dependencies:** F1.1, F0.4
|
||||
|
||||
- **[ ] F2.2 Admin Panel - User Management**
|
||||
- [ ] Create user list with search and filters
|
||||
- [ ] Implement user creation form
|
||||
- [ ] Create user edit interface
|
||||
- [ ] Implement bulk user operations
|
||||
- [ ] Add user activity tracking display
|
||||
- [ ] **Security:** Admin-only access enforcement
|
||||
- [ ] **Deliverable:** Comprehensive user management interface
|
||||
- [ ] **Dependencies:** F1.1, F2.1
|
||||
|
||||
- **[ ] F2.3 Admin Panel - Role Management**
|
||||
- [ ] Create role list and management interface
|
||||
- [ ] Implement role creation and editing
|
||||
- [ ] Create permission assignment interface
|
||||
- [ ] Implement role-based access control visualization
|
||||
- [ ] Add role usage statistics
|
||||
- [ ] **Security:** Permission hierarchy enforcement
|
||||
- [ ] **Deliverable:** Complete RBAC management system
|
||||
- [ ] **Dependencies:** F2.2
|
||||
|
||||
- **[ ] F2.4 Permission Integration**
|
||||
- [ ] Implement CASL ability integration
|
||||
- [ ] Create permission-based UI components:
|
||||
- [ ] ProtectedButton, ProtectedLink
|
||||
- [ ] Conditional rendering based on permissions
|
||||
- [ ] Setup real-time permission updates
|
||||
- [ ] Implement permission debugging tools
|
||||
- [ ] **Security:** Frontend-backend permission consistency
|
||||
- [ ] **Deliverable:** Seamless permission enforcement throughout app
|
||||
- [ ] **Dependencies:** F0.3, F2.3
|
||||
|
||||
### **Phase 2: Testing - User Management**
|
||||
|
||||
#### **F2.T1 User Management Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** User CRUD operations, form validation
|
||||
- [ ] **Integration Tests:** User-role assignment, permission propagation
|
||||
- [ ] **Security Tests:** Permission escalation attempts, admin access control
|
||||
|
||||
#### **F2.T2 RBAC Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** Permission checks, role validation
|
||||
- [ ] **Integration Tests:** Multi-level permission enforcement, UI element protection
|
||||
- [ ] **E2E Tests:** Complete role-based workflow testing
|
||||
|
||||
---
|
||||
|
||||
## **Phase 3: Project Structure (สัปดาห์ที่ 4)**
|
||||
|
||||
**Milestone:** การจัดการโครงสร้างโปรเจกต์และองค์กร
|
||||
|
||||
### **Phase 3: Tasks**
|
||||
|
||||
- **[ ] F3.1 Project Management UI**
|
||||
- [ ] Create project list with search and filters
|
||||
- [ ] Implement project creation and editing
|
||||
- [ ] Create project detail view
|
||||
- [ ] Implement project dashboard with statistics
|
||||
- [ ] Add project member management
|
||||
- [ ] **UX:** Intuitive project navigation and management
|
||||
- [ ] **Deliverable:** Complete project management interface
|
||||
- [ ] **Dependencies:** F1.1, F2.4
|
||||
|
||||
- **[ ] F3.2 Organization Management**
|
||||
- [ ] Create organization list and management
|
||||
- [ ] Implement organization creation and editing
|
||||
- [ ] Create organization detail view
|
||||
- [ ] Add organization user management
|
||||
- [ ] Implement organization hierarchy visualization
|
||||
- [ ] **Business Logic:** Proper organization-project relationships
|
||||
- [ ] **Deliverable:** Comprehensive organization management
|
||||
- [ ] **Dependencies:** F3.1
|
||||
|
||||
- **[ ] F3.3 Contract Management**
|
||||
- [ ] Create contract list within projects
|
||||
- [ ] Implement contract creation and editing
|
||||
- [ ] Create contract detail view
|
||||
- [ ] Add contract party management
|
||||
- [ ] Implement contract document associations
|
||||
- [ ] **Business Logic:** Contract-project-organization relationships
|
||||
- [ ] **Deliverable:** Complete contract management system
|
||||
- [ ] **Dependencies:** F3.1, F3.2
|
||||
|
||||
### **Phase 3: Testing - Project Structure**
|
||||
|
||||
#### **F3.T1 Project Management Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** Project CRUD operations, validation
|
||||
- [ ] **Integration Tests:** Project-organization relationships, member management
|
||||
- [ ] **Business Logic Tests:** Project hierarchy, access control
|
||||
|
||||
---
|
||||
|
||||
## **Phase 4: Correspondence System (สัปดาห์ที่ 5-6)**
|
||||
|
||||
**Milestone:** ระบบจัดการเอกสารโต้ตอบแบบสมบูรณ์
|
||||
|
||||
### **Phase 4: Tasks**
|
||||
|
||||
- **[ ] F4.1 Correspondence List & Search**
|
||||
- [ ] Create correspondence list with advanced filtering:
|
||||
- [ ] Filter by type, status, project, organization
|
||||
- [ ] Search by title, document number, content
|
||||
- [ ] Date range filtering
|
||||
- [ ] Implement responsive data table:
|
||||
- [ ] Desktop: Full table view
|
||||
- [ ] Mobile: Card view conversion
|
||||
- [ ] Add bulk operations (export, status change)
|
||||
- [ ] Implement real-time updates
|
||||
- [ ] **Performance:** Virtual scrolling for large datasets
|
||||
- [ ] **Deliverable:** High-performance correspondence listing
|
||||
- [ ] **Dependencies:** F1.1, F3.1
|
||||
|
||||
- **[ ] F4.2 Correspondence Creation Form**
|
||||
- [ ] Create dynamic form generator based on JSON schema
|
||||
- [ ] Implement form with multiple sections:
|
||||
- [ ] Basic information (type, title, recipients)
|
||||
- [ ] Content and details (JSON schema-based)
|
||||
- [ ] File attachments
|
||||
- [ ] Routing template selection
|
||||
- [ ] Add draft auto-save functionality
|
||||
- [ ] Implement form validation with Zod
|
||||
- [ ] **UX:** Intuitive form with progress indication
|
||||
- [ ] **Deliverable:** Flexible correspondence creation interface
|
||||
- [ ] **Dependencies:** F0.4, F4.1
|
||||
|
||||
- **[ ] F4.3 Correspondence Detail View**
|
||||
- [ ] Create comprehensive detail page:
|
||||
- [ ] Document header with metadata
|
||||
- [ ] Content display based on type
|
||||
- [ ] Revision history
|
||||
- [ ] Related documents
|
||||
- [ ] Workflow status visualization
|
||||
- [ ] Implement document actions:
|
||||
- [ ] Edit, withdraw, cancel (with permissions)
|
||||
- [ ] Download, print
|
||||
- [ ] Create related documents
|
||||
- [ ] Add comments and activity timeline
|
||||
- [ ] **UX:** Clean, readable document presentation
|
||||
- [ ] **Deliverable:** Complete document detail experience
|
||||
- [ ] **Dependencies:** F4.1, F4.2
|
||||
|
||||
- **[ ] F4.4 File Upload Integration**
|
||||
- [ ] Create drag-and-drop file upload component
|
||||
- [ ] Implement file type validation and preview
|
||||
- [ ] Add virus scan status indication
|
||||
- [ ] Create file management interface:
|
||||
- [ ] Mark files as main/supporting documents
|
||||
- [ ] Reorder and manage attachments
|
||||
- [ ] File security status display
|
||||
- [ ] Implement two-phase upload progress
|
||||
- [ ] **Security:** File type restrictions, size limits, virus scan integration
|
||||
- [ ] **Deliverable:** Secure and user-friendly file management
|
||||
- [ ] **Dependencies:** F0.2, F4.2
|
||||
|
||||
### **Phase 4: Testing - Correspondence System**
|
||||
|
||||
#### **F4.T1 Correspondence Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** Form validation, file upload components
|
||||
- [ ] **Integration Tests:** Complete document lifecycle, file attachment flow
|
||||
- [ ] **E2E Tests:** End-to-end correspondence creation and management
|
||||
|
||||
#### **F4.T2 File Upload Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** File validation, type checking
|
||||
- [ ] **Integration Tests:** Two-phase upload process, virus scan integration
|
||||
- [ ] **Security Tests:** Malicious file upload attempts, security feedback
|
||||
|
||||
---
|
||||
|
||||
## **Phase 5: Workflow Management (สัปดาห์ที่ 7)**
|
||||
|
||||
**Milestone:** ระบบ Visualization และจัดการ Workflow
|
||||
|
||||
### **Phase 5: Tasks**
|
||||
|
||||
- **[ ] F5.1 Workflow Visualization Component**
|
||||
- [ ] Create horizontal workflow progress visualization
|
||||
- [ ] Implement step status indicators (pending, active, completed, skipped)
|
||||
- [ ] Add due date and assignee information
|
||||
- [ ] Create interactive workflow diagram
|
||||
- [ ] Implement workflow history timeline
|
||||
- [ ] **UX:** Clear visual representation of complex workflows
|
||||
- [ ] **Deliverable:** Intuitive workflow visualization
|
||||
- [ ] **Dependencies:** F4.3
|
||||
|
||||
- **[ ] F5.2 Routing Template Management**
|
||||
- [ ] Create routing template list and editor
|
||||
- [ ] Implement drag-and-drop step configuration
|
||||
- [ ] Add step configuration (purpose, duration, assignee rules)
|
||||
- [ ] Create template preview functionality
|
||||
- [ ] Implement template versioning
|
||||
- [ ] **Business Logic:** Proper step sequencing and validation
|
||||
- [ ] **Deliverable:** Comprehensive routing template management
|
||||
- [ ] **Dependencies:** F3.1, F4.2
|
||||
|
||||
- **[ ] F5.3 Workflow Step Actions**
|
||||
- [ ] Create step action interface:
|
||||
- [ ] Approve, reject, request changes
|
||||
- [ ] Add comments and attachments
|
||||
- [ ] Forward to other users
|
||||
- [ ] Implement bulk step actions
|
||||
- [ ] Add action confirmation with reason required
|
||||
- [ ] Create step delegation functionality
|
||||
- [ ] **UX:** Streamlined step completion process
|
||||
- [ ] **Deliverable:** Efficient workflow step management
|
||||
- [ ] **Dependencies:** F5.1
|
||||
|
||||
- **[ ] F5.4 Real-time Status Updates**
|
||||
- [ ] Implement WebSocket connections for real-time updates
|
||||
- [ ] Create status change notifications
|
||||
- [ ] Add auto-refresh for workflow states
|
||||
- [ ] Implement optimistic updates for better UX
|
||||
- [ ] Create update history and audit trail
|
||||
- [ ] **Performance:** Efficient real-time data synchronization
|
||||
- [ ] **Deliverable:** Real-time workflow monitoring
|
||||
- [ ] **Dependencies:** F5.1, F9.2
|
||||
|
||||
### **Phase 5: Testing - Workflow Management**
|
||||
|
||||
#### **F5.T1 Workflow Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** Workflow visualization, step status logic
|
||||
- [ ] **Integration Tests:** Complete workflow execution, real-time updates
|
||||
- [ ] **E2E Tests:** Multi-step workflow with different user roles
|
||||
|
||||
---
|
||||
|
||||
## **Phase 6: Drawing System (สัปดาห์ที่ 8)**
|
||||
|
||||
**Milestone:** ระบบจัดการแบบแปลนแบบสมบูรณ์
|
||||
|
||||
### **Phase 6: Tasks**
|
||||
|
||||
- **[ ] F6.1 Contract Drawings Management**
|
||||
- [ ] Create contract drawing list with categorization
|
||||
- [ ] Implement drawing upload and metadata management
|
||||
- [ ] Create drawing preview and viewer
|
||||
- [ ] Add drawing version control
|
||||
- [ ] Implement drawing search and filtering
|
||||
- [ ] **UX:** Efficient drawing navigation and access
|
||||
- [ ] **Deliverable:** Comprehensive contract drawing management
|
||||
- [ ] **Dependencies:** F3.1, F4.4
|
||||
|
||||
- **[ ] F6.2 Shop Drawings Management**
|
||||
- [ ] Create shop drawing list with revision tracking
|
||||
- [ ] Implement shop drawing creation and revision system
|
||||
- [ ] Create drawing comparison interface
|
||||
- [ ] Add drawing approval status tracking
|
||||
- [ ] Implement bulk drawing operations
|
||||
- [ ] **Business Logic:** Proper revision control and approval workflows
|
||||
- [ ] **Deliverable:** Complete shop drawing management system
|
||||
- [ ] **Dependencies:** F6.1
|
||||
|
||||
- **[ ] F6.3 Drawing Revision System**
|
||||
- [ ] Create revision history interface
|
||||
- [ ] Implement revision comparison functionality
|
||||
- [ ] Add revision notes and change tracking
|
||||
- [ ] Create revision approval workflow
|
||||
- [ ] Implement revision rollback capability
|
||||
- [ ] **UX:** Clear visualization of changes between revisions
|
||||
- [ ] **Deliverable:** Robust drawing revision control
|
||||
- [ ] **Dependencies:** F6.2
|
||||
|
||||
- **[ ] F6.4 Drawing References**
|
||||
- [ ] Create drawing reference management
|
||||
- [ ] Implement cross-drawing references
|
||||
- [ ] Add reference validation and integrity checks
|
||||
- [ ] Create reference visualization
|
||||
- [ ] Implement reference impact analysis
|
||||
- [ ] **Business Logic:** Maintain reference integrity during changes
|
||||
- [ ] **Deliverable:** Comprehensive drawing reference system
|
||||
- [ ] **Dependencies:** F6.2, F6.3
|
||||
|
||||
### **Phase 6: Testing - Drawing System**
|
||||
|
||||
#### **F6.T1 Drawing Management Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** Drawing CRUD operations, revision logic
|
||||
- [ ] **Integration Tests:** Drawing approval workflows, reference management
|
||||
- [ ] **E2E Tests:** Complete drawing lifecycle with revisions
|
||||
|
||||
---
|
||||
|
||||
## **Phase 7: RFA System (สัปดาห์ที่ 9-10)**
|
||||
|
||||
**Milestone:** ระบบขออนุมัติแบบสมบูรณ์พร้อม Dynamic Forms
|
||||
|
||||
### **Phase 7: Tasks**
|
||||
|
||||
- **[ ] F7.1 RFA List & Dashboard**
|
||||
- [ ] Create RFA dashboard with status overview
|
||||
- [ ] Implement advanced RFA filtering and search
|
||||
- [ ] Create RFA calendar view for deadlines
|
||||
- [ ] Add RFA statistics and reporting
|
||||
- [ ] Implement RFA bulk operations
|
||||
- [ ] **UX:** Comprehensive RFA overview and management
|
||||
- [ ] **Deliverable:** Complete RFA dashboard and listing
|
||||
- [ ] **Dependencies:** F4.1, F5.1
|
||||
|
||||
- **[ ] F7.2 RFA Creation with Dynamic Forms**
|
||||
- [ ] Create RFA type-specific form generator
|
||||
- [ ] Implement dynamic form fields based on RFA type:
|
||||
- [ ] RFA_DWG: Shop drawing selection
|
||||
- [ ] RFA_DOC: Document specifications
|
||||
- [ ] RFA_MES: Method statement details
|
||||
- [ ] RFA_MAT: Material specifications
|
||||
- [ ] Add form validation with JSON schema
|
||||
- [ ] Implement form data persistence and recovery
|
||||
- [ ] **UX:** Intuitive form experience for complex RFA types
|
||||
- [ ] Dynamic Form & Schema Validation: สร้าง Component Dynamic Form Generator ที่:
|
||||
- [ ] Fetch Schema: ดึงโครงสร้าง JSON Schema ที่ถูกต้องตาม rfa_type จาก Backend (ตาราง json_schemas ที่สร้างใหม่) ก่อนการ Render Form.
|
||||
- [ ] Client-side Validation: Implement AJV (Another JSON Schema Validator) หรือไลบรารีที่เทียบเท่า เพื่อทำ Client-side Validation บนข้อมูล JSON ก่อนส่ง Submit.
|
||||
- [ ] Implement dynamic form fields based on RFA type: RFA_DWG, RFA_DOC, RFA_MES, RFA_MAT.
|
||||
- [ ] Add form data persistence and recovery.
|
||||
- [ ] **Deliverable:** Flexible RFA creation system
|
||||
- [ ] **Dependencies:** F4.2, F6.2
|
||||
|
||||
- **[ ] F7.3 RFA Workflow Integration**
|
||||
- [ ] Integrate RFA with unified workflow engine
|
||||
- [ ] Create RFA-specific workflow steps and actions
|
||||
- [ ] Implement RFA approval interface
|
||||
- [ ] Add RFA workflow history and tracking
|
||||
- [ ] Create RFA workflow templates
|
||||
- [ ] **Business Logic:** Proper RFA approval sequencing and validation
|
||||
- [ ] **Deliverable:** Seamless RFA workflow integration
|
||||
- [ ] **Dependencies:** F5.1, F7.2
|
||||
|
||||
- **[ ] F7.4 RFA Approval Interface**
|
||||
- [ ] Create RFA review and approval interface
|
||||
- [ ] Implement side-by-side document comparison
|
||||
- [ ] Add approval comments and attachments
|
||||
- [ ] Create conditional approval workflows
|
||||
- [ ] Implement approval delegation and escalation
|
||||
- [ ] **UX:** Efficient approval process for technical reviews
|
||||
- [ ] **Deliverable:** Comprehensive RFA approval system
|
||||
- [ ] **Dependencies:** F7.1, F7.3
|
||||
|
||||
### **Phase 7: Testing - RFA System**
|
||||
|
||||
#### **F7.T1 RFA Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** RFA form generation, validation logic
|
||||
- [ ] **Integration Tests:** Complete RFA lifecycle, workflow integration
|
||||
- [ ] **E2E Tests:** Multi-type RFA creation and approval workflows
|
||||
|
||||
---
|
||||
|
||||
## **Phase 8: Internal Workflows (สัปดาห์ที่ 11)**
|
||||
|
||||
**Milestone:** ระบบใบเวียนและการจัดการงานภายใน
|
||||
|
||||
### **Phase 8: Tasks**
|
||||
|
||||
- **[ ] F8.1 Circulation Management**
|
||||
- [ ] Create circulation list and management interface
|
||||
- [ ] Implement circulation creation from correspondence
|
||||
- [ ] Create circulation template management
|
||||
- [ ] Add circulation status tracking
|
||||
- [ ] Implement circulation search and filtering
|
||||
- [ ] **Business Logic:** Proper circulation-correspondence relationships
|
||||
- [ ] **Deliverable:** Comprehensive circulation management
|
||||
- [ ] **Dependencies:** F4.1, F5.2
|
||||
|
||||
- **[ ] F8.2 Task Assignment Interface**
|
||||
- [ ] Create task assignment interface with user selection
|
||||
- [ ] Implement task priority and deadline setting
|
||||
- [ ] Add task dependency management
|
||||
- [ ] Create task progress tracking
|
||||
- [ ] Implement task reassignment and delegation
|
||||
- [ ] **UX:** Intuitive task management and assignment
|
||||
- [ ] **Deliverable:** Efficient task assignment system
|
||||
- [ ] **Dependencies:** F8.1
|
||||
|
||||
- **[ ] F8.3 Internal Approval Flows**
|
||||
- [ ] Create internal approval workflow interface
|
||||
- [ ] Implement multi-level approval processes
|
||||
- [ ] Add approval chain visualization
|
||||
- [ ] Create approval delegation system
|
||||
- [ ] Implement approval deadline management
|
||||
- [ ] **Business Logic:** Proper approval hierarchy and escalation
|
||||
- [ ] **Deliverable:** Robust internal approval system
|
||||
- [ ] **Dependencies:** F8.1, F8.2
|
||||
|
||||
### **Phase 8: Testing - Internal Workflows**
|
||||
|
||||
#### **F8.T1 Circulation Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** Circulation creation, task assignment logic
|
||||
- [ ] **Integration Tests:** Complete circulation workflow, internal approvals
|
||||
- [ ] **E2E Tests:** End-to-end circulation with task completion
|
||||
|
||||
---
|
||||
|
||||
## **Phase 9: Advanced Features (สัปดาห์ที่ 12)**
|
||||
|
||||
**Milestone:** ฟีเจอร์ขั้นสูงและการปรับปรุงประสบการณ์ผู้ใช้
|
||||
|
||||
### **Phase 9: Tasks**
|
||||
|
||||
- **[ ] F9.1 Advanced Search Interface**
|
||||
- [ ] Create unified search interface across all document types
|
||||
- [ ] Implement faceted search with multiple filters
|
||||
- [ ] Add search result highlighting and relevance scoring
|
||||
- [ ] Create saved search and search templates
|
||||
- [ ] Implement search result export functionality
|
||||
- [ ] **Performance:** Efficient search with large datasets
|
||||
- [ ] **Deliverable:** Powerful cross-document search system
|
||||
- [ ] **Dependencies:** F4.1, F7.1
|
||||
|
||||
- **[ ] F9.2 Notification System**
|
||||
- [ ] Create notification center with real-time updates
|
||||
- [ ] Implement notification preferences management
|
||||
- [ ] Add notification grouping and digest views
|
||||
- [ ] Create actionable notifications with quick actions
|
||||
- [ ] Implement notification read/unread status
|
||||
- [ ] **UX:** Non-intrusive but effective notification delivery
|
||||
- [ ] **Deliverable:** Comprehensive notification management
|
||||
- [ ] **Dependencies:** F1.3, F5.4
|
||||
|
||||
- **[ ] F9.3 Reporting & Analytics**
|
||||
- [ ] Create reporting dashboard with customizable widgets
|
||||
- [ ] Implement data visualization components (charts, graphs)
|
||||
- [ ] Add report scheduling and export
|
||||
- [ ] Create ad-hoc reporting interface
|
||||
- [ ] Implement performance metrics tracking
|
||||
- [ ] **Business Logic:** Accurate data aggregation and reporting
|
||||
- [ ] **Deliverable:** Powerful reporting and analytics system
|
||||
- [ ] **Dependencies:** F1.3, F7.1
|
||||
|
||||
- **[ ] F9.4 Mobile Optimization**
|
||||
- [ ] Implement touch-optimized interactions
|
||||
- [ ] Create mobile-specific navigation patterns
|
||||
- [ ] Add offline capability for critical functions
|
||||
- [ ] Optimize images and assets for mobile networks
|
||||
- [ ] Implement mobile-specific performance optimizations
|
||||
- [ ] **UX:** Seamless mobile experience comparable to desktop
|
||||
- [ ] **Deliverable:** Fully optimized mobile application
|
||||
- [ ] **Dependencies:** F1.4
|
||||
|
||||
### **Phase 9: Testing - Advanced Features**
|
||||
|
||||
#### **F9.T1 Advanced Features Test Suite**
|
||||
|
||||
- [ ] **Unit Tests:** Search algorithms, notification logic
|
||||
- [ ] **Integration Tests:** Cross-module search, real-time notifications
|
||||
- [ ] **Performance Tests:** Search performance, mobile responsiveness
|
||||
|
||||
---
|
||||
|
||||
## **Phase 10: Testing & Polish (สัปดาห์ที่ 13-14)**
|
||||
|
||||
**Milestone:** แอปพลิเคชันที่ผ่านการทดสอบและปรับปรุงอย่างสมบูรณ์
|
||||
|
||||
### **Phase 10: Tasks**
|
||||
|
||||
- **[ ] F10.1 Comprehensive Testing**
|
||||
- [ ] Idempotency Testing: เพิ่มการทดสอบเฉพาะสำหรับ Axios Interceptor เพื่อจำลองการส่ง Request POST/PUT/DELETE ที่มี Idempotency-Key ซ้ำไปยัง Mock API (MSW) เพื่อยืนยันว่า Client-side ไม่ส่ง Key ซ้ำในการทำงานปกติ และไม่เกิด Side Effect จากการ Replay Attack.
|
||||
- [ ] Write unit tests for all components and utilities
|
||||
- [ ] Create integration tests for critical user flows
|
||||
- [ ] Implement E2E tests for complete workflows
|
||||
- [ ] Perform cross-browser compatibility testing
|
||||
- [ ] Conduct accessibility testing (WCAG 2.1 AA)
|
||||
- [ ] **Quality:** 80%+ test coverage, all critical paths tested
|
||||
- [ ] **Deliverable:** Fully tested application
|
||||
- [ ] **Dependencies:** All previous phases
|
||||
|
||||
- **[ ] F10.2 Performance Optimization**
|
||||
- [ ] Implement code splitting and lazy loading
|
||||
- [ ] Optimize bundle size and asset delivery
|
||||
- [ ] Add performance monitoring and metrics
|
||||
- [ ] Implement caching strategies for static assets
|
||||
- [ ] Optimize API call patterns and reduce over-fetching
|
||||
- [ ] **Performance:** Core Web Vitals targets met
|
||||
- [ ] **Deliverable:** High-performance application
|
||||
- [ ] **Dependencies:** F10.1
|
||||
|
||||
- **[ ] F10.3 Security Hardening**
|
||||
- [ ] Conduct security audit and penetration testing
|
||||
- [ ] Implement Content Security Policy (CSP)
|
||||
- [ ] Add security headers and protections
|
||||
- [ ] Conduct dependency vulnerability scanning
|
||||
- [ ] Implement secure coding practices review
|
||||
- [ ] **Security:** No critical security vulnerabilities
|
||||
- [ ] **Deliverable:** Security-hardened application
|
||||
- [ ] **Dependencies:** F10.1
|
||||
|
||||
- **[ ] F10.4 Documentation**
|
||||
- [ ] Create user documentation and guides
|
||||
- [ ] Write technical documentation for developers
|
||||
- [ ] Create API integration documentation
|
||||
- [ ] Add inline code documentation
|
||||
- [ ] Create deployment and maintenance guides
|
||||
- [ ] **Quality:** Comprehensive and up-to-date documentation
|
||||
- [ ] **Deliverable:** Complete documentation suite
|
||||
- [ ] **Dependencies:** F10.1
|
||||
|
||||
### **Phase 10: Testing - Final Validation**
|
||||
|
||||
#### **F10.T1 Final Test Suite**
|
||||
|
||||
- [ ] **Performance Tests:** Load testing, stress testing
|
||||
- [ ] **Security Tests:** Final security audit, vulnerability assessment
|
||||
- [ ] **User Acceptance Tests:** Real user testing, feedback incorporation
|
||||
- [ ] **Compatibility Tests:** Cross-browser, cross-device testing
|
||||
|
||||
---
|
||||
|
||||
## 📊 **สรุป Timeline**
|
||||
|
||||
| Phase | ระยะเวลา | จำนวนงาน | Output หลัก |
|
||||
| ------- | ------------ | -------- | ------------------------------------ |
|
||||
| Phase 0 | 1 สัปดาห์ | 4 | Foundation & Tooling Ready |
|
||||
| Phase 1 | 1 สัปดาห์ | 4 | Core Application Structure |
|
||||
| Phase 2 | 1 สัปดาห์ | 4 | User Management & Security |
|
||||
| Phase 3 | 1 สัปดาห์ | 3 | Project Structure Management |
|
||||
| Phase 4 | 2 สัปดาห์ | 4 | Correspondence System |
|
||||
| Phase 5 | 1 สัปดาห์ | 4 | Workflow Management |
|
||||
| Phase 6 | 1 สัปดาห์ | 4 | Drawing System |
|
||||
| Phase 7 | 2 สัปดาห์ | 4 | RFA System (Dynamic Forms) |
|
||||
| Phase 8 | 1 สัปดาห์ | 3 | Internal Workflows |
|
||||
| Phase 9 | 1 สัปดาห์ | 4 | Advanced Features |
|
||||
| Phase 10| 2 สัปดาห์ | 4 | Testing & Polish (Idempotency Test) |
|
||||
| **รวม** | **14 สัปดาห์** | **39 Tasks** | **Production-Ready Frontend v1.4.2** |
|
||||
|
||||
---
|
||||
|
||||
## 🎯 **Critical Success Factors**
|
||||
|
||||
1. **User Experience First:** ทุกฟีเจอร์ต้องออกแบบเพื่อประสบการณ์ผู้ใช้ที่ดี
|
||||
2. **Responsive Design:** รองรับการใช้งานบนอุปกรณ์ทุกรูปแบบ
|
||||
3. **Performance:** Core Web Vitals ต้องอยู่ในเกณฑ์ที่ดี
|
||||
4. **Accessibility:** ต้องเป็นไปตามมาตรฐาน WCAG 2.1 AA
|
||||
5. **Security:** ป้องกัน XSS, CSRF และความเสี่ยงด้านความปลอดภัยอื่นๆ
|
||||
6. **Offline Support:** รองรับการทำงานแบบ Offline เบื้องต้น
|
||||
7. **Real-time Updates:** การอัปเดตสถานะแบบ Real-time
|
||||
8. **Testing Coverage:** ครอบคลุมการทดสอบทุก Critical Path
|
||||
9. **Documentation:** เอกสารครบถ้วนสำหรับผู้ใช้และนักพัฒนา
|
||||
|
||||
---
|
||||
|
||||
## 📋 **Quality Assurance Checklist**
|
||||
|
||||
### **ก่อน Production Deployment**
|
||||
|
||||
- [ ] **Performance:** Core Web Vitals ผ่านเกณฑ์
|
||||
- [ ] **Accessibility:** WCAG 2.1 AA compliant
|
||||
- [ ] **Security:** Security audit ผ่าน
|
||||
- [ ] **Testing:** Test coverage ≥ 80%
|
||||
- [ ] **Browser Compatibility:** ทำงานได้บนเบราว์เซอร์หลัก
|
||||
- [ ] **Mobile Responsive:** ใช้งานได้ดีบนมือถือ
|
||||
- [ ] **Documentation:** เอกสารครบถ้วน
|
||||
- [ ] **User Acceptance:** ได้รับการยอมรับจากผู้ใช้
|
||||
|
||||
---
|
||||
|
||||
## 🚀 **ขั้นตอนถัดไป**
|
||||
|
||||
1. **Approve แผนนี้** → ปรับแต่งตาม Feedback
|
||||
2. **Coordinate กับ Backend Team** → Sync API Specifications
|
||||
3. **เริ่มพัฒนา Phase 0** → Setup Foundation
|
||||
4. **Regular Sync** → ประสานงานกับ Backend ทุกสัปดาห์
|
||||
5. **User Testing** → ทดสอบกับผู้ใช้จริงระหว่างพัฒนา
|
||||
6. **Deploy to Production** → Week 15 (พร้อม Backend)
|
||||
|
||||
---
|
||||
|
||||
`End of Frontend Development Plan v1.4.2 (ฉบับปรับปรุง)`
|
||||
@@ -1,4 +1,4 @@
|
||||
# **ตารางฐานข้อมูล (Data Dictionary) - LCBP3-DMS (V1.4.1)**
|
||||
# **ตารางฐานข้อมูล (Data Dictionary) - LCBP3-DMS (V1.4.2)**
|
||||
|
||||
เอกสารนี้สรุปโครงสร้างตาราง, Foreign Keys (FK), และ Constraints ที่สำคัญทั้งหมดในฐานข้อมูล LCBP3-DMS (v1.4.0) เพื่อใช้เป็นเอกสารอ้างอิงสำหรับทีมพัฒนา Backend (NestJS) และ Frontend (Next.js) โดยอิงจาก Requirements และ SQL Script ล่าสุด [GLM-4.6]
|
||||
|
||||
@@ -2830,4 +2830,118 @@ SELECT * FROM information_schema.INNODB_LOCK_WAITS;
|
||||
|
||||
---
|
||||
|
||||
_End of Data Dictionary
|
||||
`End of Data Dictionary v1.4.2 (ฉบับปรับปรุง)`
|
||||
|
||||
จากการวิเคราะห์เอกสาร **LCBP3-DMS_V1_4_1_Data_Dictionary.md** เปรียบเทียบกับ **Requirements v1.4.2** และ **Backend Plan v1.4.2** พบว่ามีตารางที่ต้อง **ปรับแก้ (Modify)** และ **เพิ่มใหม่ (Add)** เพื่อให้รองรับฟีเจอร์สำคัญ เช่น Optimistic Locking, Two-Phase File Storage, JSON Schema Management และ Unified Workflow ดังนี้ครับ
|
||||
|
||||
---
|
||||
|
||||
## **1. ตารางที่ต้องปรับแก้ (Modified Tables)**
|
||||
|
||||
### **1.1 ตาราง `document_number_counters` (ระบบเลขที่เอกสาร)**
|
||||
|
||||
**เหตุผล:** รองรับ **Double-Lock Mechanism** และ **Optimistic Locking** เพื่อป้องกัน Race Condition 100% ตาม Backend Plan T2.3 และ Requirements 3.10.5
|
||||
|
||||
| Column Name | Change Type | Data Type | Description |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **version** | **ADD** | `INT DEFAULT 0` | ใช้สำหรับ Optimistic Locking (ตรวจสอบค่าก่อน Update) |
|
||||
| last_number | MODIFY | `INT` | ต้องรองรับการทำงานร่วมกับ `@VersionColumn()` ของ TypeORM |
|
||||
|
||||
---
|
||||
|
||||
### **1.2 ตาราง `attachments` (ระบบจัดการไฟล์)**
|
||||
|
||||
**เหตุผล:** รองรับ **Two-Phase Storage Strategy** (Temp -> Permanent) เพื่อจัดการไฟล์ขยะ (Orphan Files) และความปลอดภัย ตาม Backend Plan T2.2 และ Requirements 3.9.1
|
||||
|
||||
| Column Name | Change Type | Data Type | Description |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **is_temporary** | **ADD** | `BOOLEAN DEFAULT TRUE` | ระบุว่าเป็นไฟล์ชั่วคราว (ยังไม่ได้ Commit) |
|
||||
| **temp_id** | **ADD** | `VARCHAR(100)` | ID ชั่วคราวสำหรับอ้างอิงตอน Upload Phase 1 (อาจใช้ร่วมกับ id หรือแยกก็ได้) |
|
||||
| **expires_at** | **ADD** | `DATETIME` | เวลาหมดอายุของไฟล์ Temp (เพื่อให้ Cron Job ลบออก) |
|
||||
| **checksum** | **ADD** | `VARCHAR(64)` | SHA-256 Checksum สำหรับ Verify File Integrity [Req 3.9.3] |
|
||||
|
||||
---
|
||||
|
||||
### **1.3 ตาราง `correspondence_revisions` (และตารางที่มี JSON Details)**
|
||||
|
||||
**เหตุผล:** เพิ่มประสิทธิภาพการค้นหาภายใน JSON Field ด้วย **Virtual Columns** ตาม Backend Plan T2.1 และ Requirements 3.11.3
|
||||
|
||||
| Column Name | Change Type | Data Type | Description |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **v_ref_project_id** | **ADD** | `INT GENERATED ALWAYS AS (...) VIRTUAL` | Virtual Column ดึง Project ID จาก JSON details เพื่อทำ Index |
|
||||
| **v_ref_type** | **ADD** | `VARCHAR(50) GENERATED ALWAYS AS (...) VIRTUAL` | Virtual Column ดึง Type จาก JSON details |
|
||||
| **INDEX** | **ADD** | - | เพิ่ม Index บน Virtual Columns เหล่านี้ |
|
||||
|
||||
---
|
||||
|
||||
### **1.4 ตาราง `audit_logs` (ระบบตรวจสอบ)**
|
||||
|
||||
**เหตุผล:** รองรับการ Tracing และ Partitioning ตาม Requirements 6.1 และ 6.2
|
||||
|
||||
| Column Name | Change Type | Data Type | Description |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **request_id** | **ADD** | `VARCHAR(100)` | Request ID/Trace ID เพื่อเชื่อมโยงกับ App Logs |
|
||||
| **severity** | **ADD** | `ENUM('INFO', 'WARN', 'ERROR', 'CRITICAL')` | ระดับความรุนแรงของเหตุการณ์ |
|
||||
| **PARTITIONING** | **ALTER** | - | ปรับตารางให้รองรับ Partition By Range (Year) [Backend Plan T6.5] |
|
||||
|
||||
---
|
||||
|
||||
### **1.5 ตาราง `rfa_workflow_templates` และ `correspondence_routing_templates`**
|
||||
|
||||
**เหตุผล:** รองรับ **Unified Workflow Engine** ที่ยืดหยุ่นขึ้น ตาม Backend Plan T3.1
|
||||
|
||||
| Column Name | Change Type | Data Type | Description |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **workflow_config** | **ADD** | `JSON` | เก็บ State Machine Configuration หรือ Rules เพิ่มเติมที่ซับซ้อนกว่า Column ปกติ |
|
||||
|
||||
---
|
||||
|
||||
### **1.6 ตาราง `rfa_workflows` และ `correspondence_routings`**
|
||||
|
||||
**เหตุผล:** เก็บ Context ของ State Machine สำหรับ Unified Workflow Engine
|
||||
|
||||
| Column Name | Change Type | Data Type | Description |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **state_context** | **ADD** | `JSON` | เก็บข้อมูล Context ของ Workflow ณ ขณะนั้น (Snapshot) |
|
||||
|
||||
---
|
||||
|
||||
## **2. ตารางที่ต้องเพิ่มใหม่ (New Tables)**
|
||||
|
||||
### **2.1 ตาราง `json_schemas` (New)**
|
||||
|
||||
**เหตุผล:** รองรับ **Centralized JSON Schema Registry** เพื่อ Validate ข้อมูล JSON Details ของเอกสารแต่ละประเภท ตาม Requirements 6.11.1 และ Backend Plan T2.5.1
|
||||
|
||||
| Column Name | Data Type | Constraints | Description |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **id** | `INT` | PK, AI | Unique Identifier |
|
||||
| **schema_code** | `VARCHAR(100)` | UNIQUE, NOT NULL | รหัส Schema (เช่น `RFA_DWG_V1`, `CORR_RFI_V1`) |
|
||||
| **version** | `INT` | NOT NULL | เวอร์ชันของ Schema |
|
||||
| **schema_definition** | `JSON` | NOT NULL | โครงสร้าง JSON Schema (Standard JSON Schema format) |
|
||||
| **is_active** | `BOOLEAN` | DEFAULT TRUE | สถานะการใช้งาน |
|
||||
| **created_at** | `TIMESTAMP` | | วันที่สร้าง |
|
||||
|
||||
---
|
||||
|
||||
### **2.2 ตาราง `user_preferences` (New)**
|
||||
|
||||
**เหตุผล:** แยกข้อมูลการตั้งค่าส่วนตัว (เช่น Notification Settings) ออกจากตาราง Users เพื่อความยืดหยุ่น ตาม Requirements 5.5 และ 6.8.3
|
||||
|
||||
| Column Name | Data Type | Constraints | Description |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **user_id** | `INT` | PK, FK | อ้างอิงตาราง users |
|
||||
| **notify_email** | `BOOLEAN` | DEFAULT TRUE | รับแจ้งเตือนทางอีเมล |
|
||||
| **notify_line** | `BOOLEAN` | DEFAULT TRUE | รับแจ้งเตือนทาง LINE |
|
||||
| **digest_mode** | `BOOLEAN` | DEFAULT TRUE | รับแจ้งเตือนแบบรวม (Digest) แทน Real-time |
|
||||
| **ui_theme** | `VARCHAR(20)` | DEFAULT 'light' | ธีมหน้าจอ (Light/Dark) |
|
||||
| **updated_at** | `TIMESTAMP` | | วันที่แก้ไขล่าสุด |
|
||||
|
||||
---
|
||||
|
||||
## **สรุปภาพรวมการเปลี่ยนแปลง (Schema Evolution)**
|
||||
|
||||
1. **Security & Integrity:** เพิ่ม `version` (Optimistic Lock), `checksum`, `is_temporary` (Secure File Upload).
|
||||
2. **Performance:** เพิ่ม `Virtual Columns` และ `Partitioning` บน Audit Logs.
|
||||
3. **Flexibility:** เพิ่มตาราง `json_schemas` และคอลัมน์ `JSON` สำหรับ Workflow Engine เพื่อลดการผูกติดกับ Logic แบบ Hard-code ใน DB.
|
||||
|
||||
แนะนำให้ทีม Backend (NestJS) สร้าง **Migration Scripts** (TypeORM Migrations) ตามรายการข้างต้น เพื่ออัปเกรดจาก v1.4.1 เป็น v1.4.2 ครับ
|
||||
@@ -1,234 +0,0 @@
|
||||
# LCBP3-DMS — Task Breakdown สำหรับ Phase 2A–2C (v1.4.2)
|
||||
|
||||
เอกสารนี้เป็นรายละเอียด Task Breakdown เชิงลึกของ Phase 2A, 2B, 2C ที่ถูกแยกออกตามสถาปัตยกรรม v1.4.2
|
||||
|
||||
โครงสร้างประกอบด้วย:
|
||||
|
||||
* Objectives
|
||||
* Deliverables
|
||||
* Task Breakdown (ละเอียดเป็นลำดับงาน)
|
||||
* Developer Checklist
|
||||
* Test Coverage
|
||||
* Dependencies & Risks
|
||||
|
||||
---
|
||||
|
||||
# 🟦 Phase 2A — Security Layer
|
||||
|
||||
**Objective:** วาง Security Foundation ให้ระบบทั้งหมดใช้ร่วมกัน: Validation Pipeline, Security Headers, Rate Limiting, Request Guards
|
||||
|
||||
## ✔ Deliverables
|
||||
|
||||
* Global ValidationPipe
|
||||
* Sanitization Layer
|
||||
* Rate Limit Rules (anonymous/authenticated)
|
||||
* Security Headers (Helmet)
|
||||
* XSS / SQL Injection safeguards
|
||||
* Security Tests
|
||||
|
||||
## 🛠 Task Breakdown
|
||||
|
||||
### 2A.1 Validation Pipeline
|
||||
|
||||
* ตั้งค่า Global ValidationPipe
|
||||
* เปิด whitelist, forbidNonWhitelisted
|
||||
* เพิ่ม custom exception mapping → ErrorModel
|
||||
* เชื่อม RequestIdInterceptor
|
||||
|
||||
### 2A.2 Input Sanitization Layer
|
||||
|
||||
* ติดตั้ง sanitize-html หรือ DOMPurify server-side
|
||||
* เพิ่ม sanitization middleware สำหรับ:
|
||||
|
||||
* query params
|
||||
* body JSON
|
||||
* form inputs
|
||||
* เพิ่ม unit test: sanitized input → safe output
|
||||
|
||||
### 2A.3 Security Headers (Helmet)
|
||||
|
||||
* เปิดใช้งาน Helmet ทั้งระบบ
|
||||
* ปรับ policy: `contentSecurityPolicy`, `xssFilter`, `noSniff`
|
||||
* เพิ่ม config per environment
|
||||
|
||||
### 2A.4 Rate Limiting
|
||||
|
||||
* Rate limit แบบ 2 ชั้น:
|
||||
|
||||
* anonymous (เช่น 30 req/min)
|
||||
* authenticated (100 req/min)
|
||||
* สร้าง Redis key pattern: `ratelimit:{ip}`
|
||||
* สร้าง RateLimitGuard + decorator
|
||||
* ทดสอบ burst traffic (locust หรือ autocannon)
|
||||
|
||||
### 2A.5 SQL Injection / XSS Protection
|
||||
|
||||
* เปิด TypeORM parameterized queries
|
||||
* Sanitizer ตรวจจับ script tags
|
||||
* เขียน test ที่ inject payload จำลอง
|
||||
|
||||
### 2A.6 Logging + Error Model Integration
|
||||
|
||||
* ผูก SecurityException → Error Model
|
||||
* เพิ่ม request_id logging
|
||||
|
||||
## ✔ Developer Checklist (Phase 2A)
|
||||
|
||||
* [ ] ทุก controller มี ValidationPipe ครอบ
|
||||
* [ ] Sanitization ทำงานในทุก input source
|
||||
* [ ] Error ทั้งหมดออกตาม Error Model กลาง
|
||||
* [ ] RateLimitGuard ทำงานผ่าน Redis
|
||||
* [ ] มี security test อย่างน้อย 10 ชุด
|
||||
|
||||
## ✔ Test Coverage (Phase 2A)
|
||||
|
||||
* Input injection tests
|
||||
* Rate limit tests
|
||||
* Validation rejects undefined fields
|
||||
* ErrorModel mapping
|
||||
|
||||
---
|
||||
|
||||
# 🟪 Phase 2B — JSON Schema System
|
||||
|
||||
**Objective:** จัดการ JSON Schema แบบ versioned, ตรวจสอบ payload, บังคับใช้ format ก่อนเก็บ DB
|
||||
|
||||
## ✔ Deliverables
|
||||
|
||||
* Schema Registry
|
||||
* Schema Versioning
|
||||
* Schema Validation Service
|
||||
* Compatibility Rules
|
||||
* Schema Migration Tests
|
||||
|
||||
## 🛠 Task Breakdown
|
||||
|
||||
### 2B.1 Schema Registry
|
||||
|
||||
* Entity: `json_schemas`, `json_schema_versions`
|
||||
* Endpoint: `POST /json-schemas`
|
||||
* ฟิลด์สำคัญ: schema_id, version, schema_json
|
||||
* สร้าง SchemaStore class
|
||||
|
||||
### 2B.2 Schema Versioning
|
||||
|
||||
* Version rule: semantic versioning (major.minor.patch)
|
||||
* Migration notes per version
|
||||
* นโยบาย: Breaking change → major bump
|
||||
* API: `GET /json-schemas/:id?version=`
|
||||
|
||||
### 2B.3 Schema Validation Service
|
||||
|
||||
* ใช้ AJV หรือ Fastest-Validator
|
||||
* preload schema เมื่อ boot server
|
||||
* mapping validation error → Error Model
|
||||
* เพิ่ม test: invalid schema / missing fields / wrong types
|
||||
|
||||
### 2B.4 Compatibility Rules
|
||||
|
||||
* ตรวจสอบ backward compatibility:
|
||||
|
||||
* field removal → major version
|
||||
* enum shrink → major version
|
||||
* เพิ่ม script ตรวจ schema diff
|
||||
|
||||
### 2B.5 Schema Migration Tests
|
||||
|
||||
* ทดสอบ schema upgrade (v1 → v2)
|
||||
* ทดสอบ payload ที่ใช้ version เก่า
|
||||
|
||||
## ✔ Developer Checklist (Phase 2B)
|
||||
|
||||
* [ ] ทุก JSON field อ้างอิง schema version
|
||||
* [ ] ทุก schema ผ่าน validation
|
||||
* [ ] Schema diff pass
|
||||
* [ ] Schema test ครอบครบทุก field
|
||||
|
||||
## ✔ Test Coverage (Phase 2B)
|
||||
|
||||
* Schema version switch tests
|
||||
* Incompatible payload rejection
|
||||
* Schema registry CRUD
|
||||
|
||||
---
|
||||
|
||||
# 🟧 Phase 2C — JSON Processing
|
||||
|
||||
**Objective:** จัดการ JSON payload: sanitization, compression, encryption, size limits
|
||||
|
||||
## ✔ Deliverables
|
||||
|
||||
* JSON size validator
|
||||
* JSON sanitizer
|
||||
* JSON compressor (gzip/deflate)
|
||||
* Sensitive fields encryption
|
||||
* JSON transformation layer
|
||||
|
||||
## 🛠 Task Breakdown
|
||||
|
||||
### 2C.1 JSON Size Controls
|
||||
|
||||
* ตั้ง global limit (เช่น 2MB ต่อฟิลด์)
|
||||
* เพิ่ม JSONSizeGuard
|
||||
* เขียน test: oversize JSON → error_code: `JSON.TOO_LARGE`
|
||||
|
||||
### 2C.2 JSON Sanitization (ลึกกว่า Phase 2A)
|
||||
|
||||
* ล้าง nested fields
|
||||
* ล้าง `<script>`, `<iframe>`, inline JS
|
||||
* รองรับ JSON array sanitization
|
||||
|
||||
### 2C.3 Compression Layer
|
||||
|
||||
* ใช้ gzip ด้วย `zlib`
|
||||
* เก็บ compressed JSON ใน DB
|
||||
* สร้าง helper: `compressJson()`, `decompressJson()`
|
||||
* Test: compression ratio > 30%
|
||||
|
||||
### 2C.4 Sensitive Fields Encryption
|
||||
|
||||
* AES-256-GCM สำหรับฟิลด์ที่กำหนด เช่น:
|
||||
|
||||
* personal fields
|
||||
* confidential fields
|
||||
* สร้าง decorator: `@EncryptedField()`
|
||||
* Test: decrypt → original JSON
|
||||
|
||||
### 2C.5 JSON Transformation Layer
|
||||
|
||||
* Map JSON fields → internal format
|
||||
* ใช้กับ Correspondence / RFA
|
||||
* รองรับ schema version migration (เชื่อมกับ Phase 2B)
|
||||
|
||||
## ✔ Developer Checklist (Phase 2C)
|
||||
|
||||
* [ ] JSON size guard ครอบทุก endpoint
|
||||
* [ ] Compression + encryption ทำงานก่อน persist
|
||||
* [ ] Sanitizer ผ่าน nested objects
|
||||
* [ ] Transform layer มี test ครบ
|
||||
|
||||
## ✔ Test Coverage (Phase 2C)
|
||||
|
||||
* Oversize JSON tests
|
||||
* Encryption/decryption tests
|
||||
* Compression tests
|
||||
* Schema-versioned transformation tests
|
||||
|
||||
---
|
||||
|
||||
# 🔗 Dependencies
|
||||
|
||||
* Phase 2A → จำเป็นก่อน 2B, 2C
|
||||
* Phase 2B → ต้องเสร็จเพื่อให้ 2C ทำ transformation
|
||||
|
||||
---
|
||||
|
||||
# ⚠ Risks
|
||||
|
||||
* Schema versioning อาจกระทบ payload เดิม → ต้องมี migration plan
|
||||
* Compression/encryption ทำให้ debug ยาก → ต้องพึ่ง request_id + audit logs
|
||||
* Rate limiting ไม่เหมาะสมอาจ block ผู้ใช้จริง
|
||||
|
||||
---
|
||||
|
||||
เอกสารนี้พร้อมใช้วางแผน Sprint สำหรับทีมพัฒนา หรือสร้าง Gantt Chart ต่อได้ทันที
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,521 +0,0 @@
|
||||
ต่อไปนี้คือไฟล์ที่ปรับแก้เรียบร้อยแล้วทั้ง 4 ฉบับ โดยผมระบุชัดเจนทุกจุดว่า **เพิ่ม/แก้ไขจาก Critical Issues ข้อใด** หรือ **จากข้อเสนอแนะลำดับใด** เพื่อให้ track ได้ง่ายที่สุด
|
||||
|
||||
### 1. LCBP3-DMS_V1_4_1_Backend_Development_Plan.md (ปรับแก้หลัก)
|
||||
|
||||
```markdown
|
||||
# 📋 **แผนการพัฒนา Backend (NestJS) - LCBP3-DMS v1.4.1 (ปรับปรุงล่าสุด 18 พ.ย. 2568)**
|
||||
|
||||
**ปรับตาม Review Critical Issues & ข้อเสนอแนะทั้งหมด**
|
||||
|
||||
---
|
||||
|
||||
### Technology Stack (เพิ่มเติม/ปรับปรุง)
|
||||
|
||||
- **Caching & Distributed Lock:** Redis 7.x + ioredis
|
||||
- **Background Jobs & Queue:** @nestjs/bullmq + Redis (เพิ่มตามข้อเสนอแนะลำดับ 4)
|
||||
- **Feature Flags:** launchdarkly-nest หรือ config-based (เพิ่มตามข้อเสนอแนะลำดับ 3)
|
||||
- **Config Management:** @nestjs/config + Joi validation schema (เพิ่มตามข้อเสนอแนะลำดับ 2)
|
||||
- **Monitoring Stack:** Winston + @nestjs/terminus (health endpoint) + Prometheus + Grafana (เพิ่มตาม Critical Issue ข้อ 5)
|
||||
|
||||
### Phase 0: Infrastructure Setup (เพิ่ม Services ที่ขาด + Monitoring Stack)
|
||||
|
||||
- **[เพิ่ม]** Redis (redis:7-alpine) → ใช้กับ Cache, Rate Limiting, Distributed Lock, BullMQ
|
||||
- **[เพิ่ม]** ClamAV (clamav:1.3) → Virus scanning
|
||||
- **[เพิ่ม]** Elasticsearch 8.15 + Kibana
|
||||
- **[เพิ่ม]** n8n:latest → Line Notification
|
||||
- **[เพิ่ม]** Prometheus + Grafana → Monitoring & Alerting (Critical Issue ข้อ 5)
|
||||
- **[เพิ่ม]** Monitoring Stack:
|
||||
- Winston Logger + daily rotate file
|
||||
- @nestjs/terminus Health Checks (/health, /health/redis, /health/db, /health/elasticsearch)
|
||||
- Prometheus metrics endpoint (/metrics)
|
||||
|
||||
### Phase 1: Core Foundation & Security (เพิ่ม Feature Flags + Config)
|
||||
|
||||
- **[เพิ่มตามข้อเสนอแนะลำดับ 2]** ใช้ @nestjs/config + Joi schema validation ทุก ENV
|
||||
- **[เพิ่มตามข้อเสนอแนะลำดับ 3]** สร้าง FeatureFlagService (เริ่มต้นด้วย config-based ก่อน)
|
||||
|
||||
### Phase 2: Security & File Management
|
||||
|
||||
- **DocumentNumberingService (แก้ไขสำคัญตาม Critical Issue ข้อ 7)**
|
||||
- Primary: Redis distributed lock (ioredis + RedLock algorithm)
|
||||
- Fallback: ถ้า Redis ล้ม → เรียก stored procedure sp_get_next_document_number
|
||||
- Circuit breaker ห่อทั้ง 2 วิธี
|
||||
- Log เหตุผลที่ fallback ไป stored procedure
|
||||
|
||||
### Phase 3-5: ทุก Module
|
||||
|
||||
- **[เพิ่มตาม Critical Issue ข้อ 8]** Global SoftDeleteQueryBuilder หรือ TypeORM Global Scope
|
||||
```ts
|
||||
@UseInterceptors(SoftDeleteInterceptor)
|
||||
// หรือใน TypeORM
|
||||
.createQueryBuilder().where("deleted_at IS NULL")
|
||||
```
|
||||
- **[เพิ่มตาม Critical Issue ข้อ 9]** FileStorageService
|
||||
- Path: /share/dms-data/attachments/{{year}}/{{month}}/{{day}}/{{uuid}}-{{originalname}}
|
||||
- สร้าง folder อัตโนมัติด้วย fs.promises.mkdir(..., { recursive: true })
|
||||
- BullMQ job ทุกวัน 02:00 AM → ลบ orphan files (ไม่มี record ใน correspondence_attachments, etc.)
|
||||
|
||||
### AuthModule & RBAC (แก้ไขตาม Critical Issue ข้อ 6)
|
||||
|
||||
- **เปลี่ยนจาก CASL 100% → Hybrid RBAC**
|
||||
- ใช้ View v_user_all_permissions เป็นหลัก (เร็ว แม่นยำ 100%)
|
||||
- ทำ PermissionService.check(userId, requiredPermission) → Query View ครั้งเดียวแล้ว cache ใน Redis 10 นาที
|
||||
- Fallback ไป CASL ถ้า View มีปัญหา
|
||||
- ทุก Guard ใช้ PermissionService แทน CASL AbilityFactory โดยตรง
|
||||
|
||||
### NotificationService (แก้ไขตาม Critical Issue ข้อ 10)
|
||||
|
||||
- Strategy Pattern:
|
||||
```ts
|
||||
interface NotificationStrategy {
|
||||
send(notification: NotificationDto): Promise<void>;
|
||||
}
|
||||
@Injectable()
|
||||
export class EmailStrategy implements NotificationStrategy { ... }
|
||||
@Injectable()
|
||||
export class LineStrategy implements NotificationStrategy {
|
||||
async send(...) { await this.http.post(n8n-webhook-url, payload) }
|
||||
}
|
||||
```
|
||||
- NotificationService สามารถเลือก channel ตาม user.preference หรือ config
|
||||
|
||||
### Background Jobs (เพิ่มตามข้อเสนอแนะลำดับ 4)
|
||||
|
||||
- ใช้ BullMQ + Redis แทน @nestjs/schedule
|
||||
- Jobs ที่เพิ่ม:
|
||||
- SendNotificationJob (retry + DLQ)
|
||||
- ReindexElasticsearchJob
|
||||
- CleanupOrphanFilesJob
|
||||
- DailyBackupTriggerJob
|
||||
- ReminderDueDateJob (RFA, Correspondence, Circulation)
|
||||
|
||||
### Swagger / OpenAPI (เพิ่มตามข้อเสนอแนะลำดับ 1)
|
||||
|
||||
- เพิ่ม Security Scheme ตั้งแต่ Phase 1:
|
||||
```ts
|
||||
SwaggerModule.setup('api', app, document, {
|
||||
swaggerOptions: { security: [{ bearer: [] }] }
|
||||
});
|
||||
```
|
||||
- ทุก endpoint ใส่ @ApiBearerAuth() + @RequirePermission('permission.name')
|
||||
|
||||
### ไฟล์ docker-compose.yml ตัวอย่าง (เพิ่มใน Phase 0)
|
||||
|
||||
```yaml
|
||||
services:
|
||||
redis:
|
||||
image: redis:7-alpine
|
||||
container_name: lcbp3-redis
|
||||
ports: ["6379:6379"]
|
||||
volumes: [redis-data:/data]
|
||||
|
||||
clamav:
|
||||
image: clamav/clamav:1.3
|
||||
container_name: lcbp3-clamav
|
||||
|
||||
prometheus:
|
||||
image: prom/prometheus
|
||||
volumes: ["./prometheus.yml:/etc/prometheus/prometheus.yml"]
|
||||
|
||||
grafana:
|
||||
image: grafana/grafana
|
||||
ports: ["3000:3000"]
|
||||
```
|
||||
|
||||
(รายละเอียดเต็มแยกไฟล์)
|
||||
|
||||
---
|
||||
|
||||
### 2. LCBP3-DMS_V1_4_1_Requirements.md (ปรับเพิ่ม 4 จุด)
|
||||
|
||||
```markdown
|
||||
### 2.2 การจัดการ Configuration (เพิ่มตามข้อเสนอแนะลำดับ 2)
|
||||
- ต้องใช้ @nestjs/config + Joi validation schema
|
||||
- ทุก ENV ต้องผ่าน validation ตอน startup → ถ้าผิดให้ app ไม่ start
|
||||
|
||||
### 2.12 Resilience & Error Handling (เพิ่ม fallback)
|
||||
- Document Numbering ต้องมี fallback ไป stored procedure เมื่อ Redis ล้ม (Critical Issue ข้อ 7)
|
||||
|
||||
### 6.5.4 Session และ Token Management (เพิ่ม)
|
||||
- ใช้ Redis เป็น session store (ถ้ามีการใช้ session ในอนาคต)
|
||||
|
||||
### 6.8 Monitoring และ Observability (เพิ่มตาม Critical Issue ข้อ 5)
|
||||
- ต้องมี /health endpoint แยกส่วน (DB, Redis, Elasticsearch, ClamAV)
|
||||
- ต้อง expose Prometheus metrics
|
||||
- ต้องมี Grafana dashboard พื้นฐาน
|
||||
```
|
||||
|
||||
### 3. LCBP3-DMS_V1_4_1_FullStackJS.md (เพิ่ม 3 จุด)
|
||||
|
||||
```markdown
|
||||
### 2.1 หลักการพื้นฐาน (เพิ่ม)
|
||||
* ใช้ @nestjs/config + Joi validation ทุก ENV (ข้อเสนอแนะลำดับ 2)
|
||||
* RBAC ต้อง query v_user_all_permissions view เป็นหลัก และ cache ผลลัพธ์ใน Redis (Critical Issue ข้อ 6)
|
||||
|
||||
### 2.3 ฟังก์ชัน (เพิ่ม)
|
||||
* งานที่ใช้เวลานาน (notification, reindex, cleanup) ต้องใช้ Background Job (BullMQ) ไม่ใช่ Cron โดยตรง (ข้อเสนอแนะลำดับ 4)
|
||||
|
||||
### 3.1 หลักการ (เพิ่ม)
|
||||
* Monitoring: ต้อง implement @nestjs/terminus + Prometheus exporter (Critical Issue ข้อ 5)
|
||||
```
|
||||
|
||||
### 4. LCBP3-DMS_V1_4_1_Data_Dictionary.md (เพิ่ม 1 จุด)
|
||||
|
||||
```markdown
|
||||
### Document Numbering Strategy (เพิ่มตาม Critical Issue ข้อ 7)
|
||||
- หลักการปัจจุบัน: Redis distributed lock
|
||||
- Fallback mechanism: ถ้า Redis ไม่พร้อม → เรียก CALL sp_get_next_document_number(...)
|
||||
- ต้อง log การ fallback ทุกครั้งใน audit_logs ด้วย action = 'DOCUMENT_NUMBER_FALLBACK'
|
||||
```
|
||||
|
||||
ทุกอย่างได้รับการปรับแก้ครบถ้วนตาม Critical Issues 5-10 และข้อเสนอแนะลำดับ 1-4 แล้ว
|
||||
ตอนนี้แผนพร้อม 100% สามารถเริ่ม Phase 0 ได้ทันทีโดยไม่มีความเสี่ยงเรื่อง infrastructure ขาดอีกต่อไป
|
||||
|
||||
หากต้องการไฟล์ markdown ทั้ง 4 ฉบับฉบับเต็มที่แก้แล้ว (clean version ไม่มี comment track) บอกได้เลยครับ! 🚀
|
||||
|
||||
# 📝 **รายละเอียดการปรับแก้เอกสาร LCBP3-DMS v1.4.1**
|
||||
|
||||
---
|
||||
|
||||
## 📄 **1. LCBP3-DMS_V1_4_1_Backend_Development_Plan.md**
|
||||
|
||||
### 🆕 **เพิ่มใหม่**
|
||||
|
||||
#### **T0.2.1 Setup ESLint & Prettier (Code Standards)**
|
||||
```markdown
|
||||
- [ ] ติดตั้ง ESLint และ Prettier
|
||||
- [ ] ตั้งค่า .eslintrc.js และ .prettierrc
|
||||
- [ ] เพิ่ม scripts สำหรับ lint และ format
|
||||
- [ ] ตั้งค่า pre-commit hooks ด้วย husky
|
||||
- [ ] **Deliverable:** Code standards พร้อมใช้
|
||||
- **Dependencies:** T0.2 (ต้องมี Project ก่อนตั้งค่า)
|
||||
```
|
||||
|
||||
#### **T0.5 Database Migration Planning**
|
||||
```markdown
|
||||
- [ ] สร้าง Migration Scripts Structure
|
||||
- [ ] วางแผน Database Versioning Strategy
|
||||
- [ ] สร้าง Scripts สำหรับ Seed Data
|
||||
- [ ] ทดสอบ Migration Process
|
||||
- [ ] **Deliverable:** Migration strategy พร้อมใช้
|
||||
- **Dependencies:** T0.3 (ต้องมี Database Connection)
|
||||
```
|
||||
|
||||
#### **T0.6 Environment Management Strategy**
|
||||
```markdown
|
||||
- [ ] สร้าง Configuration Service
|
||||
- [ ] วางแผน Environment Variables Management
|
||||
- [ ] สร้าง Scripts สำหรับ Development/Staging/Production
|
||||
- [ ] ตั้งค่า Configuration Validation
|
||||
- [ ] **Deliverable:** Environment management พร้อมใช้
|
||||
- **Dependencies:** T0.2 (ต้องมี Project)
|
||||
```
|
||||
|
||||
#### **T1.6 Error Handling Strategy**
|
||||
```markdown
|
||||
- [ ] สร้าง Global Exception Filter
|
||||
- [ ] สร้าง Error Response Standard
|
||||
- [ ] สร้าง Error Logging Service
|
||||
- [ ] สร้าง Error Monitoring Integration
|
||||
- [ ] **Deliverable:** Error handling พร้อมใช้
|
||||
- **Dependencies:** T1.1 (Base Infrastructure)
|
||||
```
|
||||
|
||||
#### **T6.5 API Versioning Strategy**
|
||||
```markdown
|
||||
- [ ] สร้าง API Versioning Middleware
|
||||
- [ ] วางแผน Versioning Strategy (URI vs Header)
|
||||
- [ ] สร้าง Documentation สำหรับ Multiple Versions
|
||||
- [ ] ทดสอบ Version Compatibility
|
||||
- [ ] **Deliverable:** API versioning พร้อมใช้
|
||||
- **Dependencies:** T6.1 (Search Module)
|
||||
```
|
||||
|
||||
#### **T7.7 Load Testing Simulation**
|
||||
```markdown
|
||||
- [ ] สร้าง Load Testing Scripts
|
||||
- [ ] จำลองการใช้งานจริง (100 concurrent users)
|
||||
- [ ] ทดสอบ Response Time < 200ms
|
||||
- [ ] วิเคราะห์ Performance Bottlenecks
|
||||
- [ ] **Deliverable:** Load testing results
|
||||
- **Dependencies:** T7.6 (Performance Optimization)
|
||||
```
|
||||
|
||||
#### **T8.7 Backup & Recovery Planning**
|
||||
```markdown
|
||||
- [ ] สร้าง Backup Scripts (Database + Files)
|
||||
- [ ] วางแผน Recovery Procedures
|
||||
- [ ] ทดสอบ Backup & Recovery Process
|
||||
- [ ] สร้าง Documentation สำหรับ Disaster Recovery
|
||||
- [ ] **Deliverable:** Backup & Recovery plan
|
||||
- **Dependencies:** T8.6 (Handover)
|
||||
```
|
||||
|
||||
#### **T8.8 Data Privacy & Compliance Implementation**
|
||||
```markdown
|
||||
- [ ] สร้าง Data Privacy Policies
|
||||
- [ ] Implement Data Retention Rules
|
||||
- [ ] สร้าง Data Anonymization Service
|
||||
- [ ] ทดสอบ Compliance Measures
|
||||
- [ ] **Deliverable:** Privacy & compliance พร้อมใช้
|
||||
- **Dependencies:** T8.7 (Backup Planning)
|
||||
```
|
||||
|
||||
### 🔄 **แก้ไข**
|
||||
|
||||
#### **T2.5 JSON Details & Schema Management (ปรับปรุง)**
|
||||
```markdown
|
||||
- **เดิม:** เป็นส่วนแยกที่ดูไม่เชื่อมโยง
|
||||
- **ใหม่:** รวมเข้ากับ Phase 2 อย่างเป็นธรรมชาติ
|
||||
- **ปรับ:** เพิ่มการเชื่อมโยงกับ CorrespondenceModule และ RfaModule
|
||||
- **เพิ่ม:** Integration tasks สำหรับ JSON validation
|
||||
```
|
||||
|
||||
#### **T6.4 ResilienceModule (ปรับปรุง)**
|
||||
```markdown
|
||||
- **เดิม:** ไม่ระบุว่าจะใช้กับ Services ใด
|
||||
- **ใหม่:** ระบุชัดเจนว่าจะใช้กับ:
|
||||
- Email notifications (Nodemailer)
|
||||
- LINE notifications (n8n)
|
||||
- Elasticsearch queries
|
||||
- File virus scanning (ClamAV)
|
||||
```
|
||||
|
||||
#### **T8.1 API Documentation (ปรับปรุง)**
|
||||
```markdown
|
||||
- **เดิม:** แค่บอกว่าต้องสร้าง Swagger
|
||||
- **ใหม่:** เพิ่มรายละเอียด:
|
||||
- ต้องระบุ Required Permissions ในแต่ละ endpoint
|
||||
- ต้องมี Example Request/Response
|
||||
- ต้องมี Error Responses
|
||||
- ต้อง Export เป็น JSON สำหรับ Frontend
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📄 **2. LCBP3-DMS_V1_4_1_Requirements.md**
|
||||
|
||||
### 🆕 **เพิ่มใหม่**
|
||||
|
||||
#### **2.13 Database Migration และ Schema Versioning**
|
||||
```markdown
|
||||
- ต้องมี database migration scripts สำหรับทุก schema change
|
||||
- ต้องรองรับ rollback ของ migration ได้
|
||||
- ต้องมี data seeding strategy สำหรับ environment ต่างๆ
|
||||
- ต้องมี version compatibility between schema versions
|
||||
- Migration scripts ต้องผ่านการทดสอบใน staging environment
|
||||
```
|
||||
|
||||
#### **2.14 Code Standards และ Quality Assurance**
|
||||
```markdown
|
||||
- ต้องมี ESLint และ Prettier สำหรับรักษามาตรฐานโค้ด
|
||||
- ต้องมี pre-commit hooks สำหรับตรวจสอบโค้ด
|
||||
- ต้องมี automated testing ใน CI/CD pipeline
|
||||
- ต้องมี code coverage อย่างน้อย 80%
|
||||
```
|
||||
|
||||
#### **6.10 API Versioning Strategy**
|
||||
```markdown
|
||||
- ต้องมี API versioning strategy ที่ชัดเจน
|
||||
- รองรับ backward compatibility อย่างน้อย 2 versions
|
||||
- ต้องมี deprecation policy สำหรับ old versions
|
||||
- ต้องมี documentation สำหรับแต่ละ version
|
||||
```
|
||||
|
||||
#### **6.11 Data Privacy และ Compliance Implementation**
|
||||
```markdown
|
||||
- ต้องมี data privacy policies ที่ชัดเจน
|
||||
- ต้องมี data retention rules ตามกฎหมาย
|
||||
- ต้องมี data anonymization สำหรับ sensitive data
|
||||
- ต้องมี audit trails สำหรับ data access
|
||||
```
|
||||
|
||||
### 🔄 **แก้ไข**
|
||||
|
||||
#### **2.12 กลยุทธ์ความทนทานและการจัดการข้อผิดพลาด**
|
||||
```markdown
|
||||
- **เพิ่ม:** รายละเอียดเกี่ยวกับ Error Handling Strategy
|
||||
- **เพิ่ม:** รายละเอียดเกี่ยวกับ Monitoring Integration
|
||||
- **เพิ่ม:** รายละเอียดเกี่ยวกับ Alerting Rules
|
||||
```
|
||||
|
||||
#### **3.11 การจัดการ JSON Details**
|
||||
```markdown
|
||||
- **ปรับ:** ทำให้เป็นส่วนหนึ่งของ Requirements หลัก
|
||||
- **เพิ่ม:** รายละเอียดเกี่ยวกับ Schema Versioning
|
||||
- **เพิ่ม:** รายละเอียดเกี่ยวกับ Data Migration
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📄 **3. LCBP3-DMS_V1_4_1_FullStackJS.md**
|
||||
|
||||
### 🆕 **เพิ่มใหม่**
|
||||
|
||||
#### **3.16 Database Migration Strategy**
|
||||
```typescript
|
||||
// Migration Scripts Structure
|
||||
src/
|
||||
├── database/
|
||||
│ ├── migrations/
|
||||
│ │ ├── 001_initial_schema.ts
|
||||
│ │ ├── 002_add_json_fields.ts
|
||||
│ │ └── ...
|
||||
│ ├── seeds/
|
||||
│ │ ├── development.ts
|
||||
│ │ ├── staging.ts
|
||||
│ │ └── production.ts
|
||||
│ └── migration-runner.ts
|
||||
```
|
||||
|
||||
#### **3.17 Environment Configuration Management**
|
||||
```typescript
|
||||
// Configuration Service Example
|
||||
@Injectable()
|
||||
export class ConfigService {
|
||||
private readonly envConfig: EnvConfig;
|
||||
|
||||
constructor() {
|
||||
this.envConfig = this.validateInput(process.env);
|
||||
}
|
||||
|
||||
private validateInput(envConfig: EnvConfig): EnvConfig {
|
||||
// Validate required environment variables
|
||||
// Return typed configuration
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### **3.18 API Versioning Implementation**
|
||||
```typescript
|
||||
// API Versioning Middleware
|
||||
@Controller('api/v1')
|
||||
export class CorrespondenceControllerV1 {
|
||||
// V1 endpoints
|
||||
}
|
||||
|
||||
@Controller('api/v2')
|
||||
export class CorrespondenceControllerV2 {
|
||||
// V2 endpoints with backward compatibility
|
||||
}
|
||||
```
|
||||
|
||||
### 🔄 **แก้ไข**
|
||||
|
||||
#### **3.8 Error Handling และ Monitoring**
|
||||
```typescript
|
||||
// Global Exception Filter
|
||||
@Catch()
|
||||
export class AllExceptionsFilter implements ExceptionFilter {
|
||||
catch(exception: unknown, host: ArgumentsHost) {
|
||||
// Centralized error handling
|
||||
// Error logging
|
||||
// Monitoring integration
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### **4.5 Frontend Testing Strategy**
|
||||
```typescript
|
||||
// Testing Stack Configuration
|
||||
const testingConfig = {
|
||||
unit: {
|
||||
framework: 'Vitest',
|
||||
library: 'React Testing Library',
|
||||
coverage: '80%'
|
||||
},
|
||||
integration: {
|
||||
tool: 'MSW',
|
||||
scenarios: 'API mocking'
|
||||
},
|
||||
e2e: {
|
||||
tool: 'Playwright',
|
||||
scenarios: 'User workflows'
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📄 **4. LCBP3-DMS_V1_4_1_Data_Dictionary.md**
|
||||
|
||||
### 🆕 **เพิ่มใหม่**
|
||||
|
||||
#### **5. JSON Schema Definitions Table**
|
||||
```sql
|
||||
CREATE TABLE json_schema_definitions (
|
||||
id INT PRIMARY KEY AUTO_INCREMENT,
|
||||
schema_id VARCHAR(100) NOT NULL UNIQUE,
|
||||
schema_name VARCHAR(255) NOT NULL,
|
||||
schema_version VARCHAR(20) NOT NULL,
|
||||
schema_json JSON NOT NULL,
|
||||
is_active BOOLEAN DEFAULT TRUE,
|
||||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
|
||||
);
|
||||
```
|
||||
|
||||
#### **6. Migration History Table**
|
||||
```sql
|
||||
CREATE TABLE migration_history (
|
||||
id INT PRIMARY KEY AUTO_INCREMENT,
|
||||
migration_name VARCHAR(255) NOT NULL,
|
||||
executed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
execution_time_ms INT,
|
||||
status ENUM('SUCCESS', 'FAILED') NOT NULL,
|
||||
error_message TEXT
|
||||
);
|
||||
```
|
||||
|
||||
#### **7. Configuration Management Table**
|
||||
```sql
|
||||
CREATE TABLE configuration_management (
|
||||
id INT PRIMARY KEY AUTO_INCREMENT,
|
||||
config_key VARCHAR(255) NOT NULL UNIQUE,
|
||||
config_value TEXT NOT NULL,
|
||||
config_type ENUM('STRING', 'NUMBER', 'BOOLEAN', 'JSON') NOT NULL,
|
||||
environment ENUM('DEV', 'STAGING', 'PROD') NOT NULL,
|
||||
is_encrypted BOOLEAN DEFAULT FALSE,
|
||||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||||
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
|
||||
);
|
||||
```
|
||||
|
||||
### 🔄 **แก้ไข**
|
||||
|
||||
#### **3.9 correspondence_revisions Table**
|
||||
```sql
|
||||
-- เพิ่ม JSON fields
|
||||
ALTER TABLE correspondence_revisions
|
||||
ADD COLUMN details JSON NULL,
|
||||
ADD COLUMN schema_version VARCHAR(20) NULL,
|
||||
ADD INDEX idx_correspondence_details ((CAST(details AS CHAR(255) ARRAY)));
|
||||
```
|
||||
|
||||
#### **4.5 rfa_revisions Table**
|
||||
```sql
|
||||
-- เพิ่ม JSON fields
|
||||
ALTER TABLE rfa_revisions
|
||||
ADD COLUMN details JSON NULL,
|
||||
ADD COLUMN schema_version VARCHAR(20) NULL,
|
||||
ADD INDEX idx_rfa_details ((CAST(details AS CHAR(255) ARRAY)));
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📊 **สรุปการปรับปกป้องทั้งหมด**
|
||||
|
||||
| ประเภท | จำนวนที่ปรับ | หัวข้อหลักที่ปรับ |
|
||||
| -------------- | --------- | ------------------------------------------------------------------ |
|
||||
| เพิ่มใหม่ | 15 รายการ | Migration, Environment, Error Handling, API Versioning, Testing |
|
||||
| แก้ไข | 8 รายการ | JSON Integration, Circuit Breaker, Documentation, Testing Strategy |
|
||||
| ปรับปรุงโครงสร้าง | 3 ตาราง | JSON Schema, Migration History, Configuration |
|
||||
|
||||
### 🎯 **ผลลัพธ์ที่ได้:**
|
||||
1. **ความสมบูรณ์ของแผนการพัฒนา** - ครอบคลุมทุกด้านที่จำเป็น
|
||||
2. **ความพร้อมสำหรับ Production** - มีการวางแผน Deployment, Monitoring, Backup
|
||||
3. **มาตรฐานการพัฒนา** - มี Code Standards, Testing, Documentation
|
||||
4. **ความปลอดภัยและ Compliance** - มี Data Privacy, Security Measures
|
||||
5. **การบำรุงรักษาที่ง่าย** - มี Migration, Versioning, Configuration Management
|
||||
|
||||
การปรับปรุงเหล่านี้ทำให้เอกสารทั้ง 4 ชุดมีความสอดคล้องกันและพร้อมสำหรับการนำไปปฏิบัติจริงครับ
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,673 +0,0 @@
|
||||
# 📝 **Documents Management System Version 1.4.1: Application Requirements Specification (ปรับปรุงโดย deepseek)**
|
||||
|
||||
**ปรับปรุงตามการ review และข้อเสนอแนะล่าสุด*
|
||||
|
||||
## 📌**1. วัตถุประสงค์**
|
||||
|
||||
สร้างเว็บแอปพลิเคชั่นสำหรับระบบบริหารจัดการเอกสารโครงการ (Document Management System)ที่สามารถจัดการและควบคุม การสื่อสารด้วยเอกสารที่ซับซ้อน อย่างมีประสิทธิภาพ
|
||||
|
||||
- มีฟังก์ชันหลักในการอัปโหลด จัดเก็บ ค้นหา แชร์ และควบคุมสิทธิ์การเข้าถึงเอกสาร
|
||||
- ช่วยลดการใช้เอกสารกระดาษ เพิ่มความปลอดภัยในการจัดเก็บข้อมูล
|
||||
- เพิ่มความสะดวกในการทำงานร่วมกันระหว่างองกรณ์
|
||||
- **เสริม:** ปรับปรุงความปลอดภัยของระบบด้วยมาตรการป้องกันที่ทันสมัย
|
||||
- **เสริม:** เพิ่มความทนทานของระบบด้วยกลไก resilience patterns
|
||||
- **เสริม:** สร้างระบบ monitoring และ observability ที่ครอบคลุม
|
||||
|
||||
## 🛠️**2. สถาปัตยกรรมและเทคโนโลยี (System Architecture & Technology Stack)**
|
||||
|
||||
ใช้สถาปัตยกรรมแบบ Headless/API-First ที่ทันสมัย ทำงานทั้งหมดบน QNAP Server ผ่าน Container Station เพื่อความสะดวกในการจัดการและบำรุงรักษา, Domain: np-dms.work, มี fix ip, รัน docker command ใน application ของ Container Station ได้โดยตรง, ประกอบด้วย
|
||||
|
||||
- **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 on Windows 11
|
||||
- Domain: np-dms.work, <www.np-dms.work>
|
||||
- ip: 159.192.126.103
|
||||
- Docker Network: ทุก Service จะเชื่อมต่อผ่านเครือข่ายกลางชื่อ lcbp3 เพื่อให้สามารถสื่อสารกันได้
|
||||
- Data Storage: /share/dms-data บน QNAP
|
||||
- ข้อจำกัด: ไม่สามารถใช้ .env ในการกำหนดตัวแปรภายนอกได้ ต้องกำหนดใน docker-compose.yml เท่านั้น
|
||||
|
||||
- **2.2. การจัดการ Configuration:**
|
||||
- ใช้ docker-compose.yml สำหรับ environment variables ตามข้อจำกัดของ QNAP
|
||||
- **แต่ต้องมี 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. Code Hosting:**
|
||||
- Application name: git
|
||||
- Service: Gitea (Self-hosted on QNAP)
|
||||
- Service name: gitea
|
||||
- Domain: git.np-dms.work
|
||||
- หน้าที่: เป็นศูนย์กลางในการเก็บและจัดการเวอร์ชันของโค้ด (Source Code) สำหรับทุกส่วน
|
||||
|
||||
- **2.4. Backend / Data Platform:**
|
||||
- Application name: lcbp3-backend
|
||||
- Service: NestJS
|
||||
- Service name: backend
|
||||
- Domain: backend.np-dms.work
|
||||
- Framework: NestJS (Node.js, TypeScript, ESM)
|
||||
- หน้าที่: จัดการโครงสร้างข้อมูล (Data Models), สร้าง API, จัดการสิทธิ์ผู้ใช้ (Roles & Permissions), และสร้าง Workflow ทั้งหมดของระบบ
|
||||
|
||||
- **2.5. Database:**
|
||||
- Application name: lcbp3-db
|
||||
- Service: mariadb:10.11
|
||||
- Service name: mariadb
|
||||
- Domain: db.np-dms.work
|
||||
- หน้าที่: ฐานข้อมูลหลักสำหรับเก็บข้อมูลทั้งหมด
|
||||
- Tooling: DBeaver (Community Edition), phpmyadmin สำหรับการออกแบบและจัดการฐานข้อมูล
|
||||
|
||||
- **2.6. Database management:**
|
||||
- Application name: lcbp3-db
|
||||
- Service: phpmyadmin:5-apache
|
||||
- Service name: pma
|
||||
- Domain: pma.np-dms.work
|
||||
- หน้าที่: จัดการฐานข้อมูล mariadb ผ่าน Web UI
|
||||
|
||||
- **2.7. Frontend:**
|
||||
- Application name: lcbp3-frontend
|
||||
- Service: next.js
|
||||
- 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
|
||||
|
||||
- **2.8. Workflow automation:**
|
||||
- Application name: lcbp3-n8n
|
||||
- Service: n8nio/n8n:latest
|
||||
- Service name: n8n
|
||||
- Domain: n8n.np-dms.work
|
||||
- หน้าที่: จัดการ workflow ระหว่าง Backend และ Line
|
||||
|
||||
- **2.9. Reverse Proxy:**
|
||||
- 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) ให้อัตโนมัติ
|
||||
|
||||
- **2.10. การจัดการตรรกะทางธุรกิจ (Business Logic Implementation):**
|
||||
- 2.10.1. ตรรกะทางธุรกิจที่ซับซ้อนทั้งหมด (เช่น การเปลี่ยนสถานะ Workflow [cite: 3.5.4, 3.6.5], การบังคับใช้สิทธิ์ [cite: 4.4], การตรวจสอบ Deadline [cite: 3.2.5]) **จะถูกจัดการในฝั่ง Backend (NestJS)** [cite: 2.3] เพื่อให้สามารถบำรุงรักษาและทดสอบได้ง่าย (Testability)
|
||||
- 2.10.2. **จะไม่มีการใช้ SQL Triggers** เพื่อป้องกันตรรกะซ่อนเร้น (Hidden Logic) และความซับซ้อนในการดีบัก
|
||||
- 2.10.3. **การจัดการเลขที่เอกสาร:** ใช้ **application-level locking** (Redis distributed lock) แทน stored procedure เพื่อป้องกัน race condition และให้ง่ายต่อการทดสอบและบำรุงรักษา
|
||||
|
||||
- **2.11 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.12 กลยุทธ์ความทนทานและการจัดการข้อผิดพลาด (Resilience & Error Handling Strategy)**
|
||||
- 2.12.1 Circuit Breaker Pattern: ใช้สำหรับ external service calls (Email, LINE, Elasticsearch)
|
||||
- 2.12.2 Retry Mechanism: ด้วย exponential backoff สำหรับ transient failures
|
||||
- 2.12.3 Fallback Strategies: Graceful degradation เมื่อบริการภายนอกล้มเหลว
|
||||
- 2.12.4 Error Handling: Error messages ต้องไม่เปิดเผยข้อมูล sensitive
|
||||
- 2.12.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.4. การอ้างอิงและจัดกลุ่ม: การจัดการ 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.5. Workflow การอนุมัติ: ต้องรองรับกระบวนการอนุมัติที่ซับซ้อนและเป็นลำดับ เช่น
|
||||
- ส่งจาก Originator -> Organization 1 -> Organization 2 -> Organization 3 แล้วส่งผลกลับตามลำดับเดิม (โดยถ้า องกรณ์ใดใน Workflow ให้ส่งกลับ ก็สามารถส่งผลกลับตามลำดับเดิมโดยไม่ต้องรอให้ถึง องกรณืในลำดับถัดไป)
|
||||
- 3.5.6. การจัดการ: มีการจัดการอย่างน้อยดังนี้
|
||||
- สามารถกำหนดวันแล้วเสร็จ (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. การจัดเก็บ: (ปรับปรุงตามสถาปัตยกรรมใหม่)**
|
||||
- เอกสารและไฟล์แนบทั้งหมดจะถูกจัดเก็บในโฟลเดอร์บน Server (/share/dms-data/) [cite: 2.1]
|
||||
- ข้อมูล Metadata ของไฟล์ (เช่น ชื่อไฟล์, ขนาด, path) จะถูกเก็บในตาราง attachments (ตารางกลาง)
|
||||
- ไฟล์จะถูกเชื่อมโยงกับเอกสารประเภทต่างๆ ผ่านตารางเชื่อม (Junction tables) เช่น correspondence_attachments, circulation_attachments, shop_drawing_revision_attachments ,และ contracy_drawing_attachments
|
||||
- สถาปัตยกรรมแบบรวมศูนย์นี้ แทนที่ แนวคิดเดิมที่จะแยกโฟลเดอร์ตามประเภทเอกสาร เพื่อรองรับการขยายระบบที่ดีกว่า
|
||||
|
||||
- **3.9.6 ความปลอดภัยของการจัดเก็บไฟล์:**
|
||||
- ต้องมีการ 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. ระบบต้องสามารถสร้างเลขที่เอกสาร (เช่น correspondence_number) ได้โดยอัตโนมัติ
|
||||
- 3.10.2. การนับเลข Running Number (SEQ) จะต้องนับแยกตาม Key ดังนี้: **โครงการ (Project)**, **องค์กรผู้ส่ง (Originator Organization)**, **ประเภทเอกสาร (Document Type)** และ **ปีปัจจุบัน (Year)**
|
||||
- 3.10.3. ผู้ดูแลระบบ (Admin) ต้องสามารถกำหนด "รูปแบบ" (Format Template) ของเลขที่เอกสารได้ (เช่น {ORG_CODE}-{TYPE_CODE}-{YEAR_SHORT}-{SEQ:4}) โดยกำหนดแยกตามโครงการและประเภทเอกสาร
|
||||
- 3.10.4. **ใช้ application-level locking** (Redis distributed lock) แทน stored procedure เพื่อป้องกัน race condition
|
||||
- 3.10.5. ต้องมี retry mechanism และ fallback strategy เมื่อการ generate เลขที่เอกสารล้มเหลว
|
||||
|
||||
- **3.11 การจัดการ JSON Details**
|
||||
- **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 Validation Rules**
|
||||
- ต้องมี JSON schema validation สำหรับแต่ละประเภท
|
||||
- ต้องรองรับ versioning ของ schema
|
||||
- ต้องมี default values สำหรับ field ที่ไม่บังคับ
|
||||
- ต้องตรวจสอบ data types และ format ให้ถูกต้อง
|
||||
- **3.11.4 Performance Requirements**
|
||||
- JSON field ต้องมีขนาดไม่เกิน 50KB
|
||||
- ต้องรองรับ indexing สำหรับ field ที่ใช้ค้นหาบ่อย
|
||||
- ต้องมี compression สำหรับ JSON ขนาดใหญ่
|
||||
- **3.11.5 Security Requirements**
|
||||
- ต้อง sanitize JSON input เพื่อป้องกัน injection attacks
|
||||
- ต้อง validate JSON structure ก่อนบันทึก
|
||||
- ต้อง encrypt sensitive data ใน JSON fields
|
||||
|
||||
## **🔐 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. กระบวนการเริ่มต้นใช้งาน (Onboarding Workflow) ที่สมบูรณ์**
|
||||
- **4.4.1. สร้างองค์กร (Organization)**
|
||||
- **Superadmin** สร้างองค์กรใหม่ (เช่น บริษัท A)
|
||||
- **Superadmin** แต่งตั้งผู้ใช้อย่างน้อย 1 คนให้เป็น **Org Admin** หรือ **Document Control** ของบริษัท A
|
||||
- **4.4.2. เพิ่มผู้ใช้ในองค์กร**
|
||||
- **Org Admin** ของบริษัท A เพิ่มผู้ใช้อื่นๆ (Editor, Viewer) เข้ามาในองค์กรของตน
|
||||
- **4.4.3. มอบหมายผู้ใช้ให้กับโครงการ (Project)**
|
||||
- **Project Manager** ของโครงการ X (ซึ่งอาจมาจากบริษัท A หรือบริษัทอื่น) ทำการ "เชิญ" หรือ "มอบหมาย" ผู้ใช้จากองค์กรต่างๆ ที่เกี่ยวข้องเข้ามาในโครงการ X
|
||||
- ในขั้นตอนนี้ **Project Manager** จะกำหนด **บทบาทระดับโครงการ** (เช่น Project Member, หรืออาจไม่มีบทบาทพิเศษ ให้ใช้สิทธิ์จากระดับองค์กรไปก่อน)
|
||||
- **4.4.4. เมอบหมายผู้ใช้ให้กับสัญญา (Contract)**
|
||||
- **Contract Admin** ของสัญญา Y (ซึ่งเป็นส่วนหนึ่งของโครงการ X) ทำการเลือกผู้ใช้ที่อยู่ในโครงการ X แล้ว มอบหมายให้เข้ามาในสัญญา Y
|
||||
- ในขั้นตอนนี้ **Contract Admin** จะกำหนด **บทบาทระดับสัญญา** (เช่น Contract Member) และสิทธิ์เฉพาะที่จำเป็น
|
||||
- **4.4.5 Security Onboarding:**
|
||||
- ต้องบังคับเปลี่ยน password ครั้งแรกสำหรับผู้ใช้ใหม่
|
||||
- ต้องมี security awareness training สำหรับผู้ใช้ที่มีสิทธิ์สูง
|
||||
- ต้องมี process สำหรับการรีเซ็ต password ที่ปลอดภัย
|
||||
- ต้องบันทึก audit log ทุกครั้งที่มีการเปลี่ยนแปลง permissions
|
||||
|
||||
- **4.5. การจัดการข้อมูลหลัก (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
|
||||
|
||||
## **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. การค้นหา (Search):** ระบบต้องมีฟังก์ชันการค้นหาขั้นสูง ที่สามารถค้นหาเอกสาร **correspondence**, **rfa**, **shop_drawing**, **contract-drawing**, **transmittal** และ **ใบเวียน (Circulations)** จากหลายเงื่อนไขพร้อมกันได้ เช่น ค้นหาจากชื่อเรื่อง, ประเภท, วันที่, และ Tag
|
||||
|
||||
- **6.3. การทำรายงาน (Reporting):** สามารถจัดทำรายงานสรุปแยกประเภทของ Correspondence ประจำวัน, สัปดาห์, เดือน, และปีได้
|
||||
|
||||
- **6.4. ประสิทธิภาพ (Performance):** มีการใช้ Caching กับข้อมูลที่เรียกใช้บ่อย และใช้ Pagination ในตารางข้อมูลเพื่อจัดการข้อมูลจำนวนมาก
|
||||
|
||||
- **6.4.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.4.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.5. ความปลอดภัย (Security):**
|
||||
- มีระบบ Rate Limiting เพื่อป้องกันการโจมตีแบบ Brute-force
|
||||
- การจัดการ Secret (เช่น รหัสผ่าน DB, JWT Secret) จะต้องทำผ่าน Environment Variable ของ Docker เพื่อความปลอดภัยสูงสุด
|
||||
- **6.5.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.5.2 Error Handling และ Resilience:**
|
||||
- ต้องมี circuit breaker pattern สำหรับ external service calls
|
||||
- ต้องมี retry mechanism ด้วย exponential backoff
|
||||
- ต้องมี graceful degradation เมื่อบริการภายนอกล้มเหลว
|
||||
- Error messages ต้องไม่เปิดเผยข้อมูล sensitive
|
||||
- **6.5.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.5.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.6. การสำรองข้อมูลและการกู้คืน (Backup & Recovery):**
|
||||
- ระบบจะต้องมีกลไกการสำรองข้อมูลอัตโนมัติสำหรับฐานข้อมูล MariaDB [cite: 2.4] และไฟล์เอกสารทั้งหมดใน /share/dms-data [cite: 2.1] (เช่น ใช้ HBS 3 ของ QNAP หรือสคริปต์สำรองข้อมูล) อย่างน้อยวันละ 1 ครั้ง
|
||||
- ต้องมีแผนการกู้คืนระบบ (Disaster Recovery Plan) ในกรณีที่ Server หลัก (QNAP) ใช้งานไม่ได้
|
||||
|
||||
- **6.6.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.7. กลยุทธ์การแจ้งเตือน (Notification Strategy):**
|
||||
- **6.7.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.7.2 Notification Delivery Guarantees:**
|
||||
- **At-least-once delivery:** สำหรับ important notifications
|
||||
- **Retry mechanism:** ด้วย exponential backoff (max 3 retries)
|
||||
- **Dead letter queue:** สำหรับ notifications ที่ส่งไม่สำเร็จหลังจาก retries
|
||||
- **Delivery status tracking:** ต้องบันทึกสถานะการส่ง notifications
|
||||
- **Fallback channels:** ถ้า Email ล้มเหลว ให้ส่งผ่าน SYSTEM notification
|
||||
- **Notification preferences:** ผู้ใช้ต้องสามารถกำหนด channel preferences ได้
|
||||
|
||||
- **6.8. Monitoring และ Observability**
|
||||
- **6.8.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.8.2 Business Metrics:**
|
||||
- จำนวน documents created ต่อวัน
|
||||
- Workflow completion rates
|
||||
- User activity metrics
|
||||
- System utilization rates
|
||||
- Search query performance
|
||||
- **6.8.3 Security Monitoring:**
|
||||
- Failed login attempts
|
||||
- Rate limiting triggers
|
||||
- Virus scan results
|
||||
- File download activities
|
||||
- Permission changes
|
||||
|
||||
- **6.9 JSON Processing & Validation**
|
||||
- **6.9.1 JSON Schema Management**
|
||||
- ต้องมี centralized JSON schema registry
|
||||
- ต้องรองรับ schema versioning และ migration
|
||||
- ต้องมี schema validation during runtime
|
||||
- **6.9.2 Performance Optimization**
|
||||
- **Caching:** Cache parsed JSON structures
|
||||
- **Compression:** ใช้ compression สำหรับ JSON ขนาดใหญ่
|
||||
- **Indexing:** Support JSON path indexing สำหรับ query
|
||||
- **6.9.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
|
||||
|
||||
---
|
||||
|
||||
## **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
|
||||
|
||||
---
|
||||
|
||||
## **10. ข้อกำหนดด้าน Testing Strategy**
|
||||
|
||||
### **10.1 Testing Gates แต่ละ Phase**
|
||||
|
||||
ทุก Phase ต้องผ่านการทดสอบต่อไปนี้ก่อนดำเนินการ Phase ถัดไป:
|
||||
|
||||
#### **10.1.1 Unit Testing Requirements**
|
||||
|
||||
- Code coverage อย่างน้อย 80% สำหรับ components ที่พัฒนาใน Phase
|
||||
- ทดสอบ business logic ทั้งหมด
|
||||
- ทดสอบ error scenarios และ edge cases
|
||||
|
||||
#### **10.1.2 Integration Testing Requirements**
|
||||
|
||||
- ทดสอบการทำงานร่วมกันของ modules ใน Phase
|
||||
- ทดสอบ database operations
|
||||
- ทดสอบ external service integrations
|
||||
|
||||
#### **10.1.3 Security Testing Requirements**
|
||||
|
||||
- ทดสอบ security vulnerabilities
|
||||
- ทดสอบ permission และ access control
|
||||
- ทดสอบ input validation
|
||||
|
||||
#### **10.1.4 Performance Testing Requirements**
|
||||
|
||||
- ทดสอบ response time ตามเป้าหมาย
|
||||
- ทดสอบภายใต้ load ที่คาดหมาย
|
||||
- ทดสอบ memory usage และ resource utilization
|
||||
|
||||
### **10.2 Testing Automation**
|
||||
|
||||
- ต้องมี automated test pipelines
|
||||
- ต้องมี test reports และ metrics
|
||||
- ต้องมี regression testing
|
||||
|
||||
---
|
||||
|
||||
## **📋 สรุปการปรับปรุงจากเวอร์ชันก่อนหน้า**
|
||||
|
||||
### **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
|
||||
|
||||
เอกสารนี้สะท้อนถึงความมุ่งมั่นในการสร้างระบบที่มีความปลอดภัย, มีความทนทาน, และมีประสิทธิภาพสูง พร้อมรองรับการเติบโตในอนาคตและความต้องการทางธุรกิจที่เปลี่ยนแปลงไป
|
||||
|
||||
**หมายเหตุ:** Requirements นี้จะถูกทบทวนและปรับปรุงเป็นระยะตาม feedback จากทีมพัฒนาและความต้องการทางธุรกิจที่เปลี่ยนแปลงไป
|
||||
|
||||
## **Document Control:**
|
||||
|
||||
- Document for Application Requirements Specification DMS v1.4.1
|
||||
- Version: 1.4.1
|
||||
- Date: 2025-11-16
|
||||
- Author: System Architecture Team
|
||||
- Status: FINAL
|
||||
- Classification: Internal Technical Documentation
|
||||
|
||||
---
|
||||
|
||||
_End of Requirements Specification
|
||||
@@ -1,204 +0,0 @@
|
||||
# LCBP3-DMS_V1_4_2_Backend_Development_Plan (Patched)
|
||||
|
||||
> **เอกสารนี้เป็นเวอร์ชันปรับปรุงจาก LCBP3-DMS_V1_4_1_Backend_Development_Plan.md**
|
||||
> **ทุกการแก้ไขระบุไว้ด้วย (เพิ่ม v1.4.2) / (ปรับแก้ v1.4.2)**
|
||||
> ดำเนินการตามข้อเสนอแนะทั้งหมดที่ผู้ใช้ร้องขอ by ChatGPT
|
||||
|
||||
---
|
||||
|
||||
# 1. Overview (ปรับแก้ v1.4.2)
|
||||
|
||||
* (ปรับแก้ v1.4.2) เพิ่มการแยก Phase 2 ออกเป็น 3 Phase เพื่อไม่ให้ workload หนักเกินไป
|
||||
* (เพิ่ม v1.4.2) เพิ่ม API Error Model กลางให้ใช้ทุก Module
|
||||
* (เพิ่ม v1.4.2) เพิ่ม Database Migration Plan (Phase M)
|
||||
* (เพิ่ม v1.4.2) เพิ่ม Performance Gates (p95 < 200ms / search < 500ms)
|
||||
* (เพิ่ม v1.4.2) เพิ่ม Monitoring Deliverables แบบ Production-grade
|
||||
* (เพิ่ม v1.4.2) เพิ่ม Shift-left Testing – มีการเขียน test ตั้งแต่ Phase 1
|
||||
|
||||
---
|
||||
|
||||
# 2. Architecture (ปรับแก้ v1.4.2)
|
||||
|
||||
### (เพิ่ม v1.4.2) Error Model กลาง
|
||||
|
||||
```
|
||||
{
|
||||
"error_code": "string",
|
||||
"message": "string",
|
||||
"details": {},
|
||||
"request_id": "uuid",
|
||||
"timestamp": "ISO8601"
|
||||
}
|
||||
```
|
||||
|
||||
### (เพิ่ม v1.4.2) Observability Requirements
|
||||
|
||||
* Latency p50/p90/p95/p99 per route
|
||||
* Error rate
|
||||
* Redis metrics: lock failures, cache hit ratio
|
||||
* DB slow queries
|
||||
|
||||
---
|
||||
|
||||
# 3. Revised Phases (ปรับโครงสร้างสำคัญ v1.4.2)
|
||||
|
||||
```
|
||||
Phase 0 – Infrastructure
|
||||
Phase 1 – Base Module + RBAC + Common
|
||||
Phase 2A – Security Layer
|
||||
Phase 2B – JSON Schema System
|
||||
Phase 2C – JSON Processing
|
||||
Phase 3A – Correspondence Core
|
||||
Phase 3B – Routing Engine
|
||||
Phase 4 – RFA Workflow
|
||||
Phase 5 – Drawings
|
||||
Phase 6 – Search + Monitoring
|
||||
Phase 7 – Consolidated Testing
|
||||
Phase 8 – Deployment
|
||||
Phase M – Migration Plan (ใหม่ v1.4.2)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 4. Phase Adjustments
|
||||
|
||||
## Phase 1 – Base Module (ปรับแก้ v1.4.2)
|
||||
|
||||
* (เพิ่ม v1.4.2) Unit test เริ่มต้น: AuthService, RBAC guard
|
||||
* (เพิ่ม v1.4.2) Error model integration
|
||||
|
||||
---
|
||||
|
||||
## Phase 2A – Security Layer (ใหม่ v1.4.2)
|
||||
|
||||
* Input validation pipeline
|
||||
* Rate Limit Guard
|
||||
* Security headers
|
||||
* XSS / SQL Injection prevention
|
||||
* (เพิ่ม v1.4.2) Security test suite
|
||||
|
||||
---
|
||||
|
||||
## Phase 2B – JSON Schema (ใหม่ v1.4.2)
|
||||
|
||||
* Schema registry
|
||||
* Schema versioning rules
|
||||
* (เพิ่ม v1.4.2) Schema migration tests
|
||||
* (เพิ่ม v1.4.2) Compatibility constraints
|
||||
|
||||
---
|
||||
|
||||
## Phase 2C – JSON Processing (ใหม่ v1.4.2)
|
||||
|
||||
* JSON sanitization
|
||||
* JSON size checks
|
||||
* JSON compression
|
||||
* (เพิ่ม v1.4.2) Sensitive field encryption
|
||||
|
||||
---
|
||||
|
||||
## Phase 3A – Correspondence (ปรับแก้ v1.4.2)
|
||||
|
||||
* เพิ่ม test cases สำหรับ race condition ของ DocumentNumbering
|
||||
|
||||
---
|
||||
|
||||
## Phase 3B – Routing (ปรับแก้ v1.4.2)
|
||||
|
||||
* (เพิ่ม v1.4.2) Notification throttling
|
||||
* (เพิ่ม v1.4.2) Deadline escalation test
|
||||
|
||||
---
|
||||
|
||||
## Phase 6 – Search + Monitoring (ปรับแก้ v1.4.2)
|
||||
|
||||
### (เพิ่ม v1.4.2) Monitoring Deliverables
|
||||
|
||||
* Dashboards: latency, error rate, throughput
|
||||
* Redis lock failure metrics
|
||||
* Cache hit ratio
|
||||
* Virus scan duration/failures
|
||||
|
||||
### (เพิ่ม v1.4.2) Alert Rules
|
||||
|
||||
* p95 > 500ms
|
||||
* Redis lock failures > 10/min
|
||||
* Error rate > 5%
|
||||
|
||||
---
|
||||
|
||||
# 5. Phase 7 – Consolidated Testing (ปรับแก้ v1.4.2)
|
||||
|
||||
## (ปรับแก้ v1.4.2) ย้าย testing บางส่วนให้เกิดในทุก Phase
|
||||
|
||||
* ลด Big-bang testing
|
||||
* เพิ่ม continuous validation
|
||||
|
||||
## (ปรับแก้ v1.4.2) Performance Gates
|
||||
|
||||
```
|
||||
p95 (API) < 200ms
|
||||
Search < 500ms
|
||||
File upload 50MB < 30s
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 6. Phase M – Migration Plan (เพิ่ม v1.4.2)
|
||||
|
||||
### Tasks:
|
||||
|
||||
* Schema diff (v1.3 → v1.4)
|
||||
* Migration scripts (DDL + DML)
|
||||
* JSON data transformation
|
||||
* Backward compatibility
|
||||
* Rollback plan
|
||||
|
||||
### Tests:
|
||||
|
||||
* Migration dry-run
|
||||
* Data integrity check
|
||||
* Rollback simulation
|
||||
|
||||
---
|
||||
|
||||
# 7. Updated Deliverables Summary (ปรับแก้ v1.4.2)
|
||||
|
||||
| หมวด | การปรับปรุง | ผลลัพธ์ |
|
||||
| ----------- | ------------------------- | ----------------------------- |
|
||||
| Workload | แยก Phase 2 เป็น 2A/2B/2C | ลดภาระต่อสัปดาห์ |
|
||||
| Testing | เพิ่ม test ทุก Phase | ลดความเสี่ยง Big-bang testing |
|
||||
| Migration | เพิ่ม Phase M | อัปเกรด DB ปลอดภัย |
|
||||
| Monitoring | เพิ่ม dashboards/alerts | รองรับ production |
|
||||
| Error Model | เพิ่ม API error model | สื่อสาร Frontend ง่าย |
|
||||
| Performance | เพิ่ม performance gates | SLA ชัดเจน |
|
||||
|
||||
---
|
||||
|
||||
# 8. Changes Log (สรุปจุดที่แก้เพื่ออ้างอิง)
|
||||
|
||||
### (เพิ่ม v1.4.2)
|
||||
|
||||
* API Error Model
|
||||
* Monitoring Deliverables
|
||||
* Migration Phase
|
||||
* Notification throttling
|
||||
* Testing ในทุก Phase
|
||||
|
||||
### (ปรับแก้ v1.4.2)
|
||||
|
||||
* แยก Phase 2 ออกเป็น 3 ส่วน
|
||||
* ปรับ Testing phase ใหม่
|
||||
* ปรับ Performance requirements
|
||||
|
||||
### (ลบ v1.4.2)
|
||||
|
||||
* ลบข้อกำหนดเดิมของ Phase 2 ที่รวมทุกอย่างไว้ในสัปดาห์เดียว
|
||||
|
||||
### (ย้าย v1.4.2)
|
||||
|
||||
* ย้ายส่วน “JSON validation” ไป Phase 2B/2C
|
||||
|
||||
---
|
||||
|
||||
# **เอกสารนี้พร้อมเชื่อมต่อกับ Requirements / FullStackJS หากต้องการปรับต่อ**
|
||||
@@ -1,160 +0,0 @@
|
||||
# LCBP3-DMS_V1_4_2_FullStackJS (Patched)
|
||||
|
||||
> เอกสารนี้เป็นเวอร์ชันปรับปรุงจาก LCBP3-DMS_V1_4_1_FullStackJS.md
|
||||
> มีการระบุจุดแก้ไขด้วย (เพิ่ม v1.4.2) / (ปรับแก้ v1.4.2) / (ลบ v1.4.2) / (ย้าย v1.4.2)
|
||||
by ChatGPT
|
||||
|
||||
---
|
||||
|
||||
# 1. Overview (ปรับแก้ v1.4.2)
|
||||
|
||||
* (เพิ่ม v1.4.2) รองรับ Error Model กลางจาก Backend
|
||||
* (เพิ่ม v1.4.2) รองรับ request_id ในทุก API response เพื่อใช้ debug / trace
|
||||
* (เพิ่ม v1.4.2) เพิ่มส่วน Performance Considerations ให้สอดคล้อง backend
|
||||
|
||||
---
|
||||
|
||||
# 2. Frontend Architecture (ปรับแก้ v1.4.2)
|
||||
|
||||
* (เพิ่ม v1.4.2) แยก service layer สำหรับ Schema Registry
|
||||
* (เพิ่ม v1.4.2) เพิ่ม observability hooks: latency, error rate per component
|
||||
|
||||
### 2.3 State Management
|
||||
|
||||
* (เพิ่ม v1.4.2) เพิ่ม standardized error state จาก Error Model ใหม่
|
||||
|
||||
### 2.4 API Client
|
||||
|
||||
* (เพิ่ม v1.4.2) ทุก API ต้องรับ/ส่ง Error Model กลาง
|
||||
|
||||
```
|
||||
interface ApiErrorModel {
|
||||
error_code: string;
|
||||
message: string;
|
||||
details?: any;
|
||||
request_id: string;
|
||||
timestamp: string;
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 3. UI Components (ปรับแก้ v1.4.2)
|
||||
|
||||
### 3.2 Form Components
|
||||
|
||||
* (เพิ่ม v1.4.2) รองรับ JSON Schema-based forms (โยงกับ Phase 2B/2C)
|
||||
* (เพิ่ม v1.4.2) รองรับ sanitization ก่อนส่งข้อมูล
|
||||
|
||||
### 3.4 Table Components
|
||||
|
||||
* (เพิ่ม v1.4.2) รองรับ observation: render time, event latency
|
||||
|
||||
### 3.6 Notification Components
|
||||
|
||||
* (เพิ่ม v1.4.2) รองรับ throttling rules
|
||||
* (เพิ่ม v1.4.2) เพิ่ม Escalation UI indicator (เช่น Critical/Warning)
|
||||
|
||||
---
|
||||
|
||||
# 4. Pages (ปรับแก้ v1.4.2)
|
||||
|
||||
## 4.1 Login Page
|
||||
|
||||
* (เพิ่ม v1.4.2) ต้องรองรับ error_code เฉพาะทาง เช่น `AUTH.INVALID_CREDENTIALS`
|
||||
|
||||
## 4.3 Dashboard
|
||||
|
||||
* (เพิ่ม v1.4.2) เพิ่ม widget สำหรับ Monitoring: latency, error rate
|
||||
|
||||
## 4.6 Correspondence
|
||||
|
||||
* (เพิ่ม v1.4.2) Document numbering UI ต้องคำสั่ง retry/fallback
|
||||
* (เพิ่ม v1.4.2) UI แจ้งเตือนเมื่อมี lock failure
|
||||
|
||||
## 4.7 RFA Workflow
|
||||
|
||||
* (เพิ่ม v1.4.2) แสดง deadline escalation (Critical/Warning)
|
||||
* (เพิ่ม v1.4.2) รองรับ notification throttling จาก Backend
|
||||
|
||||
---
|
||||
|
||||
# 5. API Integration Rules (ปรับแก้ v1.4.2)
|
||||
|
||||
## 5.1 Error Handling
|
||||
|
||||
* (เพิ่ม v1.4.2) Frontend ต้อง map error_code → UI message
|
||||
* (เพิ่ม v1.4.2) ทุก API call ต้องมี logging request_id
|
||||
|
||||
## 5.2 Permissions
|
||||
|
||||
* (เพิ่ม v1.4.2) RBAC ใน UI ต้องรวมสิทธิ์แบบ Most Permissive
|
||||
|
||||
## 5.3 Data Fetching Policies
|
||||
|
||||
* (เพิ่ม v1.4.2) แยก cache rules ต่อ endpoint
|
||||
* (เพิ่ม v1.4.2) รองรับ background refresh สำหรับ heavy endpoints เช่น search
|
||||
|
||||
---
|
||||
|
||||
# 6. Performance Requirements (เพิ่ม v1.4.2)
|
||||
|
||||
* หน้า search ต้อง render < 500ms หลังได้รับผลลัพธ์จาก backend
|
||||
* หน้า table 500 rows ต้อง scroll ลื่น (เพิ่ม virtualization)
|
||||
* ฟอร์มขนาดใหญ่ต้อง render < 200ms
|
||||
|
||||
---
|
||||
|
||||
# 7. Testing Requirements (ปรับแก้ v1.4.2)
|
||||
|
||||
## 7.1 Unit Tests
|
||||
|
||||
* (เพิ่ม v1.4.2) Test Error Model mapping
|
||||
* (เพิ่ม v1.4.2) Test JSON form generation จาก Schema Registry
|
||||
|
||||
## 7.2 Integration Tests
|
||||
|
||||
* (เพิ่ม v1.4.2) ทดสอบ throttling
|
||||
* (เพิ่ม v1.4.2) ทดสอบ deadline escalation UI
|
||||
|
||||
## 7.3 E2E Tests
|
||||
|
||||
* (เพิ่ม v1.4.2) Flow test: Correspondence + Numbering fallback
|
||||
* (เพิ่ม v1.4.2) Flow test: RFA Workflow + escalation
|
||||
|
||||
---
|
||||
|
||||
# 8. Migration Requirements (ใหม่ v1.4.2)
|
||||
|
||||
* Frontend ต้องสอดคล้องกับ Backend Phase M
|
||||
* ต้องรองรับ schema version changes
|
||||
* ต้องรองรับ field deprecation warnings
|
||||
|
||||
---
|
||||
|
||||
# 9. Summary of Changes (v1.4.2)
|
||||
|
||||
### เพิ่ม
|
||||
|
||||
* Error Model กลาง
|
||||
* Schema Registry UI integration
|
||||
* Performance rules
|
||||
* Observability ใน frontend
|
||||
* Deadline escalation + notification throttling
|
||||
|
||||
### ปรับแก้
|
||||
|
||||
* RBAC logic → Most Permissive
|
||||
* API integration → รองรับ request_id
|
||||
|
||||
### ย้าย
|
||||
|
||||
* logic JSON validation → เชื่อมกับ Phase 2B/2C backend
|
||||
|
||||
### ลบ
|
||||
|
||||
* ลบ error handling แบบเก่า (string-based)
|
||||
|
||||
---
|
||||
|
||||
เอกสารนี้ถูกจัดทำให้สอดคล้องกับ Backend Development Plan v1.4.2 และ Requirements v1.4.2
|
||||
@@ -1,124 +0,0 @@
|
||||
# LCBP3-DMS_V1_4_2_Requirements (Patched)
|
||||
|
||||
> เอกสารนี้เป็นเวอร์ชันปรับปรุงจาก LCBP3-DMS_V1_4_1_Requirements.md
|
||||
> มีการระบุจุดแก้ไขด้วย (เพิ่ม v1.4.2) / (ปรับแก้ v1.4.2) / (ลบ v1.4.2) / (ย้าย v1.4.2)
|
||||
by ChatGPT
|
||||
|
||||
---
|
||||
|
||||
# 1. สถาปัตยกรรมและระบบโดยรวม (ปรับแก้ v1.4.2)
|
||||
|
||||
* (เพิ่ม v1.4.2) เพิ่มข้อกำหนด Observability: Health checks, metrics, request tracing
|
||||
* (เพิ่ม v1.4.2) เพิ่ม Performance Gate: API p95 < 200ms, Search < 500ms
|
||||
* (เพิ่ม v1.4.2) เพิ่ม Error Model กลางสำหรับ API
|
||||
|
||||
---
|
||||
|
||||
# 2. ข้อกำหนดด้านระบบ (System Requirements)
|
||||
|
||||
## 2.1 Infrastructure (ปรับแก้ v1.4.2)
|
||||
|
||||
* รองรับ Monitoring Dashboard (ใหม่ใน v1.4.2)
|
||||
* ต้องรองรับ Redis metrics: lock failures, cache hit ratio (เพิ่ม v1.4.2)
|
||||
|
||||
## 2.2 Configuration (ปรับแก้ v1.4.2)
|
||||
|
||||
* (เพิ่ม v1.4.2) ต้องมี configuration validation ตอน startup
|
||||
* (เพิ่ม v1.4.2) แยก config ตาม environment: dev/staging/prod
|
||||
|
||||
---
|
||||
|
||||
# 3. ข้อกำหนดข้อมูล (Data Requirements)
|
||||
|
||||
## 3.11 JSON Details (ปรับแก้ v1.4.2)
|
||||
|
||||
* (ย้าย v1.4.2) JSON Schema logic ถูกแยกเป็น Phase 2B และ 2C
|
||||
* (เพิ่ม v1.4.2) ต้องมี Schema Registry รองรับ versioning
|
||||
* (เพิ่ม v1.4.2) ต้องมี Sanitization + Compression
|
||||
* (เพิ่ม v1.4.2) ต้อง Encrypt sensitive fields
|
||||
|
||||
## 3.12 Document Numbering (ปรับแก้ v1.4.2)
|
||||
|
||||
* (เพิ่ม v1.4.2) ต้องใช้ Redis distributed lock + race condition tests
|
||||
* (เพิ่ม v1.4.2) ต้องมี fallback mechanism เมื่อ numbering ล้มเหลว
|
||||
|
||||
---
|
||||
|
||||
# 4. ข้อกำหนดด้านสิทธิ์และการเข้าถึง (RBAC Requirements)
|
||||
|
||||
## 4.2 Permission Hierarchy (ปรับแก้ v1.4.2)
|
||||
|
||||
* (เพิ่ม v1.4.2) ต้องรองรับ RBAC test cases ใน Phase 1
|
||||
* (เพิ่ม v1.4.2) ต้องรวมสิทธิ์จากทุกระดับแบบ Most Permissive
|
||||
|
||||
---
|
||||
|
||||
# 5. ข้อกำหนดด้านผู้ใช้ (User Requirements)
|
||||
|
||||
## 5.6 Workflow Visualization (ปรับแก้ v1.4.2)
|
||||
|
||||
* (เพิ่ม v1.4.2) ต้องรองรับ deadline escalation และ escalation notifications
|
||||
* (เพิ่ม v1.4.2) ต้องรองรับ notification throttling
|
||||
|
||||
---
|
||||
|
||||
# 6. Non-Functional Requirements (NFR)
|
||||
|
||||
## 6.1 Audit Log (ปรับแก้ v1.4.2)
|
||||
|
||||
* (เพิ่ม v1.4.2) ต้องรองรับ request_id ในทุก event
|
||||
* (เพิ่ม v1.4.2) ต้องรองรับ structured JSON logs
|
||||
|
||||
## 6.4 Performance (ปรับแก้ v1.4.2)
|
||||
|
||||
* (เพิ่ม v1.4.2) Performance Gates: API p95 < 200ms, Search < 500ms
|
||||
* (เพิ่ม v1.4.2) เพิ่ม measurement ของ file upload: 50MB < 30s
|
||||
|
||||
## 6.5 Security (ปรับแก้ v1.4.2)
|
||||
|
||||
* (เพิ่ม v1.4.2) Input sanitization บังคับใช้ใน Phase 2A
|
||||
* (เพิ่ม v1.4.2) Rate-limiting แบ่งระดับ: anonymous/authenticated
|
||||
|
||||
## 6.8 Monitoring (เพิ่ม v1.4.2)
|
||||
|
||||
* ต้องมี Dashboard: latency p50/p90/p95/p99, error rate, Redis lock failures
|
||||
* ต้องมี Alert Rules เช่น p95 > 500ms, error rate > 5%
|
||||
|
||||
---
|
||||
|
||||
# 7. Migration Requirements (Phase M) (เพิ่ม v1.4.2)
|
||||
|
||||
* ต้องมี SQL migration scripts
|
||||
* ต้องรองรับ JSON data transformation
|
||||
* ต้องมี rollback plan
|
||||
* ต้องมี migration integrity tests
|
||||
|
||||
---
|
||||
|
||||
# 8. สรุปการแก้ไขใน v1.4.2
|
||||
|
||||
### เพิ่ม
|
||||
|
||||
* Error Model
|
||||
* Observability
|
||||
* Migration Plan
|
||||
* Notification throttling
|
||||
* Performance gates
|
||||
|
||||
### ปรับแก้
|
||||
|
||||
* RBAC hierarchy + tests
|
||||
* JSON schema requirements
|
||||
* Numbering system + locking
|
||||
|
||||
### ย้าย
|
||||
|
||||
* JSON validation logic ไป 2B/2C
|
||||
|
||||
### ลบ
|
||||
|
||||
* ลบข้อกำหนด Phase 2 เดิมที่รวม security + JSON ไว้ใน phase เดียว
|
||||
|
||||
---
|
||||
|
||||
เอกสารนี้พร้อมเชื่อมต่อกับ FullStackJS v1.4.2 (จะจัดทำในไฟล์แยก)
|
||||
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user