Files
alla-tms/plans/training-record-submit.md
2026-07-16 09:53:14 +07:00

831 lines
10 KiB
Markdown

# Training Record Draft Submit Workflow Review & Fix
## Objective
ตรวจสอบ วิเคราะห์ และแก้ไขปัญหา Workflow ของการส่งประวัติการอบรม (Training Record) จากสถานะ "ฉบับร่าง (Draft)" ไปเป็น "รอตรวจสอบ (Pending Review)"
ปัจจุบันพบ Runtime Error
```
พนักงานสามารถอัปโหลดเอกสารได้เฉพาะรายการที่อยู่ในสถานะฉบับร่างหรือขอแก้ไขเท่านั้น
```
**ห้ามแก้ไขจากการคาดเดา**
ต้องตรวจสอบ Source Code และลำดับการทำงานจริงก่อนทุกครั้ง
---
# Project Rules
ก่อนแก้ไขให้ปฏิบัติตาม
- AGENTS.md
- docs/AI_DEVELOPMENT_GUIDE.md
- docs/PROJECT_ARCHITECTURE.md
ห้ามสร้าง Pattern ใหม่ หากระบบเดิมมี Pattern รองรับอยู่แล้ว
Reuse
- Shared Components
- Shared Services
- Shared Mutations
- Shared Queries
- Shared Hooks
- Shared Upload Components
---
# Scope (Mandatory)
การตรวจสอบและแก้ไข **ต้องครอบคลุมทั้งระบบ**
ห้ามตรวจสอบหรือแก้ไขเฉพาะ
```
Training Record ID = 277
```
Record 277 เป็นเพียงตัวอย่างที่พบปัญหาเท่านั้น
ต้องตรวจสอบทุก Workflow ที่เกี่ยวข้องกับ
- Create Training Record
- Save Draft
- Edit Draft
- Submit Draft
- Revision Requested
- Re-submit
- Upload Certificate
- Upload Supporting Files
- Remove Files
- HRD Review
- Employee View
ต้องยืนยันว่า Logic ทำงานถูกต้องกับทุก Record
ห้าม
- Hardcode Record ID
- Hardcode Status
- แก้ไขเฉพาะหน้าเดียว
- แก้เฉพาะเคสตัวอย่าง
การแก้ไขต้องอยู่ในระดับ
- Shared Workflow
- Shared Mutation
- Shared Upload Logic
- Shared Status Guard
---
# Current User Flow
ผู้ใช้งานทำงานดังนี้
```
Create Training Record
Save Draft
Open Draft
Edit
Click "บันทึกประวัติการอบรม"
Runtime Error
```
Backend ส่งข้อความ
```
พนักงานสามารถอัปโหลดเอกสารได้เฉพาะรายการที่อยู่ในสถานะฉบับร่างหรือขอแก้ไขเท่านั้น
```
---
# Expected Workflow
Workflow ที่ถูกต้องต้องเป็น
```
Create
Save Draft
Edit Draft
Validate
Save Form
Upload Certificate
Upload Supporting Files
Verify Upload Success
Update Status
Draft
Pending Review
Refresh Query
Redirect
```
ห้ามเปลี่ยน Status ก่อน Upload ทุกชนิดเสร็จ
---
# Mandatory Investigation
## 1. Workflow Analysis
ค้นหา
- handleSubmit
- onSubmit
- submitTrainingRecord
- updateTrainingRecord
- saveTrainingRecord
- uploadCertificate
- uploadAttachment
- saveDraft
- submitDraft
สร้าง Flow Diagram ปัจจุบัน
เช่น
```
Save
Update Status
Upload
```
หรือ
```
Save
Upload
Update Status
```
---
## 2. Execution Timeline
ห้ามเดาจาก Error
ต้องสร้าง Timeline จริง
```
User Click
Validation
Mutation A
Mutation B
Mutation C
Upload
Status Changed
Redirect
```
ระบุ
- API ไหนเรียกก่อน
- API ไหนเรียกหลัง
- API ไหน await
- API ไหนทำงานพร้อมกัน
---
## 3. API Call Order
ตรวจสอบทุก API
เช่น
```
PATCH Training Record
POST Certificate
POST Attachment
PATCH Status
```
สร้างลำดับจริง
---
## 4. React Query Analysis
ตรวจสอบ
- useMutation
- mutate
- mutateAsync
- invalidateQueries
- refetch
- router.refresh
- router.push
- router.replace
สร้าง Flow ของ Mutation
---
## 5. Async Analysis
ตรวจสอบ
- async
- await
- Promise.all
- Promise.allSettled
- Promise.any
- queueMicrotask
- setTimeout
- background upload
หากพบ
ให้วิเคราะห์ผลกระทบต่อ Workflow
---
## 6. Race Condition Analysis
ตรวจสอบว่ามี Race Condition หรือไม่
ตัวอย่าง
```
PATCH Status
────────────┐
Pending Review
POST Upload
```
หากพบ
อธิบาย
- สาเหตุ
- หลักฐาน
- วิธีแก้ไข
---
## 7. Upload Component Analysis
ตรวจสอบ
- CertificateUploader
- AttachmentUploader
- Dropzone
- Upload Hook
ว่ามี
- Auto Upload
- Upload On Mount
- Upload After Save
- Upload After State Change
หรือไม่
---
## 8. Component Lifecycle
ตรวจสอบ
- useEffect
- useMemo
- useCallback
ว่าทำให้ Upload หลัง Status เปลี่ยนหรือไม่
---
## 9. Backend Rule
ตรวจสอบ Business Rule
Backend อนุญาต Upload เฉพาะ
- Draft
- Revision Requested
ห้ามแก้ไข Rule นี้
ถือว่าเป็น Business Rule ที่ถูกต้อง
Frontend ต้องทำงานให้สอดคล้องกับ Backend
---
# UI Review
ตรวจสอบทุกหน้าที่เกี่ยวข้อง
เมื่อ Status ไม่ใช่
- Draft
- Revision Requested
ต้อง
- Disable Upload
- Disable Remove File
- Disable Save Draft
- Disable Submit
หรือแสดงเป็น Readonly
ห้ามเปิดให้ Upload แล้วปล่อยให้ Backend Reject
---
# Error Handling
Runtime Error ต้องไม่เกิด
ทุก Mutation
ทุก Upload
ทุก API
ต้องมี
```
try/catch
```
หรือ
```
mutation.onError
```
แสดง
- Toast
- Inline Error
แทน Runtime Error
---
# Validation
ก่อน Submit
ต้องผ่าน Validation ทั้งหมด
หาก Validation ไม่ผ่าน
- ไม่ Upload
- ไม่ Submit
- ไม่เปลี่ยน Status
---
# Required Fix
หากพบ
```
Update Status
Upload
```
ให้แก้เป็น
```
Validate
Save Form
Upload Certificate
Upload Attachment
Verify Upload Success
Update Status
Invalidate Query
Redirect
```
---
# Regression Test
ทดสอบทุก Record
ไม่ใช่เฉพาะ Record 277
อย่างน้อย
## Case 1
Draft
Create
Save Draft
Edit
Submit
Expected
Success
---
## Case 2
Draft
Upload Certificate
Submit
Expected
Success
---
## Case 3
Draft
Upload Multiple Attachments
Submit
Expected
Success
---
## Case 4
Revision Requested
Edit
Upload
Submit
Expected
Success
---
## Case 5
Pending Review
Open
Expected
Readonly
Upload Disabled
---
## Case 6
Approved
Open
Expected
Readonly
---
## Case 7
Rejected
Open
Expected
เป็นไปตาม Business Rule
---
## Case 8
Existing Draft with Existing Files
Edit
Replace Files
Submit
Expected
Success
---
## Case 9
Existing Draft without Files
Submit
Expected
ทำงานตาม Validation
---
## Case 10
หลาย Record พร้อมกัน
Draft A
Draft B
Draft C
ต้องทำงานถูกต้องทุก Record
---
# Deliverables
สร้างเอกสาร
```
docs/reports/training-record-submit-workflow-review.md
```
ประกอบด้วย
## Executive Summary
สรุปปัญหา
---
## Current Workflow
Flow เดิม
---
## Expected Workflow
Flow ใหม่
---
## Execution Timeline
Timeline จริง
---
## API Call Sequence
ลำดับ API
---
## React Query Flow
Mutation ทั้งหมด
---
## Async Analysis
await / Promise
---
## Race Condition Analysis
พบหรือไม่
หลักฐาน
---
## Upload Component Review
ผลการตรวจสอบ
---
## Root Cause
อธิบายสาเหตุที่แท้จริง
พร้อมหลักฐาน
ห้ามสรุปจากการคาดเดา
---
## Files Modified
รายชื่อไฟล์ทั้งหมด
พร้อมเหตุผล
---
## Risk Assessment
ผลกระทบ
- Employee
- HRD
- Admin
---
## Regression Test Result
ผลการทดสอบทุก Case
---
## Remaining Issues
สิ่งที่ควรปรับปรุงต่อ
---
# Constraints
ห้าม
- เปลี่ยน Business Rule ของ Backend
- Hardcode Status
- Hardcode Record ID
- Hardcode Permission
- สร้าง API ใหม่ หาก API เดิมรองรับ
- เปลี่ยน Database Schema โดยไม่จำเป็น
- เปลี่ยน Public Interface ของ Shared Component หากไม่มีเหตุผล
ต้อง
- Reuse Shared Components
- Reuse Shared Services
- Reuse Existing Pattern
- รักษา Coding Style ของโปรเจค
- แก้ไขที่ Root Cause ไม่ใช่แก้ปลายเหตุ
- ตรวจสอบให้ครอบคลุมทั้งระบบ ไม่ใช่เฉพาะเคสตัวอย่าง