From eff0169c215c99e97ca627b4caaf723e28507d34 Mon Sep 17 00:00:00 2001 From: admin Date: Sun, 30 Nov 2025 01:38:15 +0700 Subject: [PATCH] 251130:0000 1.4.5 Update Backend&Frontend Plan --- 0_Requirements_V1_4_5.md | 655 +++++++++++++++++++++------------------ 1_FullStackJS_V1_4_5.md | 229 +++++++++++--- frontend.0/package.json | 44 --- 3 files changed, 528 insertions(+), 400 deletions(-) delete mode 100644 frontend.0/package.json diff --git a/0_Requirements_V1_4_5.md b/0_Requirements_V1_4_5.md index 64cac50..d94491e 100644 --- a/0_Requirements_V1_4_5.md +++ b/0_Requirements_V1_4_5.md @@ -111,15 +111,25 @@ ### **2.4 Business Logic & Consistency (ปรับปรุง):** -- **2.4.1 Unified Workflow Engine (หลัก):** ระบบการเดินเอกสารทั้งหมด (Correspondence, RFA, Circulation) ต้อง ใช้ Engine กลางเดียวกัน โดยกำหนด Logic ผ่าน Workflow DSL (JSON Configuration) แทนการเขียน Hard-coded ลงในตาราง +- **2.4.1 Unified Workflow Engine (หลัก):** -- **2.4.2 Separation of Concerns:** Module ต่างๆ (RFA, Correspondence) จะเก็บเฉพาะข้อมูลของเอกสาร (Data) ส่วนสถานะและการเปลี่ยนสถานะ (State Transition) จะถูกจัดการโดย Workflow Engine + - ระบบการเดินเอกสารทั้งหมด (Correspondence, RFA, Circulation) ต้อง ใช้ Engine กลางเดียวกัน โดยกำหนด Logic ผ่าน Workflow DSL (JSON Configuration) แทนการเขียน Hard-coded ลงในตาราง + - Workflow Versioning (เพิ่ม): ระบบต้องรองรับการกำหนด Version ของ Workflow Definition โดยเอกสารที่เริ่มกระบวนการไปแล้ว (In-progress instances) จะต้องใช้ Workflow Version เดิม จนกว่าจะสิ้นสุดกระบวนการ หรือได้รับคำสั่ง Migrate จาก Admin เพื่อป้องกันความขัดแย้งของ State -- **2.4.3 Idempotency & Locking:** ใช้กลไกเดิมในการป้องกันการทำรายการซ้ำ +- **2.4.2 Separation of Concerns:** -- **2.4.4 Optimistic Locking (ใหม่):** ใช้ Version Column ใน Database ควบคู่กับ Redis Lock สำหรับการสร้างเลขที่เอกสาร เพื่อเป็น Safety Net ชั้นสุดท้าย + - Module ต่างๆ (Correspondence, RFA, Circulation) จะเก็บเฉพาะข้อมูลของเอกสาร (Data) ส่วนสถานะและการเปลี่ยนสถานะ (State Transition) จะถูกจัดการโดย Workflow Engine -- **2.4.5** **จะไม่มีการใช้ SQL Triggers** เพื่อป้องกันตรรกะซ่อนเร้น (Hidden Logic) และความซับซ้อนในการดีบัก +- **2.4.3 Idempotency & Locking:** + + - ใช้กลไกเดิมในการป้องกันการทำรายการซ้ำ + +- **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:** @@ -150,117 +160,118 @@ ### **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.1. วัตถุประสงค์: + - เอกสารโต้ตอบ (correspondences) ระหว่างองค์กรณ์-องค์กรณ์ ภายใน โครงการ (Projects) และระหว่าง องค์กรณ์-องค์กรณ์ ภายนอก โครงการ (Projects), รองรับ To (ผู้รับหลัก) และ CC (ผู้รับสำเนา) หลายองค์กรณ์ +- 3.2.2. ประเภทเอกสาร: + - ระบบต้องรองรับเอกสารรูปแบบ ไฟล์ PDF, ZIP + - เอกสารโต้ตอบ (Correspondence) สามารถมีได้หลายประเภท (Types) เช่น จดหมาย (Letter), อีเมล์ (Email), Request for Information (RFI), รวมถึง เอกสารขออนุมัติ (RFA) แต่ละ revision และสามารถเพิ่มประเภทใหม่ได้ในภายหลัง - 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.2.5. Workflow (Unified Workflow): + - ระบบต้องรองรับ Workflow ที่เป็นแบบ Unified Workflow -### **3.3. การจัดกาแบบคู่สัญญา (Contract Drawing)** +### **3.3. การจัดการเอกสาขออนุมัติ (Request for Approval / RFA)** -- 3.3.1. วัตถุประสงค์: แบบคู่สัญญา (Contract Drawing) ใช้เพื่ออ้างอิงและใช้ในการตรวจสอบ -- 3.3.2. ประเภทเอกสาร: ไฟล์ PDF -- 3.3.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้ -- 3.3.4. การอ้างอิงและจัดกลุ่ม: ใช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Contract Drawing +- 3.3.1. วัตถุประสงค์: + - เอกสารขออนุมัติ (RFA) ภายใน โครงการ (Projects) +- 3.3.2. ประเภทเอกสาร: + - ระบบต้องรองรับเอกสารรูปแบบ ไฟล์ PDF + - เอกสารขออนุมัติ (RFA) สามารถมีได้หลาย revision + - มีประถทของเอกสาร ได้หลายประเภท (RFA Types) และสามารถเพิ่มประเภทใหม่ได้ในภายหลัง +- 3.3.3. การสร้างเอกสาร: + - ผู้ใช้ที่มีสิทธิ์ (เช่น Document Control) สามารถสร้างเอกสารขออนุมัติ (RFA) รอไว้ในสถานะ ฉบับร่าง" (Draft) ได้ ซึ่งผู้ใช้งานต่างองค์กรจะมองไม่เห็น + - เมื่อกด "Submitted" แล้ว การแก้ไข, ถอนเอกสารกลับไปสถานะ Draft, หรือยกเลิก (Cancel) จะต้องทำโดยผู้ใช้ระดับ Admin ขึ้นไป พร้อมระบุเหตุผล +- 3.3.4. การอ้างอิงและจัดกลุ่ม: + - RFA สามารถอ้างถึง (Reference) แบบก่อสร้าง (Shop Drawing) ได้หลายฉบับ +- 3.3.5. Workflow (Unified Workflow): + - ระบบต้องรองรับ Workflow ที่เป็นแบบ Unified Workflow ซึ่งจะมีสถานะและกิจกรรมที่ไม่เหมือนกันกับเอกสารโต้ตอบ (Correspondence) -### **3.4. การจัดกาแบบก่อสร้าง (Shop Drawing)** +### **3.4. การจัดการแบบคู่สัญญา (Contract Drawing)** -- 3.4.1. วัตถุประสงค์: แบบก่อสร้าง (Shop Drawing) ใช้เในการตรวจสอบ โดยจัดส่งด้วย Request for Approval (RFA) +- 3.4.1. วัตถุประสงค์: แบบคู่สัญญา (Contract Drawing) ใช้เพื่ออ้างอิงและใช้ในการตรวจสอบ - 3.4.2. ประเภทเอกสาร: ไฟล์ PDF - 3.4.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้ -- 3.4.4. การอ้างอิงและจัดกลุ่ม: ช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Shop Drawings +- 3.4.4. การอ้างอิงและจัดกลุ่ม: ใช้สำหรับอ้างอิง ใน Shop Drawings, มีการจัดหมวดหมู่ของ Contract Drawing -### **3.5. การจัดการ Workflow (Unified Workflow)** +### **3.5. การจัดกาแบบก่อสร้าง (Shop Drawing)** -- 3.5.1 Workflow Definition: +- 3.5.1. วัตถุประสงค์: แบบก่อสร้าง (Shop Drawing) ใช้เในการตรวจสอบ โดยจัดส่งด้วย Request for Approval (RFA) +- 3.5.2. ประเภทเอกสาร: ไฟล์ PDF, DWG, ZIP +- 3.5.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้ โดยผู้ใช้ที่มีสิทธิ์ (เช่น Document Control) สามารถสร้างเอกสารรอไว้ในสถานะ ฉบับร่าง" (Draft) ได้ ซึ่งผู้ใช้งานต่างองค์กรจะมองไม่เห็น +- 3.5.4. การอ้างอิงและจัดกลุ่ม: ใช้สำหรับอ้างอิง ใน RFA, มีการจัดหมวดหมู่ของ Shop Drawings โดยทุก แบบก่อสร้าง (Shop Drawing) แต่ละ revision ต้องมี RFA ได้เพียง 1 ฉบับ - - Admin ต้องสามารถสร้าง/แก้ไข Workflow Rule ได้ผ่านหน้าจอ UI (DSL Editor) ร - - องรับการกำหนด State, Transition, Required Role, Condition (JS Expression) +### **3.6. การจัดการ Workflow (Unified Workflow)** -- 3.5.2 Workflow Execution: +- 3.6.1 Workflow Definition: + + - Admin ต้องสามารถสร้าง/แก้ไข Workflow Rule ได้ผ่านหน้าจอ UI (DSL Editor) + - รองรับการกำหนด State, Transition, Required Role, Condition (JS Expression) + +- 3.6.2 Workflow Execution: - ระบบต้องรองรับการสร้าง Instance ของ Workflow ผูกกับเอกสาร (Polymorphic) - รองรับการเปลี่ยนสถานะ (Action) เช่น Approve, Reject, Comment, Return - Auto-Action: รองรับการเปลี่ยนสถานะอัตโนมัติเมื่อครบเงื่อนไข (เช่น Review ครบทุกคน) -- 3.5.3 Flexibility: +- 3.6.3 Flexibility: - รองรับ Parallel Review (ส่งให้หลายคนตรวจพร้อมกัน) - รองรับ Conditional Flow (เช่น ถ้ายอดเงิน > X ให้เพิ่มผู้อนุมัติ) -- 3.5.4 Workflow การอนุมัติ: -- ต้องรองรับกระบวนการอนุมัติที่ซับซ้อนและเป็นลำดับ เช่น ส่งจาก Originator -> Organization 1 -> Organization 2 -> Organization 3 แล้วส่งผลกลับตามลำดับเดิม (โดยถ้า องกรณ์ใดใน Workflow ให้ส่งกลับ ก็สามารถส่งผลกลับตามลำดับเดิมโดยไม่ต้องรอให้ถึง องกรณืในลำดับถัดไป) +- 3.6.4 Workflow การอนุมัติ: + + - รองรับกระบวนการอนุมัติที่ซับซ้อนและเป็นลำดับ เช่น ส่งจาก Originator -> Organization 1 -> Organization 2 -> Organization 3 แล้วส่งผลกลับตามลำดับเดิม (โดยถ้า องกรณ์ใดใน Workflow ให้ส่งกลับ ก็สามารถส่งผลกลับตามลำดับเดิมโดยไม่ต้องรอให้ถึง องกรณืในลำดับถัดไป) + +- 3.6.5 การจัดการ: -- 3.5.5 การจัดการ: - สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ได้ - มีระบบแจ้งเตือน ให้ผู้รับผิดชอบของ องกรณ์ ที่อยู่ใน Workflow ทราบ เมื่อมี RFA ใหม่ หรือมีการเปลี่ยนสถานะ + - สามารถข้ามขั้นตอนได้ในกรณีพิเศษ (โดยผู้มีสิทธิ์) + - สามารถส่งกลับขั้นตอนก่อนหน้าได้ -### **3.6.การจัดการเอกสารนำส่ง (Transmittals)** +### **3.7.การจัดการเอกสารนำส่ง (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.1. วัตถุประสงค์: เอกสารนำส่ง ใช้สำหรับ นำส่ง Request for Approval (RFAS) หลายฉบับ ไปยังองค์กรอื่น - 3.7.2. ประเภทเอกสาร: ไฟล์ PDF -- 3.7.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ในองค์กรนั้น สามารถสร้างและแก้ไขได้ -- 3.7.4. การอ้างอิงและจัดกลุ่ม: การระบุผู้รับผิดชอบ: +- 3.7.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ สามารถสร้างและแก้ไขได้ +- 3.7.4. การอ้างอิงและจัดกลุ่ม: เอกสารนำส่ง เป็นส่วนหนึ่งใน Correspondence + +### **3.8.ใบเวียนเอกสาร (Circulation Sheet)** + +- 3.8.1. วัตถุประสงค์: การสื่อสาร เอกสาร (Correspondence) ทุกฉบับ จะมีใบเวียนเอกสารเพื่อควบคุมและมอบหมายงานภายในองค์กร (สามารถดูและแก้ไขได้เฉพาะคนในองค์กร) +- 3.8.2. ประเภทเอกสาร: ไฟล์ PDF +- 3.8.3. การสร้างเอกสาร: ผู้ใช้ที่มีสิทธิ์ในองค์กรนั้น สามารถสร้างและแก้ไขได้ +- 3.8.4. การอ้างอิงและจัดกลุ่ม: การระบุผู้รับผิดชอบ: - ผู้รับผิดชอบหลัก (Main): มีได้หลายคน - ผู้ร่วมปฏิบัติงาน (Action): มีได้หลายคน - ผู้ที่ต้องรับทราบ (Information): มีได้หลายคน -- 3.7.5. การติดตามงาน: +- 3.8.5. การติดตามงาน: - สามารถกำหนดวันแล้วเสร็จ (Deadline) สำหรับผู้รับผิดชอบประเภท Main และ Action ได้ - มีระบบแจ้งเตือนเมื่อมี Circulation ใหม่ และแจ้งเตือนล่วงหน้าก่อนถึงวันแล้วเสร็จ - สามารถปิด Circulation ได้เมื่อดำเนินการตอบกลับไปยังองค์กรผู้ส่ง (Originator) แล้ว หรือ รับทราบแล้ว (For Information) -### **3.8. ประวัติการแก้ไข (Revisions):** ระบบจะเก็บประวัติการสร้างและแก้ไข เอกสารทั้งหมด +### **3.9. ประวัติการแก้ไข (Revisions):** ระบบจะเก็บประวัติการสร้างและแก้ไข เอกสารทั้งหมด -### **3.9. การจัดเก็บไฟล์ (File Handling - ปรับปรุงใหญ่)** +### **3.10. การจัดเก็บไฟล์ (File Handling - ปรับปรุงใหญ่)** -- **3.9.1 Two-Phase Storage Strategy:** +- **3.10.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:** +- **3.10.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 ความปลอดภัยของการจัดเก็บไฟล์:** +- **3.10.3 ความปลอดภัยของการจัดเก็บไฟล์:** - ต้องมีการ scan virus สำหรับไฟล์ที่อัปโหลดทั้งหมด โดยใช้ ClamAV หรือบริการ third-party - จำกัดประเภทไฟล์ที่อนุญาต: PDF, DWG, DOCX, XLSX, ZIP (ต้องระบุรายการที่ชัดเจน) - ขนาดไฟล์สูงสุด: 50MB ต่อไฟล์ @@ -269,92 +280,139 @@ - Download links ต้องมี expiration time (default: 24 ชั่วโมง) - ต้องบันทึก audit log ทุกครั้งที่มีการดาวน์โหลดไฟล์สำคัญ -### **3.10. การจัดการเลขที่เอกสาร (Document Numbering - ปรับปรุง)** +### **3.11. การจัดการเลขที่เอกสาร (Document Numbering - ปรับปรุง)** -- 3.10.1. ระบบต้องสามารถสร้างเลขที่เอกสาร (Running Number) ได้โดยอัตโนมัติและยืดหยุ่นสูง -- 3.10.2. **Logic การนับเลข (Counter Logic):** การนับเลขจะต้องรองรับการแยกตาม Key ที่ซับซ้อนขึ้น: +- 3.11.1. ระบบต้องสามารถสร้างเลขที่เอกสาร (Running Number) ได้โดยอัตโนมัติและยืดหยุ่นสูง +- 3.11.2. Logic การนับเลข (Counter Logic): การนับเลขจะต้องรองรับการแยกตาม Key ที่ซับซ้อนขึ้น: - **Project** + **Originator** + **Type** + **Discipline** (ถ้ามี) + **Sub-Type** (ถ้ามี) + **Year** -- 3.10.3. **Format Template:** รองรับการกำหนดรูปแบบด้วย **Token Replacement** เช่น: - - `{ORG}-{TYPE}-{DISCIPLINE}-{SEQ:4}-{REV}` -> `TEAM-RFA-STR-0001-A` +- 3.11.3. Format Template: + - รองรับการกำหนดรูปแบบด้วย Token Replacement เช่น: + - `{ORG}-{TYPE}-{DISCIPLINE}-{SEQ:4}-{REV}` -> `TEAM-RFA-STR-0001-A` - รองรับ Token: `{PROJECT}`, `{ORG}`, `{TYPE}`, `{DISCIPLINE}`, `{SUBTYPE}`, `{SUBTYPE_NUM}`, `{YEAR}`, `{YEAR_SHORT}`, `{SEQ:n}` -- 3.10.4. **Transmittal Logic:** รองรับเงื่อนไขพิเศษสำหรับ Transmittal ที่เลขอาจเปลี่ยนตามผู้รับ (To Owner vs To Contractor) -- 3.10.5. **กลไกความปลอดภัย:** ยังคงใช้ Redis Distributed Lock และ Optimistic Locking เพื่อป้องกันเลขซ้ำหรือข้าม -- 3.10.6. ต้องมี retry mechanism และ fallback strategy เมื่อการ generate เลขที่เอกสารล้มเหลว +- 3.11.4. Transmittal Logic: รองรับเงื่อนไขพิเศษสำหรับ Transmittal ที่เลขอาจเปลี่ยนตามผู้รับ (To Owner vs To Contractor) +- 3.11.5. กลไกความปลอดภัย: ยังคงใช้ Redis Distributed Lock และ Optimistic Locking เพื่อป้องกันเลขซ้ำหรือข้าม +- 3.11.6. ต้องมี retry mechanism และ fallback strategy เมื่อการ generate เลขที่เอกสารล้มเหลว +- 3.11.7 Fallback Logic (เพิ่ม): + - กรณีที่เอกสารประเภทนั้นไม่มี discipline_id หรือ sub_type_id (เป็นค่า NULL หรือไม่ระบุ) ให้ระบบใช้ค่า Default (เช่น 0) ในการจัดกลุ่ม Counter เพื่อป้องกัน Error และรับประกันความถูกต้องของ Running Number (Uniqueness Guarantee) + - Scenario 1: Redis Unavailable + - Fallback เป็น database-only locking (pessimistic lock) + - Log warning และแจ้ง ops team + - ระบบยังใช้งานได้แต่ performance ลดลง + - Scenario 2: Lock Acquisition Timeout + - Retry 5 ครั้งด้วย exponential backoff (1s, 2s, 4s, 8s, 16s) + - หลัง 5 ครั้ง: Return error 503 "Service Temporarily Unavailable" + - Frontend แสดง user-friendly message: "ระบบกำลังยุ่ง กรุณาลองใหม่ภายหลัง" + - Scenario 3: Version Conflict After Lock + - Retry transaction อีก 2 ครั้ง + - หากยังล้มเหลว: Log error พร้อม context และ return 409 Conflict + - Frontend แสดง user-friendly message: "เลขที่เอกสารถูกเปลี่ยน กรุณาลองใหม่" + - Monitoring: + - Alert ถ้า lock acquisition failures > 5% ใน 5 นาที + - Dashboard แสดง lock wait time percentiles -### **3.11 การจัดการ JSON Details (JSON & Performance - ปรับปรุง)** +### **3.12. การจัดการ JSON Details (JSON & Performance - ปรับปรุง)** -- **3.11.1 วัตถุประสงค์** +- **3.12.1 วัตถุประสงค์** - จัดเก็บข้อมูลแบบไดนามิกที่เฉพาะเจาะจงกับแต่ละประเภทของเอกสาร - รองรับการขยายตัวของระบบโดยไม่ต้องเปลี่ยนแปลง database schema - จัดการ metadata และข้อมูลประกอบสำหรับ correspondence, routing, และ workflows -- **3.11.2 โครงสร้าง JSON Schema** +- **3.12.2 โครงสร้าง JSON Schema** ระบบต้องมี predefined JSON schemas สำหรับประเภทเอกสารต่างๆ: - - **3.11.2.1 Correspondence Types** - - **GENERIC**: ข้อมูลพื้นฐานสำหรับเอกสารทั่วไป - - **RFI**: รายละเอียดคำถามและข้อมูลทางเทคนิค - - **RFA**: ข้อมูลการขออนุมัติแบบและวัสดุ - - **TRANSMITTAL**: รายการเอกสารที่ส่งต่อ - - **LETTER**: ข้อมูลจดหมายทางการ - - **EMAIL**: ข้อมูลอีเมล - - **3.11.2.2 Rworkflow Types** - - **workflow_definitions**: กฎและเงื่อนไขการส่งต่อ - - **workflow_histories**: สถานะและประวัติการส่งต่อ - - **workflow_instances**: การดำเนินการในแต่ละขั้นตอน - - **3.11.2.3 Audit Types** - - **AUDIT_LOG**: ข้อมูลการตรวจสอบ - - **SECURITY_SCAN**: ผลการตรวจสอบความปลอดภัย + - 3.12.2.1 Correspondence Types + - GENERIC: ข้อมูลพื้นฐานสำหรับเอกสารทั่วไป + - RFI: รายละเอียดคำถามและข้อมูลทางเทคนิค + - RFA: ข้อมูลการขออนุมัติแบบและวัสดุ + - TRANSMITTAL: รายการเอกสารที่ส่งต่อ + - LETTER: ข้อมูลจดหมายทางการ + - EMAIL: ข้อมูลอีเมล + - 3.12.2.2 Rworkflow Types + - workflow_definitions: กฎและเงื่อนไขการส่งต่อ + - workflow_histories: สถานะและประวัติการส่งต่อ + - workflow_instances: การดำเนินการในแต่ละขั้นตอน + - 3.12.2.3 Audit Types + - AUDIT_LOG: ข้อมูลการตรวจสอบ + - SECURITY_SCAN: ผลการตรวจสอบความปลอดภัย -- **3.11.3 Virtual Columns (ใหม่):** สำหรับ Field ใน JSON ที่ต้องใช้ในการค้นหา (Search) หรือจัดเรียง (Sort) บ่อยๆ **ต้องสร้าง Generated Column (Virtual Column)** ใน Database และทำ Index ไว้ เพื่อประสิทธิภาพสูงสุด +- **3.12.3 Virtual Columns (ปรับปรุง):** -- **3.11.4 Validation Rules** + - สำหรับ Field ใน JSON ที่ต้องใช้ในการค้นหา (Search) หรือจัดเรียง (Sort) บ่อยๆ ต้องสร้าง Generated Column (Virtual Column) ใน Database และทำ Index ไว้ เพื่อประสิทธิภาพสูงสุด + - Schema Consistency: Field ที่ถูกกำหนดเป็น Virtual Column ห้าม เปลี่ยนแปลง Key Name หรือ Data Type ใน JSON Schema Version ถัดไป หากจำเป็นต้องเปลี่ยน ต้องมีแผนการ Re-index หรือ Migration ข้อมูลเดิมที่ชัดเจน + +- **3.12.4 Validation Rules** - ต้องมี JSON schema validation สำหรับแต่ละประเภท - ต้องรองรับ versioning ของ schema - ต้องมี default values สำหรับ field ที่ไม่บังคับ - ต้องตรวจสอบ data types และ format ให้ถูกต้อง -- **3.11.5 Performance Requirements** +- **3.12.5 Performance Requirements** - JSON field ต้องมีขนาดไม่เกิน 50KB - ต้องรองรับ indexing สำหรับ field ที่ใช้ค้นหาบ่อย - ต้องมี compression สำหรับ JSON ขนาดใหญ่ -- **3.11.6 Security Requirements** +- **3.12.6 Security Requirements** + - ต้อง sanitize JSON input เพื่อป้องกัน injection attacks - ต้อง validate JSON structure ก่อนบันทึก - ต้อง encrypt sensitive data ใน JSON fields -### **3.12 ข้อกำหนดพิเศษ** +- 3.12.7 JSON Schema Migration Strategy (เพิ่มเติม) + สำหรับ Schema Breaking Changes: -- **ผู้ใช้งานที่มีสิทธิ์ระดับสูง (Global) หรือผู้ได้รับอนุญาตเป็นกรณีพิเศษ** - - สามารถเลือก **สร้างในนามองค์กร (Create on behalf of)** ได้ เพื่อให้สามารถออกเลขที่เอกสาร (Running Number) ขององค์กรอื่นได้โดยไม่ต้องล็อกอินใหม่ + - Phase 1 - Add New Column + ALTER TABLE correspondence_revisions + ADD COLUMN ref_project_id_v2 INT GENERATED ALWAYS AS + (JSON_UNQUOTE(JSON_EXTRACT(details, '$.newProjectIdPath'))) VIRTUAL; + + - Phase 2 - Backfill Old Records + - ใช้ background job แปลง JSON format เก่าเป็นใหม่ + - Update `details` JSON ทีละ batch (1000 records) + - Phase 3 - Switch Application Code + - Deploy code ที่ใช้ path ใหม่ + - Phase 4 - Remove Old Column + + - หลังจาก verify แล้วว่าไม่มี error + - Drop old virtual column + + - สำหรับ Non-Breaking Changes + - เพิ่ม optional field ใน schema + - Old records ที่ไม่มี field = ใช้ default value + +### **3.13. ข้อกำหนดพิเศษ** + +- ผู้ใช้งานที่มีสิทธิ์ระดับสูง (Global) หรือผู้ได้รับอนุญาตเป็นกรณีพิเศษ + - สามารถเลือก สร้างในนามองค์กร (Create on behalf of) ได้ เพื่อให้สามารถออกเลขที่เอกสาร (Running Number) ขององค์กรอื่นได้โดยไม่ต้องล็อกอินใหม่ - สามารถทำงานแทนผู้ใช้งานอื่นได้ Routing & Workflow ของ Correspondence, RFA, Circulation Sheet -### 3.13. การจัดการข้อมูลหลักขั้นสูง (Admin Panel for Master Data) +### **3.14. การจัดการข้อมูลหลักขั้นสูง (Admin Panel for Master Data)** -- 3.13.1. **Disciplines Management:** Admin ต้องสามารถ เพิ่ม/ลบ/แก้ไข สาขางาน (Disciplines) แยกตามสัญญา (Contract) ได้ -- 3.13.2. **Sub-Type Mapping:** Admin ต้องสามารถกำหนด Correspondence Sub-types และ Mapping รหัสตัวเลข (เช่น MAT = 11) ได้ -- 3.13.3. **Numbering Format Configuration:** Admin ต้องมี UI สำหรับตั้งค่า Format Template ของแต่ละ Project/Type ได้โดยไม่ต้องแก้โค้ด +- 3.14.1. Disciplines Management: Admin ต้องสามารถ เพิ่ม/ลบ/แก้ไข สาขางาน (Disciplines) แยกตามสัญญา (Contract) ได้ +- 3.14.2. Sub-Type Mapping: Admin ต้องสามารถกำหนด Correspondence Sub-types และ Mapping รหัสตัวเลข (เช่น MAT = 11) ได้ +- 3.14.3. Numbering Format Configuration: Admin ต้องมี UI สำหรับตั้งค่า Format Template ของแต่ละ Project/Type ได้โดยไม่ต้องแก้โค้ด ## **🔐 4. ข้อกำหนดด้านสิทธิ์และการเข้าถึง (Access Control Requirements)** -### **4.1. ภาพรวม:** ผู้ใช้และองค์กรสามารถดูและแก้ไขเอกสารได้ตามสิทธิ์ที่ได้รับ โดยระบบสิทธิ์จะเป็นแบบ Role-Based Access Control (RBAC) +### **4.1. ภาพรวม:** -### **4.2. ลำดับชั้นของสิทธิ์ (Permission Hierarchy)** +- ผู้ใช้และองค์กรสามารถดูและแก้ไขเอกสารได้ตามสิทธิ์ที่ได้รับ โดยระบบสิทธิ์จะเป็นแบบ Role-Based Access Control (RBAC) + +### **4.2. ลำดับชั้นของสิทธิ์ (Permission Hierarchy):** - Global: สิทธิ์สูงสุดของระบบ - Organization: สิทธิ์ภายในองค์กร เป็นสิทธิ์พื้นฐานของผู้ใช้ - Project: สิทธิ์เฉพาะในโครงการ จะถูกพิจารณาเมื่อผู้ใช้อยู่ในโครงการนั้น - Contract: สิทธิ์เฉพาะในสัญญา จะถูกพิจารณาเมื่อผู้ใช้อยู่ในสัญญานั้น (สัญญาเป็นส่วนหนึ่งของโครงการ) -กฎการบังคับใช้: เมื่อตรวจสอบสิทธิ์ ระบบจะพิจารณาสิทธิ์จากทุกระดับที่ผู้ใช้มี และใช้ สิทธิ์ที่มากที่สุด (Most Permissive) เป็นตัวตัดสิน +### **4.3. กฎการบังคับใช้:** -ตัวอย่าง: ผู้ใช้ A เป็น Viewer ในองค์กร แต่ถูกมอบหมายเป็น Editor ในโครงการ X เมื่ออยู่ในโครงการ X ผู้ใช้ A จะมีสิทธิ์แก้ไขได้ +- เมื่อตรวจสอบสิทธิ์ ระบบจะพิจารณาสิทธิ์จากทุกระดับที่ผู้ใช้มี และใช้ สิทธิ์ที่มากที่สุด (Most Permissive) เป็นตัวตัดสิน +- ตัวอย่าง: ผู้ใช้ A เป็น Viewer ในองค์กร แต่ถูกมอบหมายเป็น Editor ในโครงการ X เมื่ออยู่ในโครงการ X ผู้ใช้ A จะมีสิทธิ์แก้ไขได้ -### **4.3. การกำหนดบทบาท (Roles) และขอบเขต (Scope)** +### **4.4. การกำหนดบทบาท (Roles) และขอบเขต (Scope):** | บทบาท (Role) | ขอบเขต (Scope) | คำอธิบาย | สิทธิ์หลัก (Key Permissions) | | :------------------- | :------------- | :---------------------- | :------------------------------------------------------------------------------------- | @@ -366,31 +424,31 @@ | **Project Manager** | Project | ผู้จัดการโครงการ | จัดการสมาชิกในโครงการ (เพิ่ม/ลบ/มอบบทบาท), สร้าง/จัดการสัญญาในโครงการ, ดูรายงานโครงการ | | **Contract Admin** | Contract | ผู้ดูแลสัญญา | จัดการสมาชิกในสัญญา, สร้าง/จัดการข้อมูลหลักเฉพาะสัญญา (ถ้ามี), อนุมัติเอกสารในสัญญา | -### **4.4. Token Management (ปรับปรุง)** +### **4.5 . Token Management (ปรับปรุง)** - **Payload Optimization:** ใน JWT Access Token ให้เก็บเฉพาะ `userId` และ `scope` ปัจจุบันเท่านั้น - **Permission Caching:** สิทธิ์ละเอียด (Permissions List) ให้เก็บใน **Redis** และดึงมาตรวจสอบเมื่อ Request เข้ามา เพื่อลดขนาด Token และเพิ่มความเร็ว -### **4.5. กระบวนการเริ่มต้นใช้งาน (Onboarding Workflow) ที่สมบูรณ์** +### **4.6. กระบวนการเริ่มต้นใช้งาน (Onboarding Workflow) ที่สมบูรณ์** -- **4.5.1. สร้างองค์กร (Organization)** +- 4.6.1. สร้างองค์กร (Organization) - **Superadmin** สร้างองค์กรใหม่ (เช่น บริษัท A) - **Superadmin** แต่งตั้งผู้ใช้อย่างน้อย 1 คนให้เป็น **Org Admin** หรือ **Document Control** ของบริษัท A -- **4.5.2. เพิ่มผู้ใช้ในองค์กร** +- 4.6.2. เพิ่มผู้ใช้ในองค์กร - **Org Admin** ของบริษัท A เพิ่มผู้ใช้อื่นๆ (Editor, Viewer) เข้ามาในองค์กรของตน -- **4.5.3. มอบหมายผู้ใช้ให้กับโครงการ (Project)** +- 4.6.3. มอบหมายผู้ใช้ให้กับโครงการ (Project) - **Project Manager** ของโครงการ X (ซึ่งอาจมาจากบริษัท A หรือบริษัทอื่น) ทำการ "เชิญ" หรือ "มอบหมาย" ผู้ใช้จากองค์กรต่างๆ ที่เกี่ยวข้องเข้ามาในโครงการ X - ในขั้นตอนนี้ **Project Manager** จะกำหนด **บทบาทระดับโครงการ** (เช่น Project Member, หรืออาจไม่มีบทบาทพิเศษ ให้ใช้สิทธิ์จากระดับองค์กรไปก่อน) -- **4.5.4. เมอบหมายผู้ใช้ให้กับสัญญา (Contract)** +- 4.6.4. เมอบหมายผู้ใช้ให้กับสัญญา (Contract) - **Contract Admin** ของสัญญา Y (ซึ่งเป็นส่วนหนึ่งของโครงการ X) ทำการเลือกผู้ใช้ที่อยู่ในโครงการ X แล้ว มอบหมายให้เข้ามาในสัญญา Y - ในขั้นตอนนี้ **Contract Admin** จะกำหนด **บทบาทระดับสัญญา** (เช่น Contract Member) และสิทธิ์เฉพาะที่จำเป็น -- **4.5.5 Security Onboarding:** +- 4.6.5 Security Onboarding: - ต้องบังคับเปลี่ยน password ครั้งแรกสำหรับผู้ใช้ใหม่ - ต้องมี security awareness training สำหรับผู้ใช้ที่มีสิทธิ์สูง - ต้องมี process สำหรับการรีเซ็ต password ที่ปลอดภัย - ต้องบันทึก audit log ทุกครั้งที่มีการเปลี่ยนแปลง permissions -### **4.6. การจัดการข้อมูลหลัก (Master Data Management) ที่แบ่งตามระดับ** +### **4.7. การจัดการข้อมูลหลัก (Master Data Management) ที่แบ่งตามระดับ** | ข้อมูลหลัก | ผู้มีสิทธิ์จัดการ | ระดับ | | :---------------------------------- | :------------------------------ | :--------------------------------- | @@ -403,173 +461,199 @@ ## **👥 5. ข้อกำหนดด้านผู้ใช้งาน (User Interface & Experience)** -### **5.1. Layout หลัก:** หน้าเว็บใช้รูปแบบ App Shell ที่ประกอบด้วย +### 5.1. Layout หลัก -- Navbar (ส่วนบน): แสดงชื่อระบบ, เมนูผู้ใช้ (Profile), เมนูสำหรับ Document Control/เมนูสำหรับ Admin/Superadmin (จัดการผู้ใช้, จัดการสิทธิ์), และปุ่ม Login/Logout -- Sidebar (ด้านข้าง): เป็นเมนูหลักสำหรับเข้าถึงส่วนที่เกี่ยวข้องกับเอกสารทั้งหมด เช่น Dashboard, Correspondences, RFA, Drawings -- Main Content Area: พื้นที่สำหรับแสดงเนื้อหาหลักของหน้าที่เลือก +- หน้าเว็บใช้รูปแบบ App Shell ที่ประกอบด้วย + - Navbar (ส่วนบน): แสดงชื่อระบบ, เมนูผู้ใช้ (Profile), เมนูสำหรับ Document Control/เมนูสำหรับ Admin/Superadmin (จัดการผู้ใช้, จัดการสิทธิ์, และอื่นๆ), และปุ่ม Login/Logout + - Sidebar (ด้านข้าง): เป็นเมนูหลักสำหรับเข้าถึงส่วนที่เกี่ยวข้องกับเอกสารทั้งหมด เช่น Dashboard, Correspondences, RFA, Drawings + - Main Content Area: พื้นที่สำหรับแสดงเนื้อหาหลักของหน้าที่เลือก -### **5.2. หน้า Landing Page:** เป็นหน้าแรกที่แสดงข้อมูลบางส่วนของโครงการสำหรับผู้ใช้ที่ยังไม่ได้ล็อกอิน +### 5.2. หน้า Landing Page -### **5.3. หน้า Dashboard:** เป็นหน้าแรกหลังจากล็อกอิน ประกอบด้วย +- เป็นหน้าแรกที่แสดงข้อมูลบางส่วนของโครงการสำหรับผู้ใช้ที่ยังไม่ได้ล็อกอิน -- การ์ดสรุปภาพรวม (KPI Cards): แสดงข้อมูลสรุปที่สำคัญขององค์กร เช่น จำนวนเอกสาร, งานที่เกินกำหนด -- ตาราง "งานของฉัน" (My Tasks Table): แสดงรายการงานทั้งหมดจาก Circulation ที่ผู้ใช้ต้องดำเนินการ -- Security Metrics: แสดงจำนวน files scanned, security incidents, failed login attempts +### 5.3. หน้า Dashboard -### **5.4. การติดตามสถานะ:** องค์กรสามารถติดตามสถานะเอกสารทั้งของตนเอง (Originator) และสถานะเอกสารที่ส่งมาถึงตนเอง (Recipient) +- เป็นหน้าแรกหลังจากล็อกอิน ประกอบด้วย + - การ์ดสรุปภาพรวม (KPI Cards): แสดงข้อมูลสรุปที่สำคัญขององค์กร เช่น จำนวนเอกสาร, งานที่เกินกำหนด + - ตาราง "งานของฉัน" (My Tasks Table): แสดงรายการงานทั้งหมดจาก Circulation ที่ผู้ใช้ต้องดำเนินการ + - Security Metrics: แสดงจำนวน files scanned, security incidents, failed login attempts -### **5.5. การจัดการข้อมูลส่วนตัว (Profile Page):** ผู้ใช้สามารถจัดการข้อมูลส่วนตัวและเปลี่ยนรหัสผ่านของตนเองได้ +### 5.4. การติดตามสถานะ -### **5.6. การจัดการเอกสารทางเทคนิค (RFA & Workflow):** ผู้ใช้สามารถดู RFA ในรูปแบบ Workflow ทั้งหมดได้ในหน้าเดียว, ขั้นตอนที่ยังไม่ถึงหรือผ่านไปแล้วจะเป็นรูปแบบ diable, สามารถดำเนินการได้เฉพาะในขั้นตอนที่ได้รับมอบหมายงาน (active) เช่น ตรวจสอบแล้ว เพื่อไปยังขั้นตอนต่อไป, สิทธิ์ Document Control ขึ้นไป สามรถกด ไปยังขั้นตอนต่อไป ได้ทุกขั้นตอน, การย้อนกลับ ไปขั้นตอนก่อนหน้า สามารถทำได้โดย สิทธิ์ Document Control ขึ้นไป +- องค์กรสามารถติดตามสถานะเอกสารทั้งของตนเอง (Originator) และสถานะเอกสารที่ส่งมาถึงตนเอง (Recipient) -### **5.7. การจัดการใบเวียนเอกสาร (Circulation):** ผู้ใช้สามารถดู Circulation ในรูปแบบ Workflow ทั้งหมดได้ในหน้าเดียว,ขั้นตอนที่ยังไม่ถึงหรือผ่านไปแล้วจะเป็นรูปแบบ diable, สามารถดำเนินการได้เฉพาะในขั้นตอนที่ได้รับมอบหมายงาน (active) เช่น ตรวจสอบแล้ว เพื่อไปยังขั้นตอนต่อไป, สิทธิ์ Document Control ขึ้นไป สามรถกด ไปยังขั้นตอนต่อไป ได้ทุกขั้นตอน, การย้อนกลับ ไปขั้นตอนก่อนหน้า สามารถทำได้โดย สิทธิ์ Document Control ขึ้นไป +### 5.5. การจัดการข้อมูลส่วนตัว (Profile Page) -### **5.8. การจัดการเอกสารนำส่ง (Transmittals):** ผู้ใช้สามารถดู Transmittals ในรูปแบบรายการทั้งหมดได้ในหน้าเดียว +- ผู้ใช้สามารถจัดการข้อมูลส่วนตัวและเปลี่ยนรหัสผ่านของตนเองได้ -### **5.9. ข้อกำหนด UI/UX การแนบไฟล์ (File Attachment UX):** +### 5.6. การจัดการเอกสารทางเทคนิค (RFA) + +- ผู้ใช้สามารถดู RFA ในรูปแบบ Workflow Diagram ทั้งหมดได้ในหน้าเดียว +- Interactive History (เพิ่ม): ในแผนภาพ Workflow ผู้ใช้ต้องสามารถ คลิกที่ Node หรือ Step เก่าที่ผ่านมาแล้ว เพื่อดู Audit Log ย่อยของ Step นั้นได้ทันที (เช่น ใครเป็นคนกด Approve, เวลาไหน, มี Comment อะไร) โดยไม่ต้องสลับไปดูใน Tab History แยกต่างหาก +- ขั้นตอนที่ยังไม่ถึงหรือผ่านไปแล้วจะเป็นรูปแบบ disabled +- สามารถดำเนินการได้เฉพาะในขั้นตอนที่ได้รับมอบหมายงาน (active) +- สิทธิ์ Document Control ขึ้นไป สามารถกด "Force Proceed" ไปยังขั้นตอนต่อไปได้ทุกขั้นตอน หรือ "Revert" กลับขั้นตอนก่อนหน้าได้ + +### 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 (ใหม่)** +### 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 (ใหม่)** +### 5.11 Mobile Responsiveness - **Table Visualization:** บนหน้าจอมือถือ ตารางข้อมูลที่มีหลาย Column (เช่น Correspondence List) ต้องเปลี่ยนการแสดงผลเป็นแบบ **Card View** อัตโนมัติ - **Navigation:** Sidebar ต้องเป็นแบบ Collapsible Drawer -### **5.12 Resilience & Offline Support (ใหม่)** +### 5.12 Resilience & Offline Support - **Auto-Save Draft:** ระบบต้องบันทึกข้อมูลฟอร์มที่กำลังกรอกลง **LocalStorage** อัตโนมัติ เพื่อป้องกันข้อมูลหายกรณีเน็ตหลุดหรือปิด Browser โดยไม่ได้ตั้งใจ +- **State Management:** ใช้ State Management ที่เหมาะสมและไม่ซับซ้อนเกินไป โดยเน้นการใช้ React Query สำหรับ Server State และ React Hook Form สำหรับ Form State - **Graceful Degradation:** หาก Service รอง (เช่น Search, Notification) ล่ม ระบบหลัก (CRUD) ต้องยังทำงานต่อได้ +### 5.13. Secure In-App PDF Viewer (ใหม่) + +- 5.13.1 Viewer Capabilities: ระบบต้องมี PDF Viewer ภายในแอปพลิเคชันที่สามารถเปิดดูไฟล์เอกสารหลัก (PDF) ได้ทันทีโดยไม่ต้องดาวน์โหลดลงเครื่อง เพื่อความสะดวกในการตรวจทาน (Review/Approve) +- 5.13.2 Security: การแสดงผลไฟล์ต้อง ห้าม (Disable) การทำ Browser Cache สำหรับไฟล์ Sensitive เพื่อป้องกันการกู้คืนไฟล์จากเครื่อง Client ภายหลัง +- 5.13.3 Performance: ต้องรองรับการส่งข้อมูลแบบ Streaming (Range Requests) เพื่อให้เปิดดูไฟล์ขนาดใหญ่ (เช่น แบบแปลน 50MB+) ได้รวดเร็วโดยไม่ต้องรอโหลดเสร็จทั้งไฟล์ + ## **🛡️ 6. ข้อกำหนดที่ไม่ใช่ฟังก์ชันการทำงาน (Non-Functional Requirements)** -### **6.1. การบันทึกการกระทำ (Audit Log):** ทุกการกระทำที่สำคัญของผู้ใช้ (สร้าง, แก้ไข, ลบ, ส่ง) จะถูกบันทึกไว้ใน audit_logs เพื่อการตรวจสอบย้อนหลัง +### 6.1. การบันทึกการกระทำ (Audit Log) -- **6.1.1 ขอบเขตการบันทึก Audit Log:** +- ทุกการกระทำที่สำคัญของผู้ใช้ (สร้าง, แก้ไข, ลบ, ส่ง) จะถูกบันทึกไว้ใน audit_logs เพื่อการตรวจสอบย้อนหลัง - - ทุกการสร้าง/แก้ไข/ลบ ข้อมูลสำคัญ (correspondences, RFAs, drawings, users, permissions) - - ทุกการเข้าถึงข้อมูล sensitive (user data, financial information) - - ทุกการเปลี่ยนสถานะ workflow (status transitions) - - ทุกการดาวน์โหลดไฟล์สำคัญ (contract documents, financial reports) - - ทุกการเปลี่ยนแปลง permission และ role assignment - - ทุกการล็อกอินที่สำเร็จและล้มเหลว - - ทุกการส่งคำขอ API ที่สำคัญ + - 6.1.1 ขอบเขตการบันทึก Audit Log: -- **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 + - ทุกการสร้าง/แก้ไข/ลบ ข้อมูลสำคัญ (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.3. การค้นหา (Search):** -### **6.4. การทำรายงาน (Reporting):** สามารถจัดทำรายงานสรุปแยกประเภทของ Correspondence ประจำวัน, สัปดาห์, เดือน, และปีได้ +- ระบบต้องมีฟังก์ชันการค้นหาขั้นสูง ที่สามารถค้นหาเอกสาร **correspondence**, **rfa**, **shop_drawing**, **contract-drawing**, **transmittal** และ **ใบเวียน (Circulations)** จากหลายเงื่อนไขพร้อมกันได้ เช่น ค้นหาจากชื่อเรื่อง, ประเภท, วันที่, และ Tag -### **6.5. ประสิทธิภาพ (Performance):** มีการใช้ Caching กับข้อมูลที่เรียกใช้บ่อย และใช้ Pagination ในตารางข้อมูลเพื่อจัดการข้อมูลจำนวนมาก +### **6.4. การทำรายงาน (Reporting):** -- **6.5.1 ตัวชี้วัดประสิทธิภาพ:** +- สามารถจัดทำรายงานสรุปแยกประเภทของ Correspondence ประจำวัน, สัปดาห์, เดือน, และปีได้ - - **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. ประสิทธิภาพ (Performance):** -- **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) +- มีการใช้ 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.5.3 Frontend Performance: + - **Bundle Size Optimization:** ต้องควบคุมขนาด Bundle โดยรวมไม่เกิน 2MB + - **State Management Efficiency:** ใช้ State Management Libraries อย่างเหมาะสม ไม่เกิน 2 ตัวหลัก + - **Memory Management:** ต้องป้องกัน Memory Leak จาก State ที่ไม่จำเป็น ### **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.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):** +### 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 ขั้นตอนการกู้คืน:** +- 6.7.1 ขั้นตอนการกู้คืน: - **Database Restoration Procedure:** - สร้างจาก full backup ล่าสุด - Apply transaction logs ถึง point-in-time ที่ต้องการ @@ -586,18 +670,16 @@ - **Recovery Time Objective (RTO):** < 4 ชั่วโมง - **Recovery Point Objective (RPO):** < 1 ชั่วโมง -### **6.8. กลยุทธ์การแจ้งเตือน (Notification Strategy - ปรับปรุง):** - -- **6.8.1 ระบบจะส่งการแจ้งเตือน (ผ่าน Email หรือ Line [cite: 2.7]) เมื่อมีการกระทำที่สำคัญ** ดังนี้: +### 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:** +- 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 @@ -613,19 +695,19 @@ ### **6.10. Monitoring และ Observability** -- **6.10.1 Application Monitoring:** +- 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:** +- 6.10.2 Business Metrics - จำนวน documents created ต่อวัน - Workflow completion rates - User activity metrics - System utilization rates - Search query performance -- **6.10.3 Security Monitoring:** +- 6.10.3 Security Monitoring - Failed login attempts - Rate limiting triggers - Virus scan results @@ -634,63 +716,70 @@ ### **6.11 JSON Processing & Validation** -- **6.11.1 JSON Schema Management** +- 6.11.1 JSON Schema Management - ต้องมี centralized JSON schema registry - ต้องรองรับ schema versioning และ migration - ต้องมี schema validation during runtime -- **6.11.2 Performance Optimization** +- 6.11.2 Performance Optimization - **Caching:** Cache parsed JSON structures - **Compression:** ใช้ compression สำหรับ JSON ขนาดใหญ่ - **Indexing:** Support JSON path indexing สำหรับ query -- **6.11.3 Error Handling** +- 6.11.3 Error Handling - ต้องมี graceful degradation เมื่อ JSON validation ล้มเหลว - ต้องมี default fallback values - ต้องบันทึก error logs สำหรับ validation failures ## **🧪 7. ข้อกำหนดด้านการทดสอบ (Testing Requirements)** -### **7.1. Unit Testing:** +### 7.1 Unit Testing - ต้องมี unit tests สำหรับ business logic ทั้งหมด - Code coverage อย่างน้อย 70% สำหรับ backend services + - Business Logic: 80%+ + - Controllers: 70%+ + - Utilities: 90%+ - ต้องทดสอบ RBAC permission logic ทุกระดับ -### **7.2. Integration Testing:** +### 7.2 Integration Testing - ทดสอบการทำงานร่วมกันของ modules - ทดสอบ database migrations และ data integrity - ทดสอบ API endpoints ด้วย realistic data -### **7.3. End-to-End Testing:** +### 7.3 End-to-End Testing - ทดสอบ complete user workflows - ทดสอบ document lifecycle จาก creation ถึง archival - ทดสอบ cross-module integrations -### **7.4. Security Testing:** +### 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 +- 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:** +### 7.5. Performance Testing -- **Load Testing:** ทดสอบด้วย realistic workloads -- **Stress Testing:** หา breaking points ของระบบ -- **Endurance 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 + - **Load Testing:** ทดสอบด้วย realistic workloads + - **Stress Testing:** หา breaking points ของระบบ + - **Endurance Testing:** ทดสอบการทำงานต่อเนื่องเป็นเวลานาน -### **7.6. Disaster Recovery Testing:** +### 7.6. Disaster Recovery Testing - ทดสอบ backup และ restoration procedures - ทดสอบ failover mechanisms - ทดสอบ data integrity หลังการ recovery -### **7.7 Specific Scenario Testing (เพิ่ม)** +### 7.7 Specific Scenario Testing (เพิ่ม) - **Race Condition Test:** ทดสอบยิง Request ขอเลขที่เอกสารพร้อมกัน 100 Request -- **Transaction Test:** ทดสอบปิดเน็ตระหว่าง Upload ไฟล์ (ตรวจสอบว่าไม่มี Orphan File หรือ Broken Link) -- **Permission Test:** ทดสอบ CASL Integration ทั้งฝั่ง Backend และ Frontend ให้ตรงกัน + - **Transaction Test:** ทดสอบปิดเน็ตระหว่าง Upload ไฟล์ (ตรวจสอบว่าไม่มี Orphan File หรือ Broken Link) + - **Permission Test:** ทดสอบ CASL Integration ทั้งฝั่ง Backend และ Frontend ให้ตรงกัน ## **8. ข้อกำหนดด้านการบำรุงรักษา (Maintenance Requirements)** @@ -738,56 +827,6 @@ - ต้องมี security incident response plan - ต้องมี regular security assessments -## **📋 สรุปการปรับปรุงจากเวอร์ชันก่อนหน้า** - -### **Security Enhancements:** - -1. **File Upload Security** - Virus scanning, file type validation, access controls -2. **Input Validation** - OWASP Top 10 protection, XSS/CSRF prevention -3. **Rate Limiting** - Comprehensive rate limiting strategy -4. **Secrets Management** - Secure handling of sensitive configuration - -### **Architecture Improvements:** - -1. **Document Numbering** - Changed from Stored Procedure to Application-level Locking with Optimistic Locking safety net -2. **Resilience Patterns** - Circuit breaker, retry mechanisms, fallback strategies -3. **Monitoring & Observability** - Health checks, metrics, distributed tracing -4. **Caching Strategy** - Comprehensive caching with proper invalidation -5. **Two-Phase File Storage** - Temp -> Permanent storage with transaction safety -6. **Unified Workflow Engine** - Consolidated routing logic for better maintainability - -### **Performance Targets:** - -1. **API Response Time** - < 200ms (90th percentile) -2. **Search Performance** - < 500ms -3. **File Upload** - < 30 seconds for 50MB files -4. **Cache Hit Ratio** - > 80% - -### **Operational Excellence:** - -1. **Disaster Recovery** - RTO < 4 hours, RPO < 1 hour -2. **Backup Procedures** - Comprehensive backup and restoration -3. **Security Testing** - Penetration testing and security audits -4. **Performance Testing** - Load testing with realistic workloads -5. **Maintenance Mode** - Graceful system maintenance capabilities - -### **User Experience Improvements:** - -1. **Dynamic Form Generator** - Reduced code duplication and better schema support -2. **Mobile Responsiveness** - Card view for tables on mobile devices -3. **Auto-Save Draft** - LocalStorage integration for form resilience -4. **Notification Digest** - Reduced notification spam - -### **Data Management:** - -1. **Virtual Columns** - Improved JSON field search performance -2. **Table Partitioning** - Support for large-scale data growth -3. **Idempotency Keys** - Prevention of duplicate transactions - -เอกสารนี้สะท้อนถึงความมุ่งมั่นในการสร้างระบบที่มีความปลอดภัย, มีความทนทาน, และมีประสิทธิภาพสูง พร้อมรองรับการเติบโตในอนาคตและความต้องการทางธุรกิจที่เปลี่ยนแปลงไป - -**หมายเหตุ:** Requirements นี้จะถูกทบทวนและปรับปรุงเป็นระยะตาม feedback จากทีมพัฒนาและความต้องการทางธุรกิจที่เปลี่ยนแปลงไป - ## **Document Control:** - **Document:** Application Requirements Specification v1.4.5 diff --git a/1_FullStackJS_V1_4_5.md b/1_FullStackJS_V1_4_5.md index d505a2e..e8c3e39 100644 --- a/1_FullStackJS_V1_4_5.md +++ b/1_FullStackJS_V1_4_5.md @@ -30,9 +30,15 @@ ### **2.2 Configuration & Secrets Management** -- **Production/Staging:** ห้ามใส่ Secrets (Password, Keys) ใน `docker-compose.yml` หลัก -- **Development:** ให้สร้างไฟล์ `docker-compose.override.yml` (เพิ่มใน `.gitignore`) เพื่อ Inject ตัวแปร Environment ที่เป็นความลับ -- **Validation:** ใช้ `joi` หรือ `zod` ในการ Validate Environment Variables ตอน Start App หากขาดตัวแปรสำคัญให้ Throw Error ทันที +- **Production/Staging:** + - ใช้ Docker secrets หรือ environment variables ที่ inject ผ่าน CI/CD + - พิจารณา Hashicorp Vault หรือ AWS Secrets Manager สำหรับ production + - ห้ามใส่ Secrets (Password, Keys) ใน `docker-compose.yml` หลัก +- **Development:** + - ใช้ `docker-compose.override.yml` (gitignored) สำหรับ local secrets + - ไฟล์ `docker-compose.yml` หลักใช้ค่า dummy/placeholder +- **Validation:** + - ใช้ `joi` หรือ `zod` ในการ Validate Environment Variables ตอน Start App หากขาดตัวแปรสำคัญให้ Throw Error ทันที ### **2.3 Idempotency (ความสามารถในการทำซ้ำได้)** @@ -188,7 +194,8 @@ CREATE INDEX idx_ref_project_id ON correspondence_revisions(ref_project_id); #### **3.2.3 Partitioning Strategy** -สำหรับตาราง `audit_logs` และ `notifications` ให้เตรียมออกแบบ Entity ให้รองรับ Partitioning (เช่น แยกตามปี) โดยใช้ Raw SQL Migration ในการสร้างตาราง +- สำหรับตาราง `audit_logs` และ `notifications` ให้เตรียมออกแบบ Entity ให้รองรับ Partitioning (เช่น แยกตามปี) โดยใช้ Raw SQL Migration ในการสร้างตาราง +- Automated Partition Maintenance: ต้องมี Cron Job (Scheduled Task) เพื่อตรวจสอบและสร้าง Partition สำหรับปี/เดือนถัดไปล่วงหน้า (Pre-create partitions) อย่างน้อย 1 เดือน เพื่อป้องกัน Insert Error เมื่อขึ้นช่วงเวลาใหม่ ### **3.3 File Storage Service (Two-Phase Storage)** @@ -202,6 +209,10 @@ CREATE INDEX idx_ref_project_id ON correspondence_revisions(ref_project_id); - Service จะย้ายไฟล์จาก `temp/` ไปยัง `permanent/{YYYY}/{MM}/` - Update path ใน Database - ทั้งหมดนี้ต้องอยู่ภายใต้ Database Transaction เดียวกัน (ถ้า DB Fail, ไฟล์จะค้างที่ Temp และถูกลบโดย Cron Job) +3. **Cleanup:** + - มี Cron Job ลบไฟล์ใน temp/ ที่ค้างเกิน 24 ชม. (Orphan Files) โดยต้องตรวจสอบเงื่อนไขความปลอดภัยเพิ่มเติม: + - ไฟล์ต้องมี created_at เกิน 24 ชั่วโมง + - ไฟล์ต้องไม่อยู่ในสถานะ 'Locked' หรือกำลังถูก Process อยู่ (ตรวจสอบจาก Lock flag หรือ Transaction ID ถ้ามี) ### **3.4 Document Numbering (Double-Lock Mechanism)** @@ -222,6 +233,8 @@ Unified Workflow Engine (Core Architecture) - RfaModule -> เรียก WorkflowEngine - CirculationModule -> เรียก WorkflowEngine - ห้าม สร้างตาราง Routing แยก (เช่น rfa_workflows หรือ correspondence_routings) อีกต่อไป +- Boot-time Validation: + - เมื่อ Application Start (Backend Boot), ระบบต้องทำการ Validate Workflow DSL Definitions ทั้งหมด ว่า Syntax ถูกต้องและ State Transitions เชื่อมโยงกันสมบูรณ์ หากพบข้อผิดพลาดให้ Alert หรือ Block Startup (ใน Development Mode) เพื่อป้องกัน Runtime Error ### **3.6 ฟังก์ชันหลัก (Core Functionalities)** @@ -233,7 +246,6 @@ Unified Workflow Engine (Core Architecture) ### **3.7 ข้อจำกัดในการ Deploy (QNAP Container Station)** - **ห้ามใช้ไฟล์ .env** ในการตั้งค่า Environment Variables [cite: 2.1] -- การตั้งค่าทั้งหมด (เช่น Database connection string, JWT secret) **จะต้องถูกกำหนดผ่าน Environment Variable ใน docker-compose.yml โดยตรง** [cite: 6.5] ซึ่งจะจัดการผ่าน UI ของ QNAP Container Station [cite: 2.1] ### **3.8 ข้อจำกัดด้านความปลอดภัย (Security Constraints):** @@ -317,6 +329,8 @@ Unified Workflow Engine (Core Architecture) - ดึง Template จาก DB - Parse Template เพื่อหาว่าต้องใช้ Key ใดบ้างในการทำ Grouping Counter (เช่น ถ้า Template มี `{DISCIPLINE}` ให้ใช้ `discipline_id` ในการ query counter) - ใช้ **Double-Lock Mechanism** (Redis + Optimistic DB Lock) ในการดึงและอัพเดทค่า `last_number` + - Lock Timeout: การ Acquire Redis Lock ต้องกำหนด TTL (Time-to-Live) ที่สั้นและเหมาะสม (เช่น 2-5 วินาที) เพื่อป้องกัน Deadlock กรณี Service Crash ระหว่างทำงาน + - Retry Logic: ต้องมี Retry mechanism แบบ Exponential Backoff (แนะนำ 3-5 ครั้ง) หากไม่สามารถ Acquire Lock ได้ - **Features:** - Application-level locking เพื่อป้องกัน race condition - Retry mechanism ด้วย exponential backoff @@ -338,7 +352,7 @@ Unified Workflow Engine (Core Architecture) - คำนวณวันครบกำหนดอัตโนมัติ - ส่งการแจ้งเตือนเมื่อมีการส่งต่อใหม่ -#### 3.9.14 WorkflowEngineModule (New Core): +#### 3.9.14 WorkflowEngineModule (New Core) - Entities: WorkflowDefinition, WorkflowInstance, WorkflowHistory - Services: WorkflowEngineService, WorkflowDslService, WorkflowEventService @@ -515,40 +529,69 @@ Backend (NestJS) ควรเป็น **Stateless** (ไม่เก็บส #### **Performance Targets:** -- API Response Time: < 200ms (90th percentile) -- Search Query Performance: < 500ms +- API Response Time: + - Simple CRUD: < 100ms + - Complex Search: < 500ms + - File Processing: < 2s - File Upload Performance: < 30 seconds สำหรับไฟล์ 50MB - Cache Hit Ratio: > 80% -## 🖥️ **4. ฟรอนต์เอนด์ (Next.js) - Implementation Details** +### **3.20 Logging Strategy for QNAP Environment** -**โปรไฟล์นักพัฒนา (Developer Profile:** วิศวกร TypeScript + React/NextJS ระดับ Senior -เชี่ยวชาญ TailwindCSS, Shadcn/UI, และ Radix สำหรับการพัฒนา UI +เนื่องจากระบบรันบน QNAP Container Station ซึ่งอาจมีข้อจำกัดเรื่อง Disk I/O และ Storage: + +- Log Levels: ให้กำหนด Log Level ของ Production เป็น WARN หรือ ERROR เป็นหลัก +- Info Logs: ใช้ INFO เฉพาะ Flow ที่สำคัญทางธุรกิจเท่านั้น (เช่น Workflow State Change, Login Success/Fail, File Upload Commit) +- Console Logging: หลีกเลี่ยง console.log ปริมาณมาก (Verbose) ให้ใช้ Winston Logger ที่ Config ให้จัดการ Rotation และ Format ได้ดีกว่า +- Disable Debug: ปิด Debug Log ทั้งหมดใน Production Mode + +## 🖥️ **4. ฟรอนต์เอนด์ (Next.js) - Implementation Details** ### **4.1 State Management & Offline Support** #### **4.1.1 Auto-Save Drafts** -ใช้ `zustand` ร่วมกับ middleware `persist` (ลง LocalStorage) สำหรับฟอร์มที่มีขนาดใหญ่ (RFA, Correspondence) เพื่อป้องกันข้อมูลหายเมื่อเน็ตหลุด +ใช้ **React Hook Form** ร่วมกับ **persist** mechanism สำหรับฟอร์มที่มีขนาดใหญ่ (เช่น RFA, Correspondence): ```typescript -// lib/stores/draft-store.ts -export const useDraftStore = create( - persist( - (set) => ({ - drafts: {}, - saveDraft: (key, data) => - set((state) => ({ drafts: { ...state.drafts, [key]: data } })), - clearDraft: (key) => - set((state) => { - const newDrafts = { ...state.drafts }; - delete newDrafts[key]; - return { drafts: newDrafts }; - }), - }), - { name: 'form-drafts' } - ) -); +// hooks/useAutoSaveForm.ts +export const useAutoSaveForm = (formKey: string, defaultValues: any) => { + const { register, watch, setValue } = useForm({ defaultValues }); + + // Auto-save เมื่อ form เปลี่ยนแปลง + useEffect(() => { + const subscription = watch((value) => { + localStorage.setItem(`draft-${formKey}`, JSON.stringify(value)); + }); + return () => subscription.unsubscribe(); + }, [watch, formKey]); + + // Load draft เมื่อ component mount + useEffect(() => { + const draft = localStorage.getItem(`draft-${formKey}`); + if (draft) { + const parsed = JSON.parse(draft); + Object.keys(parsed).forEach((key) => { + setValue(key, parsed[key]); + }); + } + }, [formKey, setValue]); + + return { register }; +}; +``` + +#### **4.1.2 Silent Refresh Strategy** + +ใช้ React Query สำหรับจัดการ token refresh อัตโนมัติ + +```typescript +// lib/api/client.ts +const apiClient = axios.create({ + baseURL: process.env.NEXT_PUBLIC_API_URL, +}); + +// React Query จะจัดการ token refresh อัตโนมัติผ่าน interceptors ``` ### **4.2 Dynamic Form Generator** @@ -557,6 +600,7 @@ export const useDraftStore = create( - **Libraries:** แนะนำ `react-jsonschema-form` หรือสร้าง Wrapper บน `react-hook-form` ที่ Recursively render field ตาม Type - **Validation:** ใช้ `ajv` ที่ฝั่ง Client เพื่อ Validate JSON ก่อน Submit +- Schema Dependencies: ตัว Generator ต้องรองรับ dependencies keyword ของ JSON Schema (หรือ ui:schema logic) เพื่อรองรับเงื่อนไขซับซ้อน เช่น "ถ้าเลือกประเภทเอกสารเป็น 'Shop Drawing' ให้แสดง Dropdown เลือก 'Main Category' เพิ่มขึ้นมา" (Conditional Rendering) ### **4.3 Mobile Responsiveness (Card View)** @@ -611,7 +655,37 @@ export const useDraftStore = create( - แสดงข้อผิดพลาดด้วย **alert components** หรือข้อความ inline - ต้องมี labels, placeholders, และข้อความ feedback -### **🧪4.8 Frontend Testing** +### **4.8 Error Handling & Resilience (Frontend)** + +#### **4.8.1 Global Error Handling with React Query** + +ใช้ **React Query** Error Boundaries สำหรับจัดการ errors แบบรวมศูนย์: + +```typescript +// app/providers.tsx +export function QueryProvider({ children }: { children: React.ReactNode }) { + const queryClient = new QueryClient({ + defaultOptions: { + queries: { + retry: 1, + staleTime: 5 * 60 * 1000, // 5 minutes + }, + mutations: { + onError: (error) => { + // Global mutation error handling + toast.error('Operation failed'); + }, + }, + }, + }); + + return ( + {children} + ); +} +``` + +### **🧪4.9 Frontend Testing** เราจะใช้ **React Testing Library (RTL)** สำหรับการทดสอบ Component และ **Playwright** สำหรับ E2E: @@ -626,23 +700,76 @@ export const useDraftStore = create( - **เครื่องมือ:** **Playwright** - **เป้าหมาย:** ทดสอบ User Flow ทั้งระบบโดยอัตโนมัติ (เช่น ล็อกอิน -> สร้าง RFA -> ตรวจสอบ Workflow Visualization [cite: 5.6]) -### **🗄️4.9 Frontend State Management** +### **🗄️4.10 Frontend State Management (ปรับปรุง)** -สำหรับ Next.js App Router เราจะแบ่ง State เป็น 4 ระดับ: +### 🗄️4.10 Frontend State Management (ปรับปรุง) -1. **Local UI State (สถานะ UI ชั่วคราว):** - - **เครื่องมือ:** useState, useReducer - - **ใช้เมื่อ:** จัดการสถานะเล็กๆ ที่จบใน Component เดียว (เช่น Modal เปิด/ปิด, ค่าใน Input) -2. **Server State (สถานะข้อมูลจากเซิร์ฟเวอร์):** - - **เครื่องมือ:** **React Query (TanStack Query)** หรือ SWR - - **ใช้เมื่อ:** จัดการข้อมูลที่ดึงมาจาก NestJS API (เช่น รายการ correspondences, rfas, drawings) - - **ทำไม:** React Query เป็น "Cache" ที่จัดการ Caching, Re-fetching, และ Invalidation ให้โดยอัตโนมัติ -3. **Global Client State (สถานะส่วนกลางฝั่ง Client):** - - **เครื่องมือ:** **Zustand** (แนะนำ) หรือ Context API - - **ใช้เมื่อ:** จัดการข้อมูลที่ต้องใช้ร่วมกันทั่วทั้งแอป และ _ไม่ใช่_ ข้อมูลจากเซิร์ฟเวอร์ (เช่น ข้อมูล User ที่ล็อกอิน, สิทธิ์ Permissions) -4. **Form State (สถานะของฟอร์ม):** - - **เครื่องมือ:** **React Hook Form** + **Zod** - - **ใช้เมื่อ:** จัดการฟอร์มที่ซับซ้อน (เช่น ฟอร์มสร้าง RFA, ฟอร์ม Circulation [cite: 3.7]) +สำหรับ Next.js App Router เราจะใช้ State Management แบบ Simplified โดยแบ่งเป็น 3 ระดับหลัก: + +- 4.10.ๅ. **Server State (สถานะข้อมูลจากเซิร์ฟเวอร์)** + + - **เครื่องมือ:** **TanStack Query (React Query)** + - **ใช้เมื่อ:** จัดการข้อมูลที่ดึงมาจาก NestJS API ทั้งหมด + - **ครอบคลุม:** รายการ correspondences, rfas, drawings, users, permissions + - **ประโยชน์:** จัดการ Caching, Re-fetching, Background Sync อัตโนมัติ + +- 4.10.2. **Form State (สถานะของฟอร์ม):** + + - **เครื่องมือ:** **React Hook Form** + **Zod** (สำหรับ validation) + - **ใช้เมื่อ:** จัดการฟอร์มที่ซับซ้อนทั้งหมด + - **ครอบคลุม:** ฟอร์มสร้าง/แก้ไข RFA, Correspondence, Circulation + - **รวมฟีเจอร์:** Auto-save drafts ลง LocalStorage + +- 4.10.3. **UI State (สถานะ UI ชั่วคราว):** + + - **เครื่องมือ:** **useState**, **useReducer** (ใน Component) + - **ใช้เมื่อ:** จัดการสถานะเฉพาะ Component + - **ครอบคลุม:** Modal เปิด/ปิด, Dropdown state, Loading states + +- **ยกเลิกการใช้:** + + - ❌ Zustand (ไม่จำเป็น เนื่องจากใช้ React Query และ React Hook Form) + - ❌ Context API สำหรับ Server State (ใช้ React Query แทน) + +- **ตัวอย่าง Implementation:** + +```typescript +// ใช้ React Query สำหรับ data fetching +const { data: correspondences, isLoading } = useQuery({ + queryKey: ['correspondences', projectId], + queryFn: () => api.getCorrespondences(projectId), +}); + +// ใช้ React Hook Form สำหรับ forms +const { + register, + handleSubmit, + formState: { errors }, +} = useForm({ + resolver: zodResolver(correspondenceSchema), +}); +``` + +### 4.11 State Management Best Practices + +#### **4.11.1 หลักการพื้นฐาน:** + +- **Server State ≠ Client State:** แยก state ตามแหล่งที่มาให้ชัดเจน +- **ใช้ Tools ให้ถูกหน้าที่:** แต่ละ tool ใช้แก้ปัญหาที่เฉพาะเจาะจง +- **Avoid Over-engineering:** เริ่มจาก useState ก่อน แล้วค่อยขยายตามความจำเป็น + +#### **4.11.2 Decision Framework:** + +- **Server State:** ใช้ React Query หรือ SWR +- **Form State:** ใช้ React Hook Form หรือ Formik +- **UI State:** ใช้ useState/useReducer +- **Global App State:** ใช้ React Query หรือ Context API + +#### **4.11.3 Performance Considerations:** + +- ใช้ `useMemo` และ `useCallback` สำหรับ expensive computations +- ใช้ React Query's `select` option สำหรับ derived data +- หลีกเลี่ยง unnecessary re-renders ด้วย proper dependency arrays ## 🔐 **5. Security & Access Control (Full Stack Integration)** @@ -818,11 +945,13 @@ Views เหล่านี้ทำหน้าที่เป็นแหล ### **9.2 มาตรฐานฟอร์ม (Form Standards)** -- ต้องมีการใช้งาน Dropdowns แบบขึ้นต่อกัน (Dependent dropdowns) (ตามที่สคีมารองรับ): +- ใช้ **React Hook Form** เป็นมาตรฐานสำหรับฟอร์มทั้งหมด +- ใช้ **Zod** สำหรับ schema validation ทั้งฝั่ง client และ server +- ต้องมีการใช้งาน Dropdowns แบบขึ้นต่อกัน (Dependent dropdowns) (ตามที่สคีมารองรับ) ด้วย React Query สำหรับ data fetching และ React Hook Form สำหรับ state management: - Project → Contract Drawing Volumes - Contract Drawing Category → Sub-Category - RFA (ประเภท Shop Drawing) → Shop Drawing Revisions ที่เชื่อมโยงได้ -- **File Upload Security:** ต้องรองรับ **Multi-file upload (Drag-and-Drop)** [cite: 5.7] พร้อม virus scanning feedback +- **File Upload Security:** ต้องรองรับ **Multi-file upload (Drag-and-Drop)** ด้วย React Hook Form integration [cite: 5.7] พร้อม virus scanning feedback - **File Type Indicators:** UI ต้องอนุญาตให้ผู้ใช้กำหนดว่าไฟล์ใดเป็น **"เอกสารหลัก"** หรือ "เอกสารแนบประกอบ" [cite: 5.7] พร้อมแสดง file type icons - **Security Feedback:** แสดง security warnings สำหรับ file types ที่เสี่ยงหรือ files ที่ fail virus scan - ส่ง (Submit) ผ่าน API พร้อม feedback แบบ toast @@ -909,7 +1038,11 @@ Views เหล่านี้ทำหน้าที่เป็นแหล - [ ] **Idempotency:** API รองรับ Idempotency Key แล้ว - [ ] **File Upload:** ใช้ Flow Two-Phase (Temp -> Perm) แล้ว - [ ] **Mobile:** หน้าจอแสดงผลแบบ Card View บนมือถือได้ถูกต้อง -- [ ] **Performance:** สร้าง Index สำหรับ JSON Virtual Columns แล้ว (ถ้ามี) +- [ ] **Performance:** สร้าง Index สำหรับ JSON Virtual Columns แล้ว (ถ้ามี), ใช้ useMemo/useCallback ที่เหมาะสม +- [ ] **No Over-engineering:** ไม่ใช้ state management libraries เกินความจำเป็น +- [ ] **State Management:** ใช้ React Query สำหรับ server state, React Hook Form สำหรับ forms +- [ ] **Error Handling:** มี error boundaries และ proper error states +- [ ] **Type Safety:** มี proper TypeScript types สำหรับทั้งหมด state --- diff --git a/frontend.0/package.json b/frontend.0/package.json deleted file mode 100644 index 0d7029c..0000000 --- a/frontend.0/package.json +++ /dev/null @@ -1,44 +0,0 @@ -{ - "name": "lcbp3-frontend", - "version": "1.4.4", - "private": true, - "scripts": { - "dev": "next dev", - "build": "next build", - "start": "next start", - "lint": "next lint", - "format": "prettier --write ." - }, - "dependencies": { - "@hookform/resolvers": "^3.3.4", - "@radix-ui/react-slot": "^1.0.2", - "@tanstack/react-query": "^5.28.4", - "axios": "^1.6.8", - "class-variance-authority": "^0.7.0", - "clsx": "^2.1.0", - "date-fns": "^3.6.0", - "lucide-react": "^0.363.0", - "next": "14.1.4", - "next-auth": "^5.0.0-beta.16", - "react": "^18.2.0", - "react-dom": "^18.2.0", - "react-hook-form": "^7.51.1", - "tailwind-merge": "^2.2.2", - "tailwindcss-animate": "^1.0.7", - "zod": "^3.22.4", - "zustand": "^4.5.2" - }, - "devDependencies": { - "@types/node": "^20.11.30", - "@types/react": "^18.2.69", - "@types/react-dom": "^18.2.22", - "autoprefixer": "^10.4.19", - "eslint": "^8.57.0", - "eslint-config-next": "14.1.4", - "postcss": "^8.4.38", - "prettier": "^3.2.5", - "prettier-plugin-tailwindcss": "^0.5.12", - "tailwindcss": "^3.4.1", - "typescript": "^5.4.3" - } -} \ No newline at end of file