alla-tms/plans/organizers-module-fix.md

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 เท่านั้น

ห้ามใช้

delete()

เด็ดขาด

ต้องใช้

update();

พร้อมเปลี่ยนสถานะ

เช่น

isActive = false

หรือ

status = INACTIVE

หรือ Pattern เดิมของระบบ

หากไม่มี Field รองรับ

ให้เพิ่มตามมาตรฐานเดิมของ Project

เช่น

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

เช่น

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 หรือข้อเสนอแนะในการพัฒนาต่อในอนาคต