# 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. ยืนยันว่าไม่มีการแก้ไขโค้ดหรือข้อมูลในระบบ