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

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 จริง

อนุญาตเฉพาะการอ่าน วิเคราะห์ ค้นหา และจัดทำรายงาน

---

รูปแบบรายงานที่ต้องส่งมอบ

สร้างไฟล์

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