commit

plans/system-ui-permission-review-plan.md

@@ -0,0 +1,529 @@
+# Prompt: ตรวจสอบการแสดงผลของระบบเทียบกับ Permission โดยยังไม่แก้ไขโค้ด
+
+## เป้าหมาย
+
+ให้ตรวจสอบระบบทั้งหมดว่า การแสดงผลของหน้า เมนู ปุ่ม ข้อมูล ฟิลด์ และ Action ต่าง ๆ สอดคล้องกับ Permission และ Role ที่ระบบกำหนดไว้จริงหรือไม่
+
+งานนี้เป็น **Audit / Review เท่านั้น**
+ห้ามแก้ไขโค้ด ห้ามเปลี่ยน Permission และห้ามปรับพฤติกรรมของระบบในขั้นตอนนี้
+
+ผลลัพธ์ที่ต้องการคือรายงานปัญหา พร้อมหลักฐาน ตำแหน่งโค้ด ผลกระทบ และแนวทางแก้ไขสำหรับนำไปดำเนินการในขั้นตอนถัดไป
+
+---
+
+## ขอบเขตการตรวจสอบ
+
+ตรวจสอบทั้งระบบ ครอบคลุมอย่างน้อยดังนี้
+
+- Sidebar และ Navigation
+- Dashboard
+- หน้ารายการ
+- หน้ารายละเอียด
+- หน้าสร้างข้อมูล
+- หน้าแก้ไขข้อมูล
+- Dialog, Modal, Drawer, Sheet และ Dropdown Menu
+- ปุ่ม Action ในตาราง
+- ปุ่มสร้าง แก้ไข ลบ ส่งตรวจสอบ อนุมัติ ปฏิเสธ ส่งกลับ และเผยแพร่
+- ข้อมูลภายใน Card, Table, Form และ Detail Section
+- หมายเหตุการตรวจสอบ
+- ประวัติการอนุมัติ
+- Audit Log
+- API Route
+- Server Action
+- Query และ Service Layer
+- Middleware
+- Route Guard
+- Permission Helper
+- Role Guard
+- Component Guard
+- Backend Authorization
+
+ให้ตรวจสอบทุกโมดูลที่มีอยู่ในระบบ เช่น
+
+- ผู้ใช้งานและพนักงาน
+- ประวัติการอบรม
+- บทเรียนออนไลน์
+- ประกาศ
+- การแจ้งเตือน
+- นโยบาย
+- การอนุมัติ
+- รายงาน
+- ตั้งค่าระบบ
+- Audit Log
+- โมดูลอื่น ๆ ที่ค้นพบในโครงการ
+
+---
+
+## Role และ Permission
+
+ให้ค้นหา Role และ Permission จากโค้ดจริงก่อนเริ่มตรวจสอบ เช่น
+
+- User / Employee
+- Admin
+- HRD Staff
+- HRD Manager
+- IT Admin
+- Reviewer
+- Approver
+- Role อื่น ๆ ที่ระบบมีอยู่จริง
+
+ห้ามสมมติชื่อ Role หรือ Permission จากเอกสารเพียงอย่างเดียว
+
+ให้ค้นหาแหล่งกำหนด Permission ทั้งหมด เช่น
+
+- Enum
+- Constant
+- Permission Matrix
+- Database Schema
+- Seed Data
+- Middleware
+- Session
+- JWT
+- Auth.js callback
+- Route configuration
+- Sidebar configuration
+- Helper function เช่น `hasPermission`, `canAccess`, `canManage`
+- Server-side authorization
+- Client-side conditional rendering
+
+จากนั้นจัดทำ Permission Matrix ที่อ้างอิงจากโค้ดจริงก่อนตรวจสอบหน้าจอ
+
+---
+
+## หลักการตรวจสอบ
+
+การตรวจสอบต้องครอบคลุมทั้งสองระดับ
+
+### 1. การแสดงผลฝั่ง Client
+
+ตรวจสอบว่า Role หรือ Permission แต่ละประเภทเห็นเฉพาะสิ่งที่ควรเห็นหรือไม่ เช่น
+
+- เมนูที่ไม่มีสิทธิ์ถูกซ่อนหรือไม่
+- ปุ่มที่ไม่มีสิทธิ์ถูกซ่อนหรือ Disable อย่างถูกต้องหรือไม่
+- ข้อมูลภายในหน้ารายละเอียดถูกกรองตามสิทธิ์หรือไม่
+- ฟิลด์ภายใน Form แสดงตาม Role หรือ Status หรือไม่
+- Action Menu แสดงเฉพาะ Action ที่ทำได้จริงหรือไม่
+- ข้อความ หมายเหตุ และประวัติภายในระบบเปิดเผยเกินสิทธิ์หรือไม่
+
+### 2. การบังคับสิทธิ์ฝั่ง Server
+
+ห้ามสรุปว่าระบบปลอดภัยเพียงเพราะซ่อนปุ่มหรือซ่อนเมนูแล้ว
+
+ต้องตรวจสอบด้วยว่า ผู้ไม่มีสิทธิ์สามารถเรียกใช้งานผ่าน URL, API, Server Action หรือ Request โดยตรงได้หรือไม่ เช่น
+
+- เปิด URL โดยตรง
+- เรียก API โดยตรง
+- ส่ง Request จาก DevTools
+- แก้ไข Parameter
+- เปลี่ยน Record ID
+- เรียก Server Action โดยไม่ผ่าน UI
+- เข้าถึงข้อมูลของผู้ใช้งานรายอื่น
+- แก้ไขข้อมูลของผู้ใช้งานรายอื่น
+- เรียก Action ที่ UI ซ่อนไว้
+
+---
+
+## ประเด็นสำคัญที่ต้องตรวจสอบ
+
+### A. เมนูและเส้นทาง
+
+ตรวจสอบว่า
+
+- Sidebar แสดงเมนูตาม Permission
+- ผู้ไม่มีสิทธิ์ไม่สามารถเข้าหน้าผ่าน URL โดยตรง
+- Route Guard และ Middleware ใช้เงื่อนไขเดียวกับ Sidebar
+- ไม่มีหน้าที่ซ่อนเมนูแต่ยังเข้าผ่าน URL ได้
+- ไม่มีหน้าที่ Sidebar แสดงให้เห็น แต่เข้าใช้งานจริงไม่ได้
+- Redirect และ Forbidden Page ทำงานสม่ำเสมอ
+
+### B. ปุ่มและ Action
+
+ตรวจสอบทุก Action เช่น
+
+- สร้าง
+- บันทึกฉบับร่าง
+- แก้ไข
+- ลบ
+- ส่งตรวจสอบ
+- อนุมัติ
+- ปฏิเสธ
+- ส่งกลับแก้ไข
+- เผยแพร่
+- ยกเลิกเผยแพร่
+- ปักหมุด
+- นำเข้า
+- ส่งออก
+- ดาวน์โหลด
+- จัดการ Permission
+
+ตรวจสอบว่า
+
+- ปุ่มแสดงเฉพาะ Role ที่มีสิทธิ์
+- Action สอดคล้องกับสถานะข้อมูล
+- Backend ตรวจ Permission ซ้ำ
+- ไม่สามารถข้าม Workflow ได้
+- ไม่มี Action ที่ UI แสดงแต่ Backend ปฏิเสธโดยไม่ตั้งใจ
+- ไม่มี Action ที่ UI ซ่อน แต่ Backend ยังอนุญาต
+
+### C. การแสดงข้อมูลละเอียดอ่อน
+
+ตรวจสอบข้อมูลที่อาจไม่ควรแสดงแก่ผู้ใช้งานทั่วไป เช่น
+
+- หมายเหตุการตรวจสอบ
+- เหตุผลการปฏิเสธ
+- Internal Comment
+- Reviewer Note
+- Approval Note
+- Audit Log
+- ชื่อผู้อนุมัติ
+- ประวัติการแก้ไข
+- Metadata ภายใน
+- Permission หรือ Role ภายใน
+- ข้อมูลพนักงานรายอื่น
+- ข้อมูลสถานะภายใน Workflow
+
+ให้ตรวจสอบเป็นพิเศษว่า หน้าผู้ใช้งานทั่วไปมีการแสดง “หมายเหตุการตรวจสอบ” หรือข้อมูลภายในของเจ้าหน้าที่โดยไม่ตั้งใจหรือไม่
+
+### D. Ownership และขอบเขตข้อมูล
+
+ตรวจสอบว่า
+
+- ผู้ใช้งานทั่วไปเห็นเฉพาะข้อมูลของตนเอง
+- เจ้าหน้าที่เห็นข้อมูลตามบริษัท ฝ่าย หรือขอบเขตที่กำหนด
+- Reviewer และ Approver เห็นเฉพาะรายการที่เกี่ยวข้อง
+- Admin เห็นข้อมูลทั้งหมดตามที่ออกแบบ
+- การเปลี่ยน ID ใน URL หรือ Request ไม่ทำให้เข้าถึงข้อมูลของผู้อื่น
+- Query มีเงื่อนไขกรองตาม Ownership และ Permission
+- การ Export ไม่ส่งออกข้อมูลเกินสิทธิ์
+- Search และ Filter ไม่สามารถใช้ดึงข้อมูลนอกขอบเขต
+
+### E. Workflow และ Status
+
+ตรวจสอบ Permission ร่วมกับสถานะ เช่น
+
+- Draft
+- Pending
+- Submitted
+- Approved
+- Rejected
+- Returned
+- Published
+- Archived
+- Cancelled
+- สถานะอื่นที่มีอยู่จริง
+
+ตัวอย่างการตรวจสอบ
+
+- เจ้าของรายการแก้ไขได้เฉพาะ Draft หรือ Returned หรือไม่
+- เมื่อส่งตรวจสอบแล้ว ผู้ใช้งานยังแก้ไขได้หรือไม่
+- ผู้ใช้งานเห็นรายการ Rejected หรือ Returned ตามที่กำหนดหรือไม่
+- Reviewer เห็นรายการที่ต้องตรวจสอบจริงหรือไม่
+- Approver สามารถอนุมัติรายการที่ยังไม่ถึงขั้นตนเองหรือไม่
+- รายการ Published แสดงแก่ผู้ใช้งานตามเงื่อนไขหรือไม่
+- การแสดงปุ่มสอดคล้องกับ Permission และ Status พร้อมกันหรือไม่
+
+---
+
+## วิธีดำเนินการ
+
+### ขั้นตอนที่ 1: สำรวจโครงสร้าง Permission
+
+ค้นหาและสรุป
+
+- Role ทั้งหมด
+- Permission ทั้งหมด
+- Mapping ระหว่าง Role และ Permission
+- Permission Helper ทั้งหมด
+- Route Guard
+- API Guard
+- Server Action Guard
+- Ownership Rule
+- Status Rule
+
+### ขั้นตอนที่ 2: จัดทำ Permission Matrix
+
+จัดทำตารางในรูปแบบประมาณนี้
+
+| Module         | Page / Action        |       User | Staff | Manager |   Admin | เงื่อนไขเพิ่มเติม       |
+| -------------- | -------------------- | ---------: | ----: | ------: | ------: | ----------------------- |
+| Online Lessons | ดูรายการเผยแพร่      |        Yes |   Yes |     Yes |     Yes | เฉพาะ Published         |
+| Online Lessons | ดูหมายเหตุการตรวจสอบ |         No |   Yes |     Yes |     Yes | ผู้ใช้งานทั่วไปห้ามเห็น |
+| Online Lessons | แก้ไข Draft          | Owner only |   Yes |     Yes |     Yes | ตาม Ownership           |
+| Online Lessons | อนุมัติ              |         No |    No |     Yes | ตามระบบ | Pending เท่านั้น        |
+
+ให้ใช้ Role จริงจากระบบแทนตัวอย่างข้างต้น
+
+### ขั้นตอนที่ 3: ตรวจสอบ UI กับ Matrix
+
+ตรวจสอบทุกหน้าและ Component ว่า
+
+- Render Condition ถูกต้องหรือไม่
+- ใช้ Permission Helper มาตรฐานหรือไม่
+- มีการ Hardcode Role หรือไม่
+- มี Logic ซ้ำซ้อนหรือขัดแย้งกันหรือไม่
+- มีการตรวจเฉพาะ Role แต่ไม่ตรวจ Permission หรือไม่
+- มีการตรวจเฉพาะ Status แต่ไม่ตรวจ Role หรือไม่
+- มีการซ่อนด้วย CSS โดยไม่ได้หยุดการ Render หรือไม่
+
+### ขั้นตอนที่ 4: ตรวจสอบ Backend กับ Matrix
+
+ตรวจสอบ
+
+- API Route
+- Route Handler
+- Server Action
+- Service Function
+- Repository
+- Database Query
+
+ให้ยืนยันว่าแต่ละ Action ตรวจสอบครบทั้ง
+
+1. Authentication
+2. Role หรือ Permission
+3. Ownership หรือ Data Scope
+4. Record Status
+5. Input Validation
+
+### ขั้นตอนที่ 5: ตรวจหาความไม่สอดคล้อง
+
+จัดประเภทปัญหาอย่างน้อยดังนี้
+
+- UI แสดงเกินสิทธิ์
+- UI ซ่อนผิด แม้มีสิทธิ์
+- เข้าผ่าน URL โดยตรงได้
+- API ไม่มี Authorization
+- Server Action ไม่มี Authorization
+- Data Query ไม่กรอง Ownership
+- Export ข้อมูลเกินสิทธิ์
+- Role และ Permission Logic ไม่ตรงกัน
+- Permission Logic กระจายหลายจุด
+- Hardcoded Role
+- Status Guard ไม่ครบ
+- ข้อมูลภายในรั่วไปยังผู้ใช้งานทั่วไป
+- Client และ Server ใช้เงื่อนไขต่างกัน
+- Permission Matrix ไม่ตรงกับการทำงานจริง
+
+---
+
+## สิ่งที่ห้ามทำ
+
+- ห้ามแก้ไขไฟล์ใด ๆ
+- ห้าม Refactor
+- ห้ามเปลี่ยน Permission
+- ห้ามเปลี่ยน Role
+- ห้ามแก้ Middleware
+- ห้ามแก้ Component
+- ห้ามแก้ API
+- ห้ามแก้ Server Action
+- ห้ามแก้ Database Schema
+- ห้ามสร้าง Migration
+- ห้ามรันคำสั่งที่แก้ไขข้อมูล
+- ห้ามลบหรือเพิ่ม Dependency
+- ห้าม Commit
+- ห้าม Push
+- ห้ามสรุปจากชื่อไฟล์โดยไม่ได้อ่าน Logic จริง
+
+อนุญาตเฉพาะการอ่าน วิเคราะห์ ค้นหา และจัดทำรายงาน
+
+---
+
+## รูปแบบรายงานที่ต้องส่งมอบ
+
+สร้างไฟล์
+
+```text
+permission-display-audit.md
+```
+
+โดยมีโครงสร้างดังนี้
+
+# Permission and Display Audit Report
+
+## 1. Executive Summary
+
+สรุปภาพรวมว่า
+
+- ระบบสอดคล้องกับ Permission มากน้อยเพียงใด
+- พบ Critical, High, Medium และ Low กี่รายการ
+- โมดูลใดมีความเสี่ยงสูง
+- มีข้อมูลใดถูกแสดงเกินสิทธิ์หรือไม่
+- Backend บังคับ Permission ครบถ้วนหรือไม่
+
+## 2. Roles and Permissions Discovered
+
+ระบุ
+
+- Role ที่พบ
+- Permission ที่พบ
+- แหล่งที่กำหนด
+- File path
+- Logic โดยย่อ
+
+## 3. Permission Matrix
+
+ตารางสิทธิ์ของทุกโมดูล ทุกหน้า และทุก Action
+
+## 4. Route and Navigation Audit
+
+ตาราง
+
+| ID  | Route | Menu Permission | Route Guard | Direct URL Result | Status |
+| --- | ----- | --------------- | ----------- | ----------------- | ------ |
+
+## 5. UI Display Audit
+
+ตาราง
+
+| ID  | Module | Page / Component | Element | Expected | Actual | Severity | Evidence |
+| --- | ------ | ---------------- | ------- | -------- | ------ | -------- | -------- |
+
+## 6. Backend Authorization Audit
+
+ตาราง
+
+| ID  | Endpoint / Action | Authentication | Permission | Ownership | Status Guard | Result |
+| --- | ----------------- | -------------- | ---------- | --------- | ------------ | ------ |
+
+## 7. Findings
+
+สำหรับแต่ละปัญหา ให้ใช้รูปแบบ
+
+### PERM-001: ชื่อปัญหา
+
+- Severity:
+- Module:
+- Affected roles:
+- Expected behavior:
+- Actual behavior:
+- Security or business impact:
+- Root cause:
+- Evidence:
+- File path:
+- Line or code reference:
+- Reproduction steps:
+- Recommended remediation:
+- Related findings:
+
+## 8. Role-based Test Scenarios
+
+จัดทำกรณีทดสอบสำหรับแต่ละ Role เช่น
+
+| Test ID | Role | Page | Action | Expected Result |
+| ------- | ---- | ---- | ------ | --------------- |
+
+ต้องครอบคลุมอย่างน้อย
+
+- เปิดเมนู
+- เปิด URL โดยตรง
+- ดูรายการ
+- ดูรายละเอียด
+- สร้าง
+- แก้ไข
+- ลบ
+- ส่งตรวจสอบ
+- อนุมัติ
+- ปฏิเสธ
+- ส่งกลับ
+- Export
+- เข้าถึงข้อมูลของผู้อื่น
+- เปลี่ยน Record ID
+- เรียก API โดยตรง
+
+## 9. Prioritized Remediation Plan
+
+จัดลำดับแนวทางแก้ไข โดยยังไม่แก้โค้ด
+
+### Priority 0 — Critical Security
+
+ปัญหาที่ทำให้ผู้ไม่มีสิทธิ์เข้าถึงหรือแก้ไขข้อมูลได้
+
+### Priority 1 — Permission Mismatch
+
+UI และ Backend ใช้เงื่อนไขไม่ตรงกัน
+
+### Priority 2 — Data Exposure
+
+ข้อมูลภายในหรือหมายเหตุแสดงเกินสิทธิ์
+
+### Priority 3 — Maintainability
+
+Permission Logic ซ้ำซ้อน กระจาย หรือ Hardcode
+
+## 10. Files Reviewed
+
+ระบุไฟล์ทั้งหมดที่ตรวจสอบ พร้อมเหตุผลที่เกี่ยวข้อง
+
+## 11. Files Not Reviewed or Limitations
+
+ระบุส่วนที่ไม่สามารถตรวจสอบได้ พร้อมเหตุผลอย่างตรงไปตรงมา
+
+## 12. Final Assessment
+
+สรุปว่า
+
+- ระบบพร้อมใช้งานในด้าน Permission หรือไม่
+- ประเด็นใดต้องแก้ก่อน Production
+- ประเด็นใดสามารถวางแผนแก้ภายหลัง
+- ความเสี่ยงที่ยังเหลืออยู่
+
+---
+
+## ระดับความรุนแรง
+
+### Critical
+
+- ผู้ไม่มีสิทธิ์เข้าถึงหรือแก้ไขข้อมูลสำคัญได้
+- API หรือ Server Action ไม่มี Authorization
+- เปลี่ยน Record ID แล้วเข้าถึงข้อมูลของผู้อื่นได้
+- สามารถข้าม Workflow หรืออนุมัติแทน Role อื่นได้
+
+### High
+
+- UI หรือ Route แสดงข้อมูลละเอียดอ่อนเกินสิทธิ์
+- Permission ระหว่าง Client และ Server ไม่ตรงกัน
+- Ownership Rule ไม่ครบ
+- Export ข้อมูลเกินขอบเขต
+
+### Medium
+
+- ปุ่มแสดงหรือซ่อนผิด
+- Status และ Permission ไม่สัมพันธ์กัน
+- ผู้มีสิทธิ์ใช้งานไม่ได้ตามปกติ
+- Logic ซ้ำซ้อนและเสี่ยงเกิดความไม่สอดคล้อง
+
+### Low
+
+- ข้อความไม่เหมาะสมกับ Role
+- UI สื่อความหมาย Permission ไม่ชัด
+- Code Quality หรือ Maintainability ที่ยังไม่ทำให้สิทธิ์ผิดทันที
+
+---
+
+## เกณฑ์การตรวจสอบเพิ่มเติม
+
+- อ้างอิงจากโค้ดจริง ไม่อ้างอิงเฉพาะ Requirement
+- ทุก Finding ต้องมี File path หรือหลักฐาน
+- แยก Expected กับ Actual ให้ชัดเจน
+- ห้ามรายงานเป็นข้อสันนิษฐานโดยไม่มีหลักฐาน
+- เมื่อไม่แน่ใจให้ระบุว่า “ต้องยืนยันเพิ่มเติม”
+- ตรวจสอบทั้ง Client และ Server เสมอ
+- ให้ความสำคัญกับ Security มากกว่าการซ่อน UI
+- ห้ามใช้คำว่า “ผ่าน” หากตรวจเพียงฝั่งหน้าเว็บ
+- ตรวจสอบว่าการใช้ `role`, `permission`, `status` และ `ownership` เป็นมาตรฐานเดียวกันทั้งระบบหรือไม่
+
+---
+
+## คำสั่งสุดท้าย
+
+เริ่มจากสำรวจโครงสร้างโปรเจกต์และ Permission ทั้งหมดก่อน จากนั้นตรวจสอบการแสดงผลและการเข้าถึงของระบบทุกโมดูล
+
+งานนี้ให้ดำเนินการเฉพาะการตรวจสอบและจัดทำรายงานเท่านั้น ห้ามแก้ไขโค้ดทุกกรณี
+
+เมื่อเสร็จแล้วให้สรุปในข้อความตอบกลับว่า
+
+1. พบปัญหาทั้งหมดกี่รายการ แยกตาม Severity
+2. โมดูลใดมีความเสี่ยงสูงที่สุด
+3. มีกรณีข้อมูลแสดงเกินสิทธิ์หรือไม่
+4. มี API หรือ Server Action ที่ไม่มี Authorization หรือไม่
+5. สร้างไฟล์รายงานไว้ที่ตำแหน่งใด
+6. ยืนยันว่าไม่มีการแก้ไขโค้ดหรือข้อมูลในระบบ