15 KiB
Prompt: ปรับปุ่มบันทึก Draft และ Validation ก่อนเปลี่ยนสถานะ Training Record
Objective
ปรับปรุงหน้าแก้ไขประวัติการอบรมที่มาจากสถานะ ฉบับร่าง หรือ ตีกลับ ให้ปุ่มและ Workflow ชัดเจนขึ้น โดยยังคงให้ผู้ใช้สามารถบันทึกฉบับร่างได้ และเพิ่มการตรวจสอบข้อมูลก่อนเปลี่ยนสถานะเป็น รอตรวจสอบ
Scope
ให้ตรวจสอบและปรับปรุงทุกส่วนที่เกี่ยวข้อง เช่น
- หน้า
training-records/new - หน้า Edit Training Record
- Training Record Form Component
- Validation Schema
- API / Server Action / Mutation
- Status Workflow
- หน้า List
training-records - เอกสารรายงานผลใน
docs/
Requirement
1. ปรับชื่อปุ่มในหน้า Edit Draft
เมื่อ Employee เปิดรายการสถานะ ฉบับร่าง มาแก้ไข
จากเดิม:
อัปเดตประวัติการอบรม
ให้เปลี่ยนเป็น:
บันทึกประวัติการอบรม
โดยปุ่มนี้ทำงานเหมือนการ ส่งตรวจสอบ
2. ยังคงมีปุ่มบันทึกฉบับร่าง
ในหน้า Edit ของรายการสถานะ ฉบับร่าง ต้องมีปุ่ม:
[บันทึกฉบับร่าง] [บันทึกประวัติการอบรม]
ความหมาย:
บันทึกฉบับร่าง= อัปเดตข้อมูล แต่ยังคงสถานะเป็น ฉบับร่างบันทึกประวัติการอบรม= ตรวจสอบข้อมูลให้ครบ แล้วเปลี่ยนสถานะเป็น รอตรวจสอบ
3. Validation ก่อนเปลี่ยนสถานะ
เมื่อกดปุ่ม:
บันทึกประวัติการอบรม
ระบบต้องใช้ Validation ชุดเดียวกับตอน Create / ส่งตรวจสอบ
ต้องตรวจสอบอย่างน้อย:
- ชื่อหลักสูตร
- วันที่อบรม
- ประเภทการอบรม
- จำนวนชั่วโมง
- ข้อมูลที่จำเป็นอื่นตาม Schema เดิม
- เงื่อนไข Public Training Attachment ตาม Requirement เดิม
กรณีประเภทการอบรมเป็น อบรมภายนอก (Public Training) ต้องแนบ Attachment ให้ครบก่อนจึงจะเปลี่ยนสถานะได้
4. กรณี Validation ไม่ผ่าน
ถ้าข้อมูลไม่ครบหรือไฟล์แนบไม่ถูกต้อง:
- ห้ามเปลี่ยนสถานะ
- รายการต้องยังคงเป็น ฉบับร่าง
- แสดง Error ทุกจุดที่ผิด
- ให้ผู้ใช้แก้ไขแล้วกดใหม่ได้
5. กรณี Validation ผ่าน
ถ้าข้อมูลครบถ้วน:
- บันทึกข้อมูลล่าสุด
- เปลี่ยนสถานะจาก ฉบับร่าง เป็น รอตรวจสอบ
- Redirect กลับไปหน้า:
training-records
6. หน้า List หลังเปลี่ยนสถานะ
หลังเปลี่ยนสถานะเป็น รอตรวจสอบ
- รายการต้องไม่อยู่ในกลุ่ม/ตัวกรอง ฉบับร่าง
- รายการต้องไปอยู่ในสถานะ รอตรวจสอบ
- Badge / Status ต้องแสดงถูกต้องตาม Pattern เดิมของระบบ
7. กรณี HRD ตีกลับ
เมื่อ HRD ตีกลับรายการ แล้ว Employee เปิดมาแก้ไข
ให้แสดงปุ่ม:
[บันทึกฉบับร่าง] [ส่งตรวจสอบอีกครั้ง]
ความหมาย:
บันทึกฉบับร่าง= บันทึกการแก้ไขไว้ก่อน ยังไม่ส่ง HRDส่งตรวจสอบอีกครั้ง= Validate ข้อมูล แล้วเปลี่ยนสถานะกลับเป็น รอตรวจสอบ
8. Logic ของปุ่มแต่ละสถานะ
ให้จัดการปุ่มตามสถานะดังนี้:
| สถานะ | ปุ่มที่แสดง | ผลลัพธ์ |
|---|---|---|
| สร้างใหม่ | บันทึกฉบับร่าง / ส่งตรวจสอบ | สร้าง Draft หรือสร้างรายการรอตรวจสอบ |
| ฉบับร่าง | บันทึกฉบับร่าง / บันทึกประวัติการอบรม | อัปเดต Draft หรือเปลี่ยนเป็นรอตรวจสอบ |
| ตีกลับ | บันทึกฉบับร่าง / ส่งตรวจสอบอีกครั้ง | บันทึก Draft หรือส่งตรวจสอบใหม่ |
| รอตรวจสอบ | ไม่ให้ Employee แก้ไข | อ่านอย่างเดียว |
| อนุมัติ | ไม่ให้ Employee แก้ไข | อ่านอย่างเดียว |
Technical Requirement
ก่อนแก้ไขต้องตรวจสอบ Pattern เดิมของโปรเจกต์ เช่น
- Form ใช้ React Hook Form / TanStack Form หรือ Pattern อื่น
- Validation ใช้ Zod หรือ Schema ใด
- Submit แยก Action ด้วย intent หรือ status หรือไม่
- API / Mutation / Server Action เดิมรับค่า status อย่างไร
- Status enum / constant ใช้ค่าอะไร
- หน้า List แยกสถานะหรือ filter อย่างไร
ห้ามเดาค่าเอง ต้องตรวจสอบจาก Source Code เดิมก่อนเสมอ
Implementation Steps
- ตรวจสอบหน้า Create และ Edit Training Record
- ตรวจสอบปุ่ม Submit เดิม
- ตรวจสอบ Workflow ของ Draft / Returned / Pending
- ตรวจสอบ Validation Schema เดิม
- ตรวจสอบ Public Training Attachment Requirement เดิม
- แยก Logic ระหว่าง Draft Save กับ Final Submit
- ปรับชื่อปุ่ม
อัปเดตประวัติการอบรมเป็นบันทึกประวัติการอบรมเฉพาะสถานะ Draft - เพิ่มปุ่ม
ส่งตรวจสอบอีกครั้งสำหรับรายการที่ถูก HRD ตีกลับ - ตรวจสอบให้ Validation ไม่ผ่านแล้วไม่เปลี่ยนสถานะ
- ตรวจสอบให้ Validation ผ่านแล้วเปลี่ยนสถานะเป็น
รอตรวจสอบ - Redirect กลับหน้า
training-records - ตรวจสอบหน้า List และ Badge สถานะ
- ตรวจสอบ TypeScript, ESLint และ Build
- สร้างรายงานผลไว้ใน
docs/
Expected Behavior
Case 1: เปิด Draft แล้วกดบันทึกฉบับร่าง
- บันทึกข้อมูลล่าสุด
- สถานะยังเป็น ฉบับร่าง
- ไม่บังคับ Validation เต็ม
- Redirect หรืออยู่หน้าเดิมตาม Pattern เดิมของระบบ
Case 2: เปิด Draft แล้วกดบันทึกประวัติการอบรม แต่ข้อมูลไม่ครบ
- Submit ไม่สำเร็จ
- สถานะยังเป็น ฉบับร่าง
- แสดง Error ทุกจุดที่ผิด
- ไม่เปลี่ยนเป็นรอตรวจสอบ
Case 3: เปิด Draft แล้วกดบันทึกประวัติการอบรม และข้อมูลครบ
- บันทึกข้อมูลล่าสุด
- เปลี่ยนสถานะเป็น รอตรวจสอบ
- Redirect กลับหน้า
training-records
Case 4: Public Training Draft ไม่แนบไฟล์ แล้วกดบันทึกประวัติการอบรม
- Submit ไม่สำเร็จ
- แสดง Error ว่าต้องแนบ Attachment
- สถานะยังเป็น ฉบับร่าง
Case 5: Public Training Draft แนบไฟล์ครบ แล้วกดบันทึกประวัติการอบรม
- Submit สำเร็จ
- สถานะเปลี่ยนเป็น รอตรวจสอบ
- Redirect กลับหน้า List
Case 6: รายการถูก HRD ตีกลับ
- Employee แก้ไขได้
- มีปุ่ม
บันทึกฉบับร่าง - มีปุ่ม
ส่งตรวจสอบอีกครั้ง - หาก Validation ผ่าน ให้เปลี่ยนสถานะกลับเป็น รอตรวจสอบ
Testing Checklist
- Draft แสดงปุ่ม
บันทึกฉบับร่าง - Draft แสดงปุ่ม
บันทึกประวัติการอบรม - ปุ่ม
อัปเดตประวัติการอบรมไม่แสดงใน Draft - กด
บันทึกฉบับร่างแล้วสถานะยังเป็น Draft - กด
บันทึกประวัติการอบรมแล้ว Validation ทำงานเต็ม - Validation ไม่ผ่านแล้วสถานะยังเป็น Draft
- Validation ผ่านแล้วสถานะเปลี่ยนเป็นรอตรวจสอบ
- Public Training ไม่แนบไฟล์แล้วส่งไม่ได้
- Public Training แนบไฟล์ครบแล้วส่งได้
- หลังส่งสำเร็จ Redirect กลับหน้า
training-records - หน้า List แสดงสถานะ
รอตรวจสอบถูกต้อง - รายการไม่อยู่ในกลุ่ม Draft หลังส่งตรวจสอบแล้ว
- รายการตีกลับแสดงปุ่ม
บันทึกฉบับร่าง - รายการตีกลับแสดงปุ่ม
ส่งตรวจสอบอีกครั้ง - รายการรอตรวจสอบ Employee แก้ไขไม่ได้
- รายการอนุมัติ Employee แก้ไขไม่ได้
- Layout ไม่เสียบน Desktop
- Layout ไม่เสียบน Mobile
- ไม่มี TypeScript Error
- ไม่มี ESLint Error
- Build ผ่าน
Report Requirement
หลังดำเนินการเสร็จ ให้สร้างเอกสารรายงานผลไว้ในโฟลเดอร์:
docs/
ตั้งชื่อไฟล์ประมาณนี้:
docs/training-record-draft-submit-workflow-report.md
ในรายงานต้องมีหัวข้อดังนี้:
# Training Record Draft Submit Workflow Report
## Summary
สรุปสิ่งที่ดำเนินการ
## Files Changed
รายการไฟล์ที่แก้ไข
## Requirement Mapping
Mapping ระหว่าง Requirement กับสิ่งที่แก้ไข
## Implementation Details
รายละเอียดการปรับปุ่มและ Workflow
## Button Behavior
สรุปพฤติกรรมของแต่ละปุ่มตามสถานะ
## Validation Rules
สรุป Validation ของ Draft Save และ Submit
## Status Workflow
อธิบาย Flow สถานะ ฉบับร่าง → รอตรวจสอบ → อนุมัติ/ตีกลับ
## Testing Result
ผลการทดสอบตาม Checklist
## Impact Analysis
ผลกระทบต่อระบบเดิม
## Notes / Limitations
ข้อจำกัดหรือสิ่งที่ควรตรวจสอบเพิ่มเติม
Important Rules
- ห้ามแก้ไขส่วนที่ไม่เกี่ยวข้อง
- ห้ามเปลี่ยน Database Schema หากไม่จำเป็น
- ห้ามเปลี่ยน Role Permission เดิมโดยไม่จำเป็น
- ต้องใช้ Pattern เดิมของโปรเจกต์
- ต้องรองรับ Public Training Attachment Requirement เดิม
- ต้องรองรับ Draft Feature เดิม
- ต้องตรวจสอบก่อนเปลี่ยนสถานะเสมอ
- Validation ไม่ผ่านต้องไม่เปลี่ยนสถานะ
- ต้องสร้างรายงานผลไว้ใน
docs/หลังดำเนินการเสร็จ