168 lines
8.5 KiB
Markdown
168 lines
8.5 KiB
Markdown
# Prompt.md — สร้าง Plan.md สำหรับหน้า Role & Permission Management
|
|
|
|
## Context
|
|
|
|
โปรเจกต์นี้คือ Training Management System (TMS) ที่กำลังปรับระบบสิทธิ์จากแนวคิด Role-based เดิม ไปเป็น Permission-first โดยใช้ Permission Template เป็นหลัก
|
|
|
|
เป้าหมายรอบนี้คือ **ยังไม่ต้องแก้ไขโค้ดจริง** แต่ให้ตรวจสอบโครงสร้างระบบเดิม และสร้างเอกสาร `Plan.md` สำหรับการพัฒนาหน้า Role & Permission Management อย่างเป็นระบบ
|
|
|
|
## Current Direction
|
|
|
|
ระบบต้องไม่ใช้ Role เป็นตัวกำหนดสิทธิ์หลักอีกต่อไป แต่ให้ใช้ Permission Template เป็นแกนหลัก
|
|
|
|
Role เดิม เช่น Employee, Staff, Manager, IT Admin, Super Admin อาจยังคงมีไว้เพื่อ compatibility หรือ metadata แต่สิทธิ์การใช้งานจริงต้องอ้างอิงจาก Permission Template และ Permission รายการย่อย
|
|
|
|
## Requirement Summary
|
|
|
|
ต้องสร้างแผนสำหรับหน้าจัดการ Role และ Permission โดยมีแนวคิดหลักดังนี้
|
|
|
|
1. มีหน้า Permission Template Management แยกจากหน้า User Permission Assignment
|
|
2. ผู้ใช้ 1 คนสามารถมี Permission Template ได้เพียง 1 Template เท่านั้น
|
|
3. ผู้ใช้สามารถมี Extra Permission หรือ Override Permission เพิ่มเติมรายบุคคลได้
|
|
4. Permission ต้องรองรับทั้งระดับเมนู และระดับ Action
|
|
5. ผู้ที่จัดการ Permission ได้คือ Super Admin เท่านั้น
|
|
6. การลบ Permission Template ต้องเป็น Soft Delete หรือ Deactivate เท่านั้น
|
|
7. ต้องมี Template เริ่มต้น ได้แก่
|
|
- Employee / User
|
|
- Staff
|
|
- Manager
|
|
- IT Admin
|
|
- Super Admin
|
|
|
|
8. ทุกการเปลี่ยนแปลง Permission ต้องบันทึก Audit Log
|
|
9. รอบนี้ให้สร้าง `Plan.md` เท่านั้น ยังไม่ต้องแก้ไขโค้ดจริง
|
|
|
|
## Pages to Plan
|
|
|
|
### 1. Permission Template Management Page
|
|
|
|
ควรวางแผนหน้าสำหรับจัดการ Permission Template โดยรองรับ
|
|
|
|
- แสดงรายการ Template ทั้งหมด
|
|
- สร้าง Template ใหม่
|
|
- แก้ไข Template
|
|
- Clone Template
|
|
- Soft Delete / Deactivate Template
|
|
- เปิด/ปิดการใช้งาน Template
|
|
- ดูจำนวนผู้ใช้ที่ใช้งาน Template
|
|
- ดู Permission ภายใน Template
|
|
- ป้องกันการลบ Template ที่เป็น system default โดยตรง
|
|
- จำกัดการเข้าถึงเฉพาะ Super Admin
|
|
|
|
### 2. Permission Matrix Page
|
|
|
|
ควรวางแผนหน้าสำหรับจัดการ Permission แบบ Matrix
|
|
|
|
Permission ควรแบ่งตาม Module และ Action เช่น
|
|
|
|
Modules ตัวอย่าง:
|
|
|
|
- Dashboard
|
|
- Training Records
|
|
- Online Lessons
|
|
- Announcements
|
|
- Employees
|
|
- Courses
|
|
- Approvals
|
|
- Reports
|
|
- Settings
|
|
- Permission Management
|
|
|
|
Actions ตัวอย่าง:
|
|
|
|
- View
|
|
- Create
|
|
- Edit
|
|
- Delete
|
|
- Approve
|
|
- Publish
|
|
- Export
|
|
- Manage
|
|
|
|
ต้องวางแผนให้สามารถเลือก Permission ได้ทั้งระดับเมนูและระดับ Action
|
|
|
|
### 3. User Permission Assignment Page
|
|
|
|
ควรวางแผนหน้าสำหรับกำหนดสิทธิ์รายผู้ใช้ โดยรองรับ
|
|
|
|
- ค้นหาผู้ใช้
|
|
- แสดงข้อมูลผู้ใช้ เช่น รหัสพนักงาน ชื่อ แผนก ตำแหน่ง
|
|
- เลือก Permission Template ได้ 1 Template
|
|
- เพิ่ม Extra Permission รายบุคคลได้
|
|
- Override / Remove Permission บางรายการได้ หากจำเป็น
|
|
- Preview สิทธิ์สุดท้ายที่ผู้ใช้จะได้รับ
|
|
- บันทึกการเปลี่ยนแปลง
|
|
- จำกัดการเข้าถึงเฉพาะ Super Admin
|
|
|
|
### 4. Audit Log Page
|
|
|
|
ควรวางแผนหน้าสำหรับตรวจสอบประวัติการเปลี่ยนแปลงสิทธิ์ โดยรองรับ
|
|
|
|
- ผู้ที่ทำรายการ
|
|
- ผู้ใช้ที่ถูกแก้ไขสิทธิ์
|
|
- รายการก่อนแก้ไข
|
|
- รายการหลังแก้ไข
|
|
- วันที่และเวลา
|
|
- ประเภท Action เช่น create, update, clone, deactivate, assign, override
|
|
- หมายเหตุหรือเหตุผลการแก้ไข
|
|
- ค้นหาและกรองข้อมูลได้
|
|
|
|
## Technical Audit Required
|
|
|
|
ก่อนสร้าง Plan.md ให้ตรวจสอบโครงสร้างเดิมของโปรเจกต์ก่อน โดยเฉพาะ
|
|
|
|
- โครงสร้าง route ใน `src/app`
|
|
- โครงสร้าง feature modules
|
|
- ระบบ auth ปัจจุบัน
|
|
- helper เดิม เช่น `isHRD()`, `businessRole`
|
|
- permission utility เดิม เช่น `requirePermission()`
|
|
- nav config เช่น `nav-config.ts`
|
|
- hook ที่เกี่ยวกับเมนู เช่น `use-nav.ts`
|
|
- schema/model ที่เกี่ยวข้องกับ user, role, permission
|
|
- API route handlers ที่เกี่ยวข้อง
|
|
- shared components เช่น DataTable, Dialog, Sheet, Form, Badge, Button
|
|
- audit log pattern ที่มีอยู่แล้ว ถ้ามี
|
|
|
|
ห้ามเดาโครงสร้างเอง ให้ตรวจสอบจากของจริงในโปรเจกต์ก่อนเสมอ
|
|
|
|
## Plan.md Must Include
|
|
|
|
ให้สร้างไฟล์ `Plan.md` โดยมีหัวข้ออย่างน้อยดังนี้
|
|
|
|
1. Objective
|
|
2. Current System Findings
|
|
3. Existing Files / Modules Related to Role & Permission
|
|
4. Proposed Permission Model
|
|
5. Proposed Pages
|
|
6. Proposed Database / Schema Changes
|
|
7. Proposed API Routes
|
|
8. Proposed UI Components
|
|
9. Access Control Rules
|
|
10. Audit Log Strategy
|
|
11. Migration Strategy from Role-based to Permission-first
|
|
12. Implementation Phases
|
|
13. Validation & Testing Checklist
|
|
14. Risks / Edge Cases
|
|
15. Files Expected to be Created or Modified
|
|
|
|
## Important Rules
|
|
|
|
- ห้ามแก้ไขโค้ดจริงในรอบนี้
|
|
- ห้ามสร้าง migration จริง
|
|
- ห้ามลบระบบ role เดิมทันที
|
|
- ต้องคำนึงถึง compatibility mode เดิม
|
|
- ต้องออกแบบให้ Super Admin เท่านั้นที่เข้าถึงหน้าจัดการ Permission ได้
|
|
- ต้องรองรับ Permission Template 1 รายการต่อผู้ใช้ 1 คน
|
|
- ต้องรองรับ Extra Permission / Override รายบุคคล
|
|
- ต้องใช้ Soft Delete สำหรับ Template
|
|
- ต้องมี Audit Log ทุกครั้งที่มีการเปลี่ยนแปลงสิทธิ์
|
|
- ต้องเขียน Plan.md ให้ละเอียดพอสำหรับใช้เป็นแผนก่อนลงมือ Coding Phase ถัดไป
|
|
|
|
## Expected Output
|
|
|
|
หลังตรวจสอบเสร็จ ให้สร้างไฟล์:
|
|
|
|
`docs/role-permission-management-plan.md`
|
|
|
|
โดยเป็นเอกสารแผนการพัฒนา ยังไม่ต้องแก้ไขโค้ดจริง
|