# Prompt: Organizers Module Enhancement (CRUD + Soft Delete + Permission + Audit) ## Objective ดำเนินการตรวจสอบ วิเคราะห์ ออกแบบ และพัฒนา Module **Organizers** ให้รองรับการจัดการข้อมูลแบบสมบูรณ์ (CRUD) โดยใช้หลักการ **Soft Delete** และสอดคล้องกับ Architecture ของระบบปัจจุบัน การดำเนินการต้องครอบคลุม - Create Organizer - View Organizer - Edit Organizer - Soft Delete Organizer - Permission Control - Validation - Audit Log - UI/UX Improvement - Regression Testing - Documentation --- # Background ระบบนี้เป็น Training Management System (TMS) Architecture หลัก - Next.js App Router - TypeScript - Prisma ORM - TanStack Query - TanStack Form - shadcn/ui - Permission Template First - RBAC + Permission - Audit Log - Multi Organization ปัจจุบันหน้า Organizers สามารถสร้าง Organizer ได้เพียงบางส่วน และยังไม่มีความสามารถในการ - แก้ไข - ลบ - Soft Delete - Validation ครบถ้วน - Audit - Permission ครบ --- # IMPORTANT ก่อนแก้ไข AI ต้องตรวจสอบ Architecture เดิมก่อนทุกครั้ง ห้ามสร้าง Pattern ใหม่ หากระบบมี Pattern เดิมอยู่แล้ว ต้อง Reuse - Shared Components - Shared Dialog - Shared Form - Shared Validation - Shared Permission - Shared Toast - Shared Table/Card Pattern - Shared API Pattern - Shared Service Layer --- # Phase 0 — Architecture Audit ก่อนแก้ไข ตรวจสอบ ## Frontend - Organizer Page - Organizer List - Organizer Card - Create Form - Existing Components - Dialog Pattern - Sheet Pattern - Toast Pattern --- ## Backend ตรวจสอบ - API Routes - Route Handlers - Server Actions - Service Layer - Repository - Prisma Queries --- ## Database ตรวจสอบ Organizer Model เช่น - id - name - slug - createdAt - updatedAt ตรวจสอบว่ามี - status - isActive - deletedAt - deletedBy อยู่แล้วหรือไม่ ห้ามเดา ต้องอ้างอิงจาก Schema จริง --- ## Permission ตรวจสอบ ระบบใช้ Permission หรือ Business Role หรือ ทั้งสอง ให้ใช้ Pattern เดิมของระบบ --- # Phase 1 — Feature Analysis วิเคราะห์ Feature ปัจจุบัน ระบุว่า สิ่งใดทำได้แล้ว สิ่งใดยังไม่มี เช่น ✅ View ✅ Create ❌ Edit ❌ Delete ❌ Soft Delete ❌ Validation ❌ Audit --- # Phase 2 — UI Enhancement ปรับปรุงหน้า Organizers ## Organizer List แต่ละ Organizer Card ให้มี - Name - Slug - Status - Created Date และ Action ``` Edit Delete ``` ใช้ Component Pattern เดิมของระบบ --- ## Empty State หากไม่มี Organizer แสดง ``` ยังไม่มี Organizer ``` พร้อมปุ่ม ``` สร้าง Organizer ``` --- ## Loading รองรับ Loading Skeleton Spinner ตามมาตรฐานของระบบ --- ## Error State รองรับ Error Retry --- # Phase 3 — Create Organizer ตรวจสอบ Flow เดิม ปรับปรุง Validation Required - Organizer Name Validation - Required - Trim - Duplicate - Max Length - Invalid Character Slug สร้างตาม Pattern เดิมของระบบ ห้าม Hardcode --- # Phase 4 — Edit Organizer เพิ่มความสามารถ Edit Organizer สามารถแก้ไข - Organizer Name หากระบบรองรับ สามารถแก้ไข - Description - Status ห้ามแก้ไข - Organizer ID ห้ามเปลี่ยนข้อมูลที่กระทบ Foreign Key --- ใช้ Dialog หรือ Sheet ตาม Pattern เดิมของระบบ --- # Phase 5 — Soft Delete ระบบต้องใช้ Soft Delete เท่านั้น ห้ามใช้ ```ts delete() ``` เด็ดขาด ต้องใช้ ```ts update(); ``` พร้อมเปลี่ยนสถานะ เช่น ``` isActive = false ``` หรือ ``` status = INACTIVE ``` หรือ Pattern เดิมของระบบ หากไม่มี Field รองรับ ให้เพิ่มตามมาตรฐานเดิมของ Project เช่น ```prisma isActive Boolean @default(true) deletedAt DateTime? deletedBy String? ``` --- # Soft Delete Rule เมื่อ Delete ข้อมูล Users Training Permission Audit History ต้องยังอยู่ครบ Frontend ต้องไม่แสดง Organizer แต่ Database ต้องยังมีข้อมูล --- # Confirmation Dialog ก่อน Delete แสดง Dialog ``` ยืนยันการปิดใช้งาน Organizer Organizer นี้จะไม่ถูกลบออกจากฐานข้อมูล ข้อมูลทั้งหมดจะยังคงอยู่ แต่จะไม่สามารถใช้งานได้ ต้องการดำเนินการต่อหรือไม่ ``` Buttons ``` Cancel Delete ``` Delete ใช้ Destructive Variant --- # Phase 6 — Query Update ทุก Query ที่ดึง Organizer ต้องกรองเฉพาะ Active เช่น ```ts where; status = ACTIVE; ``` หรือ ``` isActive = true ``` ตาม Pattern เดิม รวมถึง - Organizer Switcher - Dropdown - Select - Search - API - Dashboard --- # Phase 7 — Validation ตรวจสอบ Frontend Backend API Validation ทั้งหมด เช่น Required Duplicate Slug Name Length Invalid Character Inactive Record Not Found --- # Phase 8 — Permission ใช้ Permission First หากระบบรองรับแล้ว ห้ามใช้ ``` isHRD() businessRole ``` หาก Architecture ใหม่รองรับ Permission แล้ว ใช้ Permission เดิมของระบบ เช่น ``` organization:view organization:create organization:update organization:delete organization:manage ``` หรือ Permission ที่มีอยู่จริง --- เฉพาะ IT Admin Super Admin เท่านั้น ที่สามารถ Create Edit Delete ได้ Role อื่น ต้อง - ไม่เห็นปุ่ม - เรียก API ไม่ได้ - ได้ 403 --- # Phase 9 — Audit Log หากระบบรองรับ Audit ให้บันทึก ``` ORGANIZATION_CREATED ORGANIZATION_UPDATED ORGANIZATION_SOFT_DELETED ``` ข้อมูลที่ควรบันทึก - Organization ID - Name - User - Time - Old Value - New Value ตาม Pattern เดิม --- # Phase 10 — Regression Testing ตรวจสอบ ## Create - Success - Validation - Duplicate --- ## Edit - Success - Validation --- ## Delete - Confirmation - Soft Delete - ไม่ลบจริง --- ## Query Inactive ต้องไม่แสดง --- ## Switcher Inactive ต้องไม่แสดง --- ## Permission Employee ห้ามเห็น Staff ห้ามเห็น Manager ห้ามเห็น IT ใช้งานได้ Super Admin ใช้งานได้ --- ## Database ตรวจสอบ Record ยังอยู่ แต่ Inactive --- ## TypeScript ไม่มี Type Error --- ## ESLint ไม่มี Error --- ## Console ไม่มี console.log --- # Phase 11 — Code Quality ตรวจสอบ - Reuse Existing Components - Reuse Existing Dialog - Reuse Existing Form - Reuse Existing Mutation - Reuse Existing Query - ไม่มี Duplicate Logic - ไม่มี Dead Code - ไม่มี Unused Import - ไม่มี any ใหม่ - ไม่มี Hardcode --- # Deliverables แก้ไข Source Code เฉพาะส่วนที่จำเป็น --- สร้างรายงาน ``` docs/organizers-module-enhancement-report.md ``` --- # Report Structure ``` # Organizers Module Enhancement Report ## Executive Summary ## Current Architecture ## Current Limitation ## Root Cause Analysis ## Feature Comparison Before After ## Files Modified ## Database Changes ## API Changes ## UI Changes ## Permission Changes ## Validation Changes ## Soft Delete Design ## Audit Log ## Testing Result ### Create ### Edit ### Delete ### Permission ### Regression ## Risks ## Recommendations ## Future Improvements ``` --- # Constraints ห้าม - Physical Delete - Hardcode Permission - Hardcode Role - Hardcode Organization ID - เปลี่ยน Business Logic - เปลี่ยน Database Schema โดยไม่จำเป็น - เพิ่ม Library ใหม่ - ใช้ any - ลบข้อมูลจริง - Refactor Module อื่นที่ไม่เกี่ยวข้อง ต้อง - ใช้ Shared Components - ใช้ Shared Permission - ใช้ Shared Validation - ใช้ Shared API Pattern - ใช้ Shared Service Pattern - รักษา Type Safety - รักษา Coding Standard - รักษา Backward Compatibility --- # Final Response เมื่อดำเนินการเสร็จ ให้สรุปผลเป็นภาษาไทย โดยประกอบด้วย 1. Executive Summary 2. Root Cause ที่พบ 3. รายการ Feature ที่เพิ่ม 4. รายชื่อไฟล์ที่แก้ไข 5. การออกแบบ Soft Delete 6. Permission ที่ใช้ 7. Validation ที่เพิ่ม 8. ผลการทดสอบ (Create / Edit / Delete / Permission / Regression) 9. ความเสี่ยงที่เหลือ (ถ้ามี) 10. Path ของรายงาน ``` docs/organizers-module-enhancement-report.md ``` พร้อมระบุหากพบ Technical Debt หรือข้อเสนอแนะในการพัฒนาต่อในอนาคต