admin
812 lines
35 KiB
Markdown
812 lines
35 KiB
Markdown
# 🛡️ Module Edge Cases & Business Rules — LCBP3-DMS v1.8.1
|
||
|
||
---
|
||
|
||
title: 'Edge Cases, Business Rules, and Anti-Bug Specifications'
|
||
version: 1.8.1
|
||
status: updated
|
||
owner: Nattanin Peancharoen (Product Owner / System Architect)
|
||
last_updated: 2026-03-24
|
||
related:
|
||
|
||
- specs/01-Requirements/01-04-user-stories.md
|
||
- specs/01-Requirements/01-05-acceptance-criteria.md
|
||
- specs/01-Requirements/01-02-business-rules/01-02-02-doc-numbering-rules.md
|
||
- specs/06-Decision-Records/ADR-001-unified-workflow-engine.md
|
||
- specs/06-Decision-Records/ADR-016-security-authentication.md
|
||
- specs/06-Decision-Records/ADR-019-hybrid-identifier-strategy.md
|
||
- specs/03-Data-and-Storage/lcbp3-v1.8.0-schema-02-tables.sql
|
||
|
||
---
|
||
|
||
> [!IMPORTANT]
|
||
> เอกสารนี้ระบุ **Edge Cases ที่ต้อง Implement และ Test อย่างชัดเจน** เพื่อป้องกัน Bug ในระบบ Prod
|
||
> ทุก Edge Case มี **Expected Behavior** ที่ Developer และ QA ต้องยึดถือ
|
||
|
||
---
|
||
|
||
## 📐 วิธีอ่าน
|
||
|
||
- **EC-[MODULE]-[NNN]** = Edge Case ID
|
||
- **Severity:** 🔴 Critical | 🟠 High | 🟡 Medium
|
||
- **Type:** `Data Integrity` | `Security` | `Concurrency` | `UX` | `Business Rule`
|
||
|
||
---
|
||
|
||
## Module 1: Document Numbering Edge Cases
|
||
|
||
### EC-DN-001 — Concurrent Submission (Race Condition)
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Concurrency, Data Integrity
|
||
|
||
**Scenario:** User A และ User B กด Submit Correspondence พร้อมกันทุก millisecond สำหรับ Project/Type/Sender/Receiver เดียวกัน
|
||
|
||
**Expected Behavior:**
|
||
|
||
- ทั้งสองได้รับเลขเอกสาร **ต่างกัน** (เช่น 0001 และ 0002)
|
||
- ไม่มีเลข Duplicate ในระบบ
|
||
- API ทั้งสองตอบ 201 Created สำเร็จ
|
||
|
||
**Implementation Rule:**
|
||
|
||
```
|
||
1. Redis Redlock acquire บน counterKey ก่อน
|
||
2. ถ้า Lock ไม่ได้ใน 5 วินาที → 503 Service Unavailable (Retry-After: 3s)
|
||
3. DB SELECT FOR UPDATE อีกชั้น (Defense in Depth)
|
||
4. Increment counter → COMMIT → Release Lock
|
||
5. ห้ามใช้ AUTO_INCREMENT ของ DB โดยตรงสำหรับเลขเอกสาร
|
||
```
|
||
|
||
**Test Method:** Load Test 50 concurrent POST `/document-numbering/reserve` → Assert DISTINCT count = 50
|
||
|
||
---
|
||
|
||
### EC-DN-002 — Yearly Reset Boundary Condition
|
||
|
||
**Severity:** 🟠 High | **Type:** Business Rule, Data Integrity
|
||
|
||
**Scenario A:** Document ถูก Submit เวลา 23:59:59 วันที่ 31 ธันวาคม
|
||
**Scenario B:** Cron Job Reset Counter ทำงานตอนเที่ยงคืน แต่มี Document ในสถานะ RESERVED อยู่
|
||
|
||
**Expected Behavior (A):**
|
||
|
||
- ได้รับเลขของปีเก่า (counter ปีเก่า) — เวลา Submit คือที่กำหนด
|
||
- ถ้า Confirm หลังเที่ยงคืน → เลขยังเป็นของปีเก่า (ใช้เวลา Reserve ไม่ใช่ Confirm)
|
||
|
||
**Expected Behavior (B):**
|
||
|
||
- Cron Job ต้อง **Skip** เลขที่อยู่ใน RESERVED state — ไม่ Reset Counter จนกว่า Reservation จะ Expire หรือ Confirmed
|
||
- ถ้า Reset รันก่อน Expiry: Counter ใหม่เริ่ม 0001 แต่ Reserved เลขยังคงอยู่ (ไม่ถูก Overwrite)
|
||
|
||
**Implementation Rule:**
|
||
|
||
```
|
||
- Cron Job ติด Lock เดียวกับ Reserve Process ก่อน Reset
|
||
- Reset scope = 'YEAR_2025' → Counter Key ใหม่ = 'YEAR_2026'
|
||
- ไม่ Delete counter เก่า — แค่ Key ใหม่
|
||
```
|
||
|
||
---
|
||
|
||
### EC-DN-003 — Cancelled/Voided Number Must Not Reuse
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Business Rule, Data Integrity
|
||
|
||
**Scenario:** Document ถูก Submit → ได้เลข 0005 → Admin Cancel Document → User Submit ใหม่
|
||
|
||
**Expected Behavior:**
|
||
|
||
- เลขถัดไปต้อง **0006** ไม่ใช่ 0005
|
||
- เลข 0005 อยู่ใน `document_number_reservations` สถานะ CANCELLED ตลอดไป
|
||
- ไม่มีการ Reuse เลขที่ถูก Cancel เด็ดขาด
|
||
|
||
**Business Rule:** "เลขที่ออกแล้วต้องไปข้างหน้าเท่านั้น — ห้ามถอยหลัง"
|
||
|
||
---
|
||
|
||
### EC-DN-004 — Reservation TTL Expired Cleanup
|
||
|
||
**Severity:** 🟠 High | **Type:** Data Integrity, UX
|
||
|
||
**Scenario:** User Reserve เลข (TTL 5 นาที) แต่ Browser ปิดก่อน Confirm
|
||
|
||
**Expected Behavior:**
|
||
|
||
- หลัง 5 นาที → `document_number_reservations.status` เปลี่ยนเป็น EXPIRED (by Cron/TTL)
|
||
- Counter ไม่ถูก Decrement (เลขนั้นหายไปถาวร — ฟัน-หลอ-เลข เป็นที่ยอมรับ)
|
||
- ถ้า User กลับมา Confirm Token ที่ Expired → 410 Gone (Token expired)
|
||
|
||
**Implementation Rule:**
|
||
|
||
```sql
|
||
-- Cron ทุก 1 นาที
|
||
UPDATE document_number_reservations
|
||
SET status = 'EXPIRED'
|
||
WHERE status = 'RESERVED' AND expires_at < NOW();
|
||
```
|
||
|
||
---
|
||
|
||
### EC-DN-005 — Idempotency Key Duplicate Submission
|
||
|
||
**Severity:** 🟠 High | **Type:** Concurrency, UX
|
||
|
||
**Scenario:** Network ไม่เสถียร → User คลิก Submit 2 ครั้ง → Frontend ส่ง POST 2 ครั้งด้วย Idempotency-Key เดียวกัน
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Request แรก → ออกเลขใหม่ → 201 Created
|
||
- Request ที่สอง (same Idempotency-Key) → **Return เลขเดิม** → 200 OK (ไม่ออกเลขใหม่)
|
||
- ไม่ว่า Request ที่สองจะมาเร็วแค่ไหน
|
||
|
||
**Implementation Rule:** Cache Idempotency-Key ใน Redis (TTL 24h) → ถ้า Key เจอ → Return Cached Response
|
||
|
||
---
|
||
|
||
## Module 2: Workflow Engine Edge Cases
|
||
|
||
### EC-WF-001 — Concurrent Approval (Parallel Steps)
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Concurrency, Business Rule
|
||
|
||
**Scenario:** Workflow มี Parallel Approval (Engineer A **และ** Engineer B ต้อง Approve พร้อมกัน)
|
||
Engineer A Approve พร้อมกับ Engineer B Approve ใน millisecond เดียวกัน
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Workflow System บันทึกทั้งสอง Action อย่างถูกต้อง
|
||
- State เปลี่ยนเป็น "Approved" ก็ต่อเมื่อ **ทุก Parallel Branch** Complete แล้ว
|
||
- ไม่เกิด State Corruption (เช่น State ถูก Override โดย Action หนึ่ง)
|
||
|
||
**Implementation Rule:**
|
||
|
||
```
|
||
- DB Transaction Isolation: SERIALIZABLE สำหรับ State Transition
|
||
- Check: all parallel branches completed → ถ้าใช่ → advance to next state
|
||
- ถ้าไม่ใช่ → บันทึก partial approval เท่านั้น
|
||
```
|
||
|
||
---
|
||
|
||
### EC-WF-002 — Action on Wrong Workflow State
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Security, Business Rule
|
||
|
||
**Scenario A:** Reviewer พยายาม Approve เอกสารที่ถูก Cancel แล้ว
|
||
**Scenario B:** Reviewer Approve เอกสารที่ Approve ไปแล้ว (Double-click)
|
||
|
||
**Expected Behavior (A):**
|
||
|
||
- `GET /correspondences/:id` → status: CANCELLED → ปุ่ม Approve ไม่แสดง (UI)
|
||
- ถ้าโจมตีตรงๆ ผ่าน API → 422 Unprocessable Entity (Invalid state transition)
|
||
|
||
**Expected Behavior (B):**
|
||
|
||
- `workflow_state_transitions` ตรวจสอบ current_state + action ก่อน
|
||
- ถ้า Action ไม่ Valid สำหรับ State ปัจจุบัน → 409 Conflict (Already processed)
|
||
- Idempotency: ถ้า User กด Approve ซ้ำด้วย Action เดียวกัน → Return เดิม ไม่ Error
|
||
|
||
---
|
||
|
||
### EC-WF-003 — Force Proceed on Final State
|
||
|
||
**Severity:** 🟠 High | **Type:** Business Rule, UX
|
||
|
||
**Scenario:** Document Control กด "Force Proceed" บนเอกสารที่อยู่ใน APPROVED (Final State) แล้ว
|
||
|
||
**Expected Behavior:**
|
||
|
||
- ถ้าไม่มี Next State ใน DSL → ปุ่ม Force Proceed ไม่แสดง (UI)
|
||
- ถ้าเรียก API ตรงๆ → 422 (No next state available from current state)
|
||
|
||
---
|
||
|
||
### EC-WF-004 — Workflow Definition Changed During Execution
|
||
|
||
**Severity:** 🟡 Medium | **Type:** Business Rule, Data Integrity
|
||
|
||
**Scenario:** Admin แก้ไข Workflow DSL ขณะที่มี Workflow Instance กำลังดำเนินการอยู่
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Workflow Instance ที่กำลังเดินอยู่ **ใช้ DSL เวอร์ชันที่สร้าง Instance** (Snapshot at creation)
|
||
- Instance ใหม่ที่สร้างหลังจากนั้นใช้ DSL เวอร์ชันใหม่
|
||
- ไม่มีการ Interrupt Instance ที่กำลังเดินอยู่
|
||
|
||
**Implementation Rule:**
|
||
|
||
```
|
||
workflow_instances.workflow_definition_snapshot (JSON) — บันทึก DSL ณ เวลาสร้าง
|
||
ไม่ Reference workflow_definitions.id โดยตรงสำหรับ Active Instances
|
||
```
|
||
|
||
---
|
||
|
||
### EC-WF-005 — Deadline Passed — No Action Taken
|
||
|
||
**Severity:** 🟡 Medium | **Type:** Business Rule, UX
|
||
|
||
**Scenario:** Deadline ของ Organization ผ่านไปแล้ว แต่ User ยังไม่ Approve
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Workflow **ไม่ Auto-advance** (ต้องการ Human Decision เสมอ)
|
||
- Dashboard แสดง "Overdue" Badge (สีแดง)
|
||
- Notification Reminder ส่งซ้ำตาม Schedule (ไม่ใช่ตลอดเวลา — Anti-Spam)
|
||
- Document Control สามารถ Force Proceed ได้ (กรณีฉุกเฉิน)
|
||
|
||
---
|
||
|
||
## Module 3: File Storage Edge Cases
|
||
|
||
### EC-STOR-001 — File Upload During Network Interruption
|
||
|
||
**Severity:** 🟠 High | **Type:** UX, Data Integrity
|
||
|
||
**Scenario:** User Upload ไฟล์ 50MB ผ่าน Wi-Fi แล้วเน็ตหลุดระหว่าง Upload
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Partial upload ไม่ถูก Save ใน Temp Storage
|
||
- User เห็น Error: "การอัปโหลดล้มเหลว กรุณาลองใหม่" + ปุ่ม Retry
|
||
- Draft ข้อมูล Form (ที่ไม่ใช่ไฟล์) ยังอยู่ใน LocalStorage (Auto-saved)
|
||
- ถ้า Retry → อัปโหลดใหม่ทั้งหมด (ไม่มี Resume Upload ใน MVP)
|
||
|
||
---
|
||
|
||
### EC-STOR-002 — Virus Detected in Uploaded File
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Security
|
||
|
||
**Scenario:** User พยายาม Upload ไฟล์ที่ ClamAV ตรวจพบ Malware
|
||
|
||
**Expected Behavior:**
|
||
|
||
- ClamAV Scan ใน Temp Storage → พบ → ลบไฟล์ออกจาก Temp ทันที
|
||
- API ตอบ 422 Unprocessable Entity: `{ "error": "FILE_VIRUS_DETECTED", "filename": "..." }`
|
||
- Audit Log บันทึก: `VIRUS_DETECTED` + filename + user_id + ip_address
|
||
- Security Metric Counter ใน Dashboard เพิ่มขึ้น
|
||
- ไม่ดำเนินการ Submit Document ต่อ (ไม่ว่าไฟล์อื่นจะผ่านแล้ว)
|
||
|
||
---
|
||
|
||
### EC-STOR-003 — File Type Mismatch (MIME Sniffing Attack)
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Security
|
||
|
||
**Scenario:** Attacker เปลี่ยน Extension ไฟล์ `malware.exe` → `document.pdf` แล้ว Upload
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Backend ตรวจ MIME Type จาก **File Content** (ไม่ใช่ Extension)
|
||
- ถ้า MIME Type ไม่ตรงกับ Whitelist (PDF, DWG, ZIP, DOCX) → 400 Bad Request
|
||
- ถ้า Extension กับ MIME Type ไม่ตรงกัน → 400 Bad Request: "File type mismatch"
|
||
- Audit Log บันทึก Security Event
|
||
|
||
**Whitelist:**
|
||
|
||
```
|
||
PDF: application/pdf
|
||
DWG: application/acad, image/vnd.dwg
|
||
ZIP: application/zip, application/x-zip-compressed
|
||
DOCX: application/vnd.openxmlformats-officedocument.wordprocessingml.document
|
||
XLSX: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
|
||
```
|
||
|
||
---
|
||
|
||
### EC-STOR-004 — Orphan File Cleanup (Document Cancelled Before Confirm)
|
||
|
||
**Severity:** 🟠 High | **Type:** Data Integrity, Storage
|
||
|
||
**Scenario:** User Reserve Document Number → อัปโหลดไฟล์ไป Temp → Cancel Document → ออกจากหน้า
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Temp files ต้องถูกลบออกจาก Storage ภายใน 1 ชั่วโมง (Cleanup Cron)
|
||
- ไม่มี Orphan Files ใน Temp Storage เกิน TTL
|
||
- Permanent Storage ไม่มีไฟล์ที่ไม่มี Document Reference
|
||
|
||
**Implementation Rule:**
|
||
|
||
```typescript
|
||
// Cron ทุกชั่วโมง
|
||
// ลบ Temp files ที่ older than 1 hour และ ไม่ได้ถูก Confirm
|
||
```
|
||
|
||
---
|
||
|
||
### EC-STOR-005 — Duplicate File Upload Detection
|
||
|
||
**Severity:** 🟡 Medium | **Type:** UX, Storage
|
||
|
||
**Scenario:** User อัปโหลดไฟล์เดิมซ้ำสองครั้ง (ลืมว่าอัปโหลดแล้ว)
|
||
|
||
**Expected Behavior:**
|
||
|
||
- **ไม่ Block** การ Upload ซ้ำ — เก็บเป็น 2 Attachment แยกกัน
|
||
- แสดง Warning (ไม่ใช่ Error): "ไฟล์นี้อาจถูกอัปโหลดแล้ว — ชื่อเดียวกัน"
|
||
- User สามารถลบ Duplicate ออกก่อน Submit
|
||
|
||
---
|
||
|
||
## Module 4: RFA & Drawing Edge Cases
|
||
|
||
### EC-RFA-001 — 1 Shop Drawing Revision = Max 1 RFA Constraint
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Business Rule, Data Integrity
|
||
|
||
**Scenario:** Document Control พยายามสร้าง RFA ที่สอง สำหรับ Shop Drawing Revision เดิม
|
||
|
||
**Expected Behavior:**
|
||
|
||
- ตรวจสอบ: `rfas WHERE shop_drawing_revision_id = X AND status NOT IN ('REJECTED', 'CANCELLED')`
|
||
- ถ้ามี Active RFA อยู่แล้ว → 409 Conflict: "Shop Drawing Revision นี้มี RFA อยู่แล้ว"
|
||
- UI: Disable ปุ่ม "สร้าง RFA" ถ้า Revision มี Active RFA แล้ว
|
||
|
||
**Exception:** ถ้า RFA ก่อนหน้าถูก REJECTED หรือ CANCELLED → สร้างใหม่ได้
|
||
|
||
---
|
||
|
||
### EC-RFA-002 — RFA Revision While Previous Still Pending
|
||
|
||
**Severity:** 🟠 High | **Type:** Business Rule
|
||
|
||
**Scenario:** RFA Rev.A ยัง Pending Review อยู่ แต่ Contractor พยายามสร้าง Rev.B
|
||
|
||
**Expected Behavior:**
|
||
|
||
- ถ้า Rev.A ยังไม่มีคำตอบสุดท้าย (REJECTED/APPROVED/APPROVED_WITH_COMMENTS) → Block
|
||
- 409 Conflict: "ต้องรอคำตอบของ Revision ก่อนหน้าก่อน"
|
||
- ไม่อนุญาตให้มี 2 Active Revision พร้อมกัน
|
||
|
||
---
|
||
|
||
### EC-RFA-003 — Shop Drawing Uploaded to Wrong Category
|
||
|
||
**Severity:** 🟡 Medium | **Type:** Business Rule, UX
|
||
|
||
**Scenario:** User เลือก Discipline = "Structural" แต่ Upload Shop Drawing ที่เป็น Electrical
|
||
|
||
**Expected Behavior (MVP):**
|
||
|
||
- ไม่มี Auto-detection (AI Classification เป็น Phase 3)
|
||
- Validation: Discipline ต้องเลือก (ไม่มี Default)
|
||
- เตือนผู้ใช้ให้ตรวจสอบก่อน Submit (Review Mode)
|
||
- Reviewer ที่ Reject สามารถระบุเหตุผล "Wrong Discipline" ได้
|
||
|
||
---
|
||
|
||
### EC-RFA-004 — Transmittal Contains Mixed-Status RFAs
|
||
|
||
**Severity:** 🟠 High | **Type:** Business Rule
|
||
|
||
**Scenario:** Transmittal ถูกสร้างโดยรวม RFA บางฉบับที่ยัง DRAFT และบางฉบับที่ READY
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Transmittal Submit ได้เฉพาะเมื่อ **ทุก RFA ใน Transmittal** อยู่ในสถานะ READY (ไม่ใช่ DRAFT)
|
||
- ถ้ามี DRAFT อยู่ → 422: "RFA [เลข] ยังอยู่ใน Draft กรุณา Submit ก่อน"
|
||
- UI: แสดง Status ของแต่ละ RFA ใน Transmittal ก่อน Submit
|
||
|
||
---
|
||
|
||
### EC-RFA-005 — Edit Draft RFA Validation
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Business Rule, Data Integrity
|
||
|
||
**Scenario:** User พยายามแก้ไข RFA ที่ไม่ใช่สถานะ DRAFT หรือพยายามแก้ไข Shop Drawing Revision
|
||
|
||
**Expected Behavior:**
|
||
|
||
- ถ้าสถานะ ≠ DRAFT → 403 Forbidden: "สามารถแก้ไขได้เฉพาะในสถานะ Draft"
|
||
- ถ้าสถานะ = DRAFT → อนุญาตแก้ไข Subject, Body, Remarks, Description, Due Date
|
||
- Shop Drawing Revision ที่ผูกอยู่ **ไม่สามารถเปลี่ยนได้** (EC-RFA-001 enforced)
|
||
- Audit Log บันทึก UPDATE + user + timestamp ทุกครั้ง
|
||
- Details JSON schema_version คงที่ (ไม่อนุญาตเปลี่ยน version)
|
||
|
||
**Reference:** US-012a, AC-RFA-007
|
||
|
||
---
|
||
|
||
### EC-RFA-006 — Cancel Draft RFA Cascade Effects
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Business Rule, Data Integrity
|
||
|
||
**Scenario:** User ยกเลิก RFA ที่อยู่ในสถานะ DRAFT หรือพยายามยกเลิกที่ไม่ใช่ DRAFT
|
||
|
||
**Expected Behavior:**
|
||
|
||
- ถ้าสถานะ ≠ DRAFT → 403 Forbidden: "สามารถยกเลิกได้เฉพาะในสถานะ Draft"
|
||
- ถ้าสถานะ = DRAFT → RFA status เปลี่ยนเป็น CANCELLED
|
||
- Shop Drawing Revision ถูกปลดผูก (available = true) ทันที
|
||
- Audit Log บันทึก CANCELLED + reason + user + timestamp
|
||
- ไม่สามารถ Undo การ Cancel ได้ (ต้องสร้าง RFA ใหม่)
|
||
|
||
**Reference:** US-012b, AC-RFA-008
|
||
|
||
---
|
||
|
||
### EC-RFA-007 — Search Results RBAC Filtering
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Security, Business Rule
|
||
|
||
**Scenario:** Contractor A ค้นหา RFA แต่พยายามเห็น RFA ของ Contractor B โดยใช้ Advanced Filter
|
||
|
||
**Expected Behavior:**
|
||
|
||
- RFA ในสถานะ DRAFT → เห็นเฉพาะ originator organization (เจ้าของ RFA)
|
||
- RFA ในสถานะอื่น (SUBMITTED, FAP, APPROVED, REJECTED) → เห็นตามสิทธิ์ปกติ (project/contract scope)
|
||
- Elasticsearch query filter ด้วย `visible_to_organizations` array field
|
||
- Frontend ไม่แสดงผลลัพธ์ที่ไม่มีสิทธิ์ (return empty ไม่ใช่ error)
|
||
- API Response ไม่เปิดเผย entity_uuid ของเอกสารที่ไม่มีสิทธิ์
|
||
|
||
**Implementation:** Backend filter ใน service layer + Elasticsearch query filter
|
||
|
||
**Reference:** US-012c, AC-RFA-009, ADR-019
|
||
|
||
---
|
||
|
||
## Module 5: Authentication & Session Edge Cases
|
||
|
||
### EC-AUTH-001 — Token Refresh Race Condition
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Concurrency, Security
|
||
|
||
**Scenario:** Browser Tab A และ Tab B ทำ API Call พร้อมกันด้วย Access Token ที่ Expired
|
||
ทั้งสองตรวจพบ 401 และพยายาม Refresh Token พร้อมกัน
|
||
|
||
**Expected Behavior:**
|
||
|
||
- ใช้ **Single Refresh Promise Pattern**: Tab แรกที่ Refresh สำเร็จ → Tab ที่สองใช้ Token ใหม่ (ไม่ Refresh ซ้อน)
|
||
- ถ้า Tab ที่สอง Refresh ก็ได้ Token ใหม่เหมือนกัน → ถือว่า OK (Refresh Token ยังใช้ได้)
|
||
- Refresh Token ถูก Rotate ทุกครั้งที่ใช้ (Refresh Token Rotation)
|
||
|
||
**Implementation:** Frontend Singleton Refresh Promise ใน Axios Interceptor
|
||
|
||
---
|
||
|
||
### EC-AUTH-002 — Permission Changed While User is Logged In
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Security, Business Rule
|
||
|
||
**Scenario:** Admin เปลี่ยน Role ของ User จาก Document Control → Viewer ขณะที่ User กำลัง Login อยู่
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Redis Permission Cache ของ User ถูกล้าง **ทันที** (ไม่รอ TTL)
|
||
- Access Token เดิมยังใช้ได้จนหมดอายุ (15 นาที) — เป็นที่ยอมรับ
|
||
- **Request ถัดไปหลัง Token Refresh** → Permission ใหม่มีผล
|
||
- Maximum Lag: 15 นาที (= Access Token TTL)
|
||
|
||
---
|
||
|
||
### EC-AUTH-003 — Concurrent Login (Same Account, Multiple Devices)
|
||
|
||
**Severity:** 🟡 Medium | **Type:** Security, Business Rule
|
||
|
||
**Scenario:** User Login จาก 2 Device พร้อมกัน (PC และ Tablet)
|
||
|
||
**Expected Behavior (MVP):**
|
||
|
||
- อนุญาต (Session ทั้งสองทำงาน Independent)
|
||
- แต่ละ Device มี Refresh Token แยกกัน
|
||
- Logout จาก Device หนึ่ง → Revoke เฉพาะ Refresh Token ของ Device นั้น
|
||
|
||
**Future Enhancement (Phase 2):**
|
||
|
||
- Option: "Logout จาก Device อื่นทั้งหมด"
|
||
|
||
---
|
||
|
||
### EC-AUTH-004 — Account Deactivated While Logged In
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Security
|
||
|
||
**Scenario:** Admin Deactivate User Account ขณะที่ User กำลัง Login อยู่
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Redis: Blacklist User ID (ทุก Token ของ User นั้นถือว่า Invalid ทันที)
|
||
- Request ถัดไปของ User → 401 Unauthorized: "Account has been deactivated"
|
||
- User ถูก Redirect ไปหน้า Login พร้อม Message ชัดเจน
|
||
|
||
**Implementation:**
|
||
|
||
```typescript
|
||
// ใน JWT Guard: ตรวจ Redis Blacklist ก่อน Validate Token
|
||
const isBlacklisted = await redis.get(`user:blacklist:${userId}`);
|
||
if (isBlacklisted) throw new UnauthorizedException('Account deactivated');
|
||
```
|
||
|
||
---
|
||
|
||
## Module 6: Permission & RBAC Edge Cases
|
||
|
||
### EC-PERM-001 — Direct Object Reference (IDOR Attack)
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Security
|
||
|
||
**Scenario:** User A รู้ UUID ของเอกสาร User B (เช่น `/correspondences/550e8400-e29b-41d4-a716-446655440000`) แล้วเรียกตรงๆ
|
||
|
||
**Expected Behavior:**
|
||
|
||
- CASL AbilityGuard ตรวจสอบทั้ง Action และ Resource Owner (ADR-019)
|
||
- ถ้าไม่มีสิทธิ์ → **403 Forbidden** (ไม่ใช่ 404 — เพราะ 404 บอกว่ามีอยู่แต่หาไม่เจอ)
|
||
- **Exception:** ถ้าต้องการซ่อน Existence ของ Document → Return 404
|
||
- ทุก API ต้องผ่าน Permission Check โดยไม่มีข้อยกเว้น
|
||
- ParseUuidPipe ตรวจสอบ UUID format ก่อน query database
|
||
|
||
**Implementation:** UUID-based routing + CASL permissions
|
||
|
||
---
|
||
|
||
### EC-PERM-002 — Super Admin Impersonation Prevention
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Security
|
||
|
||
**Scenario:** User พยายาม Forge JWT payload เพิ่ม role: 'SUPERADMIN'
|
||
|
||
**Expected Behavior:**
|
||
|
||
- JWT ถูก Sign ด้วย Secret ที่ไม่เปิดเผย → Signature ไม่ตรง → 401 Invalid token
|
||
- Role ไม่ถูก Read จาก Token โดยตรงสำหรับ Permission Check — ต้อง Verify จาก DB/Redis
|
||
- JWT payload ใช้แค่ `user_id` → ดึง Permission จาก Redis Cache/DB
|
||
|
||
---
|
||
|
||
### EC-PERM-003 — Organization Switch Mid-session
|
||
|
||
**Severity:** 🟡 Medium | **Type:** Business Rule, UX
|
||
|
||
**Scenario (ถ้ามี):** User เป็นสมาชิกในหลาย Organization (กรณี Consultant ที่ทำงานหลายโครงการ)
|
||
|
||
**Expected Behavior:**
|
||
|
||
- User เห็นเฉพาะ Data ขององค์กรที่ Login อยู่ (Active Context)
|
||
- ถ้าต้องการดูอีก Org → ต้อง "Switch Organization" (Session Context เปลี่ยน)
|
||
- ไม่มี Cross-org Data Leak แม้ User เป็นสมาชิกทั้งสอง Org
|
||
|
||
---
|
||
|
||
## Module 7: Correspondence Edge Cases
|
||
|
||
### EC-CORR-001 — Cancel Correspondence with Downstream Circulation
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Business Rule, Data Integrity
|
||
|
||
**Scenario:** Correspondence ถูก Submit → ผู้รับสร้าง Circulation แล้ว → Originator ขอ Cancel
|
||
|
||
**Expected Behavior:**
|
||
|
||
- ต้องแจ้งเตือน Admin ว่า "มี Circulation ที่เปิดอยู่ [X รายการ] สำหรับเอกสารนี้"
|
||
- ต้องยืนยันก่อน Cancel: "การ Cancel จะส่งผลให้ Circulation ที่เกี่ยวข้องถูกปิดทั้งหมด"
|
||
- เมื่อ Confirm → Correspondence = CANCELLED + Circulation ที่เกี่ยวข้อง = FORCE_CLOSED
|
||
- Audit Log บันทึกทั้งหมด (CANCELLED + FORCE_CLOSED + reason + user)
|
||
|
||
---
|
||
|
||
### EC-CORR-002 — Reply to Cancel Correspondence
|
||
|
||
**Severity:** 🟡 Medium | **Type:** Business Rule
|
||
|
||
**Scenario:** Document Control พยายามสร้าง Correspondence เพื่อ Reply ต่อ Correspondence ที่ถูก Cancel
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Reply ทำได้ — Reference ถึง CANCELLED เอกสารได้ (เพื่อ acknowledge การยกเลิก)
|
||
- UI แสดง Warning: "กำลัง Reply ต่อเอกสารที่ถูกยกเลิกแล้ว"
|
||
- ไม่ Block การ Reply (เป็น Business Decision ไม่ใช่ Technical Constraint)
|
||
|
||
---
|
||
|
||
### EC-CORR-003 — Correspondence to Self (Same Organization)
|
||
|
||
**Severity:** 🟡 Medium | **Type:** Business Rule
|
||
|
||
**Scenario:** User พยายามสร้าง Correspondence ที่ Sender และ Receiver เป็นองค์กรเดียวกัน
|
||
|
||
**Expected Behavior:**
|
||
|
||
- External Correspondence (Letter/RFI) → Block: "ไม่สามารถส่งหาตัวเองได้"
|
||
- Internal Communication → ใช้ Circulation Sheet แทน (ไม่ใช่ Correspondence)
|
||
- UI Validation + Backend Validation (Double Check)
|
||
|
||
---
|
||
|
||
## Module 8: Circulation Edge Cases
|
||
|
||
### EC-CIRC-001 — Assignee Deactivated Before Completing Task
|
||
|
||
**Severity:** 🟠 High | **Type:** Business Rule, UX
|
||
|
||
**Scenario:** User ถูก Deactivate หลังจากถูก Assign ใน Circulation แต่ก่อน Respond
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Circulation ยัง Active อยู่ — ไม่หยุดอัตโนมัติ
|
||
- Document Control เห็น Warning: "Assignee [ชื่อ] ไม่ Active แล้ว"
|
||
- Document Control สามารถ Re-assign ไปยัง User อื่นได้
|
||
- Audit Log บันทึก Re-assign Event
|
||
|
||
---
|
||
|
||
### EC-CIRC-002 — Multi-Assignee: Partial Response
|
||
|
||
**Severity:** 🟡 Medium | **Type:** Business Rule, UX
|
||
|
||
**Scenario:** Circulation มี Action Assignees 3 คน — 2 คน Respond แล้ว แต่ 1 คนยังไม่ Respond
|
||
|
||
**Expected Behavior (MVP):**
|
||
|
||
- Document Control เห็นสถานะ "2/3 ตอบกลับแล้ว"
|
||
- Document Control สามารถ Force Close ได้ (พร้อมระบุเหตุผล)
|
||
- ถ้า Force Close → ทุก Partial Response ถูกบันทึก + หมายเหตุว่า Force Closed
|
||
|
||
---
|
||
|
||
### EC-CIRC-003 — Circulation Deadline = Today (Edge of Day)
|
||
|
||
**Severity:** 🟡 Medium | **Type:** Business Rule, UX
|
||
|
||
**Scenario:** Deadline ถูกกำหนด = "วันนี้" แต่ User ดูตอนบ่ายสอง
|
||
|
||
**Expected Behavior:**
|
||
|
||
- ถ้า Deadline = วันที่ X → หมดเขตเมื่อ X เวลา 23:59:59 (ไม่ใช่ 00:00:00)
|
||
- Reminder: ส่ง Notification เวลา 08:00 ของวัน Deadline
|
||
- Overdue Badge ขึ้นเมื่อ `NOW() > deadline_date + 1 day` (วันถัดไป 00:00)
|
||
|
||
---
|
||
|
||
## Module 9: Search & Elasticsearch Edge Cases
|
||
|
||
### EC-SRCH-001 — Search Index Lag (Eventual Consistency)
|
||
|
||
**Severity:** 🟡 Medium | **Type:** Data Consistency, UX
|
||
|
||
**Scenario:** Document ถูก Submit แล้ว → User ค้นหาทันที แต่ไม่เจอ
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Index อาจ Lag 5–30 วินาที (BullMQ Async Job)
|
||
- UI แสดง "เอกสารอาจใช้เวลาสักครู่ก่อนปรากฏในผลค้นหา"
|
||
- **ไม่ถือว่า Bug** — เป็น By Design (Eventual Consistency)
|
||
- User สามารถ Navigate ไปยังเอกสารได้ทันทีผ่าน Notification Link (ไม่ต้องรอ Search)
|
||
|
||
---
|
||
|
||
### EC-SRCH-002 — Permission-filtered Search Results
|
||
|
||
**Severity:** 🔴 Critical | **Type:** Security
|
||
|
||
**Scenario:** Contractor A ค้นหา Keyword ที่มีใน Document ของ Contractor B
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Elasticsearch Index ต้องมี `organization_id` / `contract_id` Field
|
||
- ทุก Search Query ต้อง Filter ด้วย `must: [{ term: { visible_to_org: userOrgId } }]`
|
||
- Contractor A **ไม่เห็น** Document ของ Contractor B ในผลค้นหา
|
||
- **ห้าม Filter ที่ Application Layer เท่านั้น** → ต้อง Filter ที่ Query Level
|
||
|
||
---
|
||
|
||
### EC-SRCH-003 — Special Characters in Search Query
|
||
|
||
**Severity:** 🟡 Medium | **Type:** Security, UX
|
||
|
||
**Scenario:** User ค้นหาด้วย `คคง. สค. - 2025` (มี `-`, `.`, ช่องว่าง)
|
||
|
||
**Expected Behavior:**
|
||
|
||
- ไม่ Crash — Elasticsearch รองรับ Special Characters
|
||
- Sanitize Query ก่อนส่ง (กัน Elasticsearch Injection)
|
||
- ผล Search ยังคง Relevance สูง
|
||
|
||
---
|
||
|
||
## Module 10: Notifications Edge Cases
|
||
|
||
### EC-NOTIF-001 — Notification Flood Prevention
|
||
|
||
**Severity:** 🟠 High | **Type:** UX, Anti-Spam
|
||
|
||
**Scenario:** Workflow มีหลาย Step ที่เปลี่ยนเร็ว → ส่ง Notification ทุก State Change → User ได้รับ Email 10 ฉบับในนาทีเดียว
|
||
|
||
**Expected Behavior:**
|
||
|
||
- **Notification Debounce/Batch:** รวม Notifications ภายใน 5 นาทีเป็น Summary Email เดียว
|
||
- ถ้าเปลี่ยน State 5 ครั้งใน 5 นาที → Email เดียว: "เอกสาร X มี 5 การเปลี่ยนแปลง"
|
||
- In-App Notifications ยังแสดงทุกรายการ (ไม่ Batch)
|
||
|
||
---
|
||
|
||
### EC-NOTIF-002 — User Unsubscribed from EMAIL but still needs In-App
|
||
|
||
**Severity:** 🟡 Medium | **Type:** UX, Business Rule
|
||
|
||
**Scenario:** User ปิด Email Notification แต่ยังต้องการ In-App Notification
|
||
|
||
**Expected Behavior:**
|
||
|
||
- Notification Settings: แยก Toggle สำหรับ Email / LINE / In-App
|
||
- Core Workflow Assignments (ที่ User ต้อง Action) → **ไม่สามารถ Disable** ทุก Channel ได้
|
||
- ต้องมี In-App อย่างน้อย 1 Channel สำหรับ Action Required Notifications
|
||
|
||
---
|
||
|
||
## 📊 Edge Case Summary by Module
|
||
|
||
| Module | Critical | High | Medium | Total |
|
||
| ------------------ | -------- | ----- | ------ | ------ |
|
||
| Document Numbering | 2 | 2 | 1 | 5 |
|
||
| Workflow Engine | 2 | 1 | 2 | 5 |
|
||
| File Storage | 2 | 2 | 1 | 5 |
|
||
| RFA & Drawing | 4 | 2 | 1 | 7 |
|
||
| Auth & Session | 3 | 0 | 1 | 4 |
|
||
| Permission & RBAC | 2 | 0 | 1 | 3 |
|
||
| Correspondence | 1 | 0 | 2 | 3 |
|
||
| Circulation | 0 | 1 | 2 | 3 |
|
||
| Search | 1 | 0 | 2 | 3 |
|
||
| Notifications | 0 | 1 | 1 | 2 |
|
||
| **รวม** | **17** | **9** | **14** | **40** |
|
||
|
||
---
|
||
|
||
## 🧪 Testing Strategy for Edge Cases
|
||
|
||
### สำหรับ Unit Tests (Backend)
|
||
|
||
```typescript
|
||
// ตัวอย่าง: EC-RFA-005 — Edit Draft RFA Validation
|
||
describe('RFAService - Edit Draft Validation', () => {
|
||
it('should allow edit when status is DRAFT', async () => {
|
||
const rfa = await service.createRFA({ status: 'DRAFT' });
|
||
const updated = await service.updateRFA(rfa.uuid, { subject: 'Updated' });
|
||
expect(updated.subject).toBe('Updated');
|
||
});
|
||
|
||
it('should reject edit when status is not DRAFT', async () => {
|
||
const rfa = await service.createRFA({ status: 'SUBMITTED' });
|
||
await expect(service.updateRFA(rfa.uuid, { subject: 'Updated' }))
|
||
.rejects.toThrow('403');
|
||
});
|
||
});
|
||
|
||
// ตัวอย่าง: EC-DN-001 — Concurrent Number Generation
|
||
describe('DocumentNumberingService - Concurrency', () => {
|
||
it('should generate unique numbers for concurrent requests', async () => {
|
||
const promises = Array.from({ length: 50 }, () => service.reserve({ projectId: 1, typeId: 2, orgId: 3 }));
|
||
const results = await Promise.all(promises);
|
||
const numbers = results.map((r) => r.documentNumber);
|
||
const unique = new Set(numbers);
|
||
expect(unique.size).toBe(50); // ไม่มีซ้ำ
|
||
});
|
||
});
|
||
```
|
||
|
||
### สำหรับ Integration Tests
|
||
|
||
- EC-DN-001: k6 Load Test Script (50 VUs, `/document-numbering/reserve`)
|
||
- EC-AUTH-001: Cypress Multi-tab Token Refresh Test
|
||
- EC-PERM-001: API Test Suite — Direct Object Reference สำหรับทุก Resource (UUID-based)
|
||
- EC-RFA-005~007: RFA CRUD operations test with different user roles
|
||
|
||
### สำหรับ Manual UAT
|
||
|
||
- EC-WF-001: Test Parallel Approval ด้วย 2 Browser Session พร้อมกัน
|
||
- EC-STOR-002: Upload EICAR Test File (ClamAV Test Virus)
|
||
- EC-RFA-001: สร้าง RFA สำหรับ Revision เดิมที่มี Active RFA → Assert Block
|
||
- EC-RFA-006: Cancel Draft RFA → Verify Shop Drawing Revision ถูกปลดผูก
|
||
- EC-RFA-007: Contractor A ค้นหา → Assert ไม่เห็น RFA ของ Contractor B
|
||
|
||
---
|
||
|
||
## 📝 Document Control
|
||
|
||
- **Version:** 1.8.1 | **Status:** updated
|
||
- **Created:** 2026-03-11 | **Updated:** 2026-03-24 | **Owner:** Nattanin Peancharoen
|
||
- **Changes:** Added EC-RFA-005~007 (Edit/Cancel/Search RFA), Updated UUID references (ADR-019), Sync with US-012a~012c and AC-RFA-007~009
|
||
- **Next Review:** Pre-UAT (T-2 สัปดาห์ก่อน Go-Live)
|
||
- **Classification:** Internal Use Only — Developer & QA Reference
|