# Prompt: เพิ่มปุ่มบันทึกฉบับร่างใน Training Record Form ## Objective ปรับปรุงหน้า `training-records/new` และหน้าที่เกี่ยวข้องกับการแก้ไขประวัติการอบรม ให้รองรับการ **บันทึกฉบับร่าง** เพื่อให้พนักงานสามารถบันทึกข้อมูลการอบรมไว้ก่อนได้ แม้ข้อมูลหรือเอกสารแนบยังไม่ครบ และสามารถกลับมาแก้ไข/ส่งตรวจสอบภายหลังได้ ## Scope ให้ตรวจสอบและปรับปรุงทุกส่วนที่เกี่ยวข้อง เช่น - หน้า `training-records/new` - หน้า Edit Training Record - Training Record Form Component - Validation Schema - API / Server Action / Mutation - Status ของ Training Record - ตารางรายการประวัติการอบรม - สิทธิ์การแก้ไขตามสถานะ - เอกสารรายงานผลใน `docs/` ## Requirement ### 1. เพิ่มสถานะฉบับร่าง เพิ่มหรือรองรับสถานะรายการเป็น ```text ฉบับร่าง ``` หากระบบใช้ enum/status code ให้ตรวจสอบ Pattern เดิมก่อน เช่น ```ts DRAFT; ``` ห้ามเดาค่าเอง ให้ตรวจสอบ status เดิมของระบบก่อนแก้ไข ### 2. เพิ่มปุ่มในหน้า Create ในหน้า `training-records/new` ให้เพิ่มปุ่ม ```text บันทึกฉบับร่าง ``` โดยตำแหน่งปุ่มแนะนำเป็น ```text [ยกเลิก] [บันทึกฉบับร่าง] [ส่งตรวจสอบ] ``` หรือปรับตาม Layout เดิมของระบบ โดยต้องไม่ทำให้ UI เดิมเสีย ### 3. เพิ่มปุ่มในหน้า Edit กรณีเปิดรายการที่มีสถานะ **ฉบับร่าง** หรือ **ตีกลับ** ให้มีปุ่ม ```text [บันทึกฉบับร่าง] [ส่งตรวจสอบ] ``` เพื่อให้ผู้ใช้เลือกได้ว่าจะบันทึกไว้ก่อน หรือส่งให้ HRD ตรวจสอบ ### 4. พฤติกรรมของปุ่มบันทึกฉบับร่าง เมื่อกด **บันทึกฉบับร่าง** ระบบต้องบันทึกรายการด้วยสถานะ ```text ฉบับร่าง ``` และหลังบันทึกสำเร็จให้ Redirect กลับไปหน้า ```text training-records ``` ### 5. Validation สำหรับ Draft กรณีกด **บันทึกฉบับร่าง** ให้ผ่อนปรน Validation บางส่วนได้ เช่น - ยังไม่แนบไฟล์ได้ - ยังไม่กรอก URL ได้ - ยังไม่กรอกหมายเหตุได้ - ยังไม่กรอก Provider ได้ - ยังไม่กรอก Location ได้ แต่ยังควรบังคับข้อมูลหลัก เช่น - ชื่อหลักสูตร - วันที่อบรม - ประเภทการอบรม - จำนวนชั่วโมง ให้ตรวจสอบ Validation เดิมก่อน และปรับให้เหมาะสมตาม Pattern เดิมของโปรเจกต์ ### 6. Validation สำหรับส่งตรวจสอบ กรณีกด **ส่งตรวจสอบ** ให้ใช้ Validation เต็มตามเงื่อนไขเดิมของระบบ เพิ่มเติมจาก Requirement ก่อนหน้า: หากประเภทการอบรมเป็น **อบรมภายนอก (Public Training)** ต้องบังคับแนบ Attachment ก่อนส่งตรวจสอบ แต่หากกด **บันทึกฉบับร่าง** ไม่ต้องบังคับแนบ Attachment แม้จะเป็น Public Training ### 7. สิทธิ์การมองเห็น Draft รายการสถานะ **ฉบับร่าง** - Employee เห็นเฉพาะ Draft ของตัวเอง - HRD/Admin ไม่ต้องนำ Draft ไปเข้าคิวตรวจสอบ - HRD/Admin จะเห็นหรือไม่เห็น Draft ให้ตรวจสอบ Pattern เดิมของระบบก่อน หากไม่มี Requirement ชัดเจน ให้แนะนำแนวทางใน `plan.md` ก่อนแก้ไข ### 8. Workflow สถานะ ให้รองรับ Flow ดังนี้ ```text ฉบับร่าง → รอตรวจสอบ → อนุมัติ / ตีกลับ ``` รายละเอียด: - Draft ยังไม่ส่งให้ HRD ตรวจ - Draft ยังแก้ไขได้โดยเจ้าของรายการ - เมื่อกดส่งตรวจสอบ ให้เปลี่ยนสถานะเป็น `รอตรวจสอบ` - เมื่อส่งตรวจสอบแล้ว Employee แก้ไขไม่ได้ - หาก HRD ตีกลับ รายการกลับมาให้ Employee แก้ไขและส่งใหม่ได้ ### 9. ตารางรายการ Training Records ให้ตรวจสอบหน้า List ของ `training-records` ต้องแสดงรายการ Draft ของ Employee เจ้าของรายการด้วย ควรแสดงสถานะเป็น Badge เช่น ```text ฉบับร่าง ``` และควรมี Action สำหรับแก้ไข Draft ได้ เช่น ```text แก้ไข ``` โดยใช้ UI Pattern เดิมของระบบ ### 10. Technical Requirement ก่อนแก้ไขต้องตรวจสอบก่อนว่าโปรเจกต์ใช้ Pattern ใด เช่น - React Hook Form - TanStack Form - Zod Validation - Server Action - API Route - TanStack Query Mutation - Prisma / SQL Server - Status enum / constant / master data ให้แก้ไขตาม Pattern เดิมเท่านั้น ห้ามสร้าง Logic ซ้ำ หากมี Shared Component หรือ Shared Schema อยู่แล้ว ## Implementation Steps 1. ตรวจสอบโครงสร้างหน้า `training-records/new` 2. ตรวจสอบหน้า Edit Training Record 3. ตรวจสอบ Training Record Form Component 4. ตรวจสอบ Validation Schema เดิม 5. ตรวจสอบ API / Mutation / Server Action สำหรับ Create/Update 6. ตรวจสอบ Status เดิมของ Training Record 7. เพิ่มหรือรองรับสถานะ `ฉบับร่าง` 8. เพิ่มปุ่ม `บันทึกฉบับร่าง` 9. แยก Logic ระหว่าง Draft Submit กับ Final Submit 10. ปรับ Validation ให้ Draft ผ่อนปรนได้ 11. ปรับ Public Training Attachment Rule ให้บังคับเฉพาะตอน `ส่งตรวจสอบ` 12. ปรับหน้า List ให้แสดง Draft ของ Employee เจ้าของรายการ 13. ทดสอบ Create Draft, Edit Draft, Submit Draft 14. ตรวจสอบ TypeScript, ESLint และ Build 15. สร้างเอกสารรายงานผลใน `docs/` ## Expected Behavior ### Case 1: สร้างรายการแล้วกดบันทึกฉบับร่าง - ระบบบันทึกสถานะเป็น `ฉบับร่าง` - ไม่บังคับแนบ Attachment - Redirect กลับไปหน้า `training-records` - รายการแสดงใน List ของ Employee เจ้าของรายการ ### Case 2: Public Training แล้วกดบันทึกฉบับร่างโดยไม่แนบไฟล์ - บันทึกได้ - สถานะเป็น `ฉบับร่าง` - ไม่ส่งให้ HRD ตรวจ ### Case 3: Public Training แล้วกดส่งตรวจสอบโดยไม่แนบไฟล์ - Submit ไม่ได้ - แสดง Validation Error - แจ้งว่าต้องแนบเอกสารก่อนส่งตรวจสอบ ### Case 4: เปิด Draft มาแก้ไข - แก้ไขข้อมูลได้ - มีปุ่ม `บันทึกฉบับร่าง` - มีปุ่ม `ส่งตรวจสอบ` ### Case 5: Draft ถูกส่งตรวจสอบ - สถานะเปลี่ยนเป็น `รอตรวจสอบ` - Employee ไม่สามารถแก้ไขได้ - รายการเข้าสู่ Flow HRD Review ### Case 6: HRD ตีกลับ - Employee สามารถแก้ไขรายการได้ - สามารถกด `บันทึกฉบับร่าง` หรือ `ส่งตรวจสอบ` ใหม่ได้ ## Testing Checklist - [ ] หน้า `training-records/new` มีปุ่ม `บันทึกฉบับร่าง` - [ ] กด Draft แล้วบันทึกสำเร็จ - [ ] Draft Redirect กลับไปหน้า `training-records` - [ ] Draft แสดงใน List ของ Employee เจ้าของรายการ - [ ] Draft ไม่เข้าคิว HRD Review - [ ] Draft ไม่บังคับแนบ Attachment - [ ] Public Training Draft ไม่บังคับแนบ Attachment - [ ] Public Training ส่งตรวจสอบโดยไม่แนบ Attachment ต้อง Submit ไม่ได้ - [ ] Public Training ส่งตรวจสอบพร้อม Attachment ต้อง Submit ได้ - [ ] Edit Draft ได้ - [ ] Edit Draft มีปุ่ม `บันทึกฉบับร่าง` และ `ส่งตรวจสอบ` - [ ] ส่ง Draft ไปตรวจสอบแล้วสถานะเปลี่ยนเป็น `รอตรวจสอบ` - [ ] รายการที่ส่งตรวจสอบแล้ว Employee แก้ไขไม่ได้ - [ ] รายการที่ HRD ตีกลับ Employee แก้ไขและส่งใหม่ได้ - [ ] Badge สถานะ `ฉบับร่าง` แสดงถูกต้อง - [ ] Layout ไม่เสียบน Desktop - [ ] Layout ไม่เสียบน Mobile - [ ] ไม่มี TypeScript Error - [ ] ไม่มี ESLint Error - [ ] Build ผ่าน ## Report Requirement หลังดำเนินการเสร็จ ให้สร้างเอกสารรายงานผลไว้ในโฟลเดอร์ ```text docs/ ``` ตั้งชื่อไฟล์ประมาณนี้ ```text docs/training-record-draft-feature-report.md ``` ในรายงานต้องมีหัวข้อดังนี้ ```md # Training Record Draft Feature Report ## Summary สรุปสิ่งที่ดำเนินการ ## Files Changed รายการไฟล์ที่แก้ไข ## Requirement Mapping Mapping ระหว่าง Requirement กับสิ่งที่แก้ไข ## Implementation Details รายละเอียดการเพิ่มปุ่ม Draft, Workflow, Validation และ Permission ## Status Workflow อธิบาย Flow สถานะ ฉบับร่าง → รอตรวจสอบ → อนุมัติ/ตีกลับ ## Validation Rules สรุป Validation ของ Draft และ Submit ## Testing Result ผลการทดสอบตาม Checklist ## Impact Analysis ผลกระทบต่อระบบเดิม ## Notes / Limitations ข้อจำกัดหรือสิ่งที่ควรตรวจสอบเพิ่มเติม ``` ## Important Rules - ห้ามแก้ไขส่วนที่ไม่เกี่ยวข้อง - ห้ามเปลี่ยน Role Permission เดิมโดยไม่จำเป็น - ห้ามเปลี่ยน Database Schema หากไม่จำเป็น - หากจำเป็นต้องเพิ่ม Status/Enum/Database Field ต้องอธิบายเหตุผลใน `plan.md` ก่อน - ต้องใช้ Pattern เดิมของโปรเจกต์ - ต้องรองรับ Requirement Public Training Attachment เดิม - ต้องสร้างรายงานผลไว้ใน `docs/` หลังดำเนินการเสร็จ - หากพบความเสี่ยงหรือจุดที่กระทบหลายหน้า ให้สรุปใน `plan.md` ก่อนแก้ไข ## Implementation Notes - This feature requires a real DB enum extension because the current `approval_status` only supports `pending`, `approved`, `rejected`, and `needs_revision`; there is no existing persisted draft value to reuse safely. - Implementation decision: add `draft` to `approval_status` and use the existing `needs_revision` status as the employee-editable returned-for-revision state. - Implementation decision: drafts will be excluded from the HRD `pending-review` queue, but remain visible in the main `training-records` listing for HRD/Admin to preserve the current organization-wide visibility pattern unless a later requirement says otherwise.