alla-tms/plans/permission-validation-fix.md

Prompt: Permission Template Type Validation Audit & Fix

Objective

ดำเนินการตรวจสอบ วิเคราะห์ และแก้ไขปัญหาในฟอร์มที่เกี่ยวข้องกับ Permission Template ซึ่งปัจจุบันพบ Validation Error ดังนี้

Invalid input: expected number, received string

เป้าหมายคือให้ระบบสามารถเลือก Permission Template ได้อย่างถูกต้อง โดยไม่มี Type Mismatch ระหว่าง Frontend, Validation Schema และ Backend พร้อมทั้งสร้างเอกสารสรุปผลการดำเนินงานไว้ในโฟลเดอร์ docs/

---

Background

ระบบกำลังพัฒนาโดยใช้แนวคิด Permission Template First Architecture

Permission Template เป็นตัวกำหนดสิทธิ์หลักของผู้ใช้งาน

เมื่อผู้ใช้เลือก Permission Template จาก Dropdown ไม่ควรเกิด Validation Error และข้อมูลต้องสามารถบันทึกได้ทั้ง Create และ Edit

---

Scope

ตรวจสอบทุกส่วนที่เกี่ยวข้องกับ Permission Template ได้แก่

• Form Component
• Select Component
• TanStack Form
• React Hook Form (ถ้ามี)
• Zod Schema
• DTO
• API Request
• API Route
• Service Layer
• Repository
• Prisma
• Database Mapping
• TypeScript Types
• Default Values
• Edit Form
• Create Form

รวมถึงไฟล์ Shared ที่เกี่ยวข้อง

---

Phase 1 — Architecture Audit

ก่อนแก้ไข ต้องตรวจสอบระบบทั้งหมดก่อน

ตรวจสอบ

Frontend

• Permission Template Select
• Form State
• Default Values
• Initial Values
• Edit Values
• Submit Handler

Validation

ตรวจสอบ

• zod schema
• validator
• preprocess
• transform

Backend

ตรวจสอบ

• Route Handler
• Server Action
• Service
• Repository
• Prisma

Database

ตรวจสอบว่า

Permission Template ใช้

INT

หรือ

UUID

หรือ

String

ห้ามเดา

ต้องอ้างอิงจากโค้ดจริง

---

Phase 2 — Root Cause Analysis

ค้นหาสาเหตุที่แท้จริง

เช่น

Case A

Select ส่ง

"1";

แต่ schema

z.number();

---

Case B

Select ส่ง

"employee";

แต่ database ต้องการ

1;

---

Case C

Default Value

permissionTemplateId: "";

แต่ schema

z.number();

---

Case D

Edit Form

โหลดข้อมูลมาเป็น

number;

แต่ Select ต้องการ

string;

---

Case E

API รับ

string;

แต่ backend schema

number;

---

ต้องระบุให้ชัดเจนว่า

Root Cause ที่แท้จริงคืออะไร

พร้อมอธิบายเหตุผล

---

Phase 3 — Fix Frontend

ตรวจสอบ Select

ตัวอย่าง

<Select
    value={...}
    onValueChange={...}
>

ต้องตรวจสอบว่า

value

และ

onValueChange

มี Type ที่ถูกต้อง

หาก Database ใช้ numeric id

ให้แปลงค่าอย่างเหมาะสม

เช่น

value={
    field.state.value != null
        ? String(field.state.value)
        : undefined
}

และ

onValueChange={(value) => {
    if (!value) {
        field.handleChange(undefined)
        return
    }

    field.handleChange(Number(value))
}}

ห้ามใช้

Number("");

จนกลายเป็น

0

โดยไม่ได้ตั้งใจ

---

Phase 4 — Fix Default Values

ตรวจสอบ

Default Values

ทุกจุด

เช่น

ผิด

permissionTemplateId: "";

หรือ

permissionTemplateId: "1";

ให้ปรับให้สอดคล้องกับ schema

เช่น

undefined;

หรือ

null;

หรือ

number;

ตามมาตรฐานของระบบ

---

Phase 5 — Fix Validation

ตรวจสอบ Zod Schema

หากต้องการ Number

ให้รองรับค่าจาก Select อย่างถูกต้อง

ตัวอย่าง

z.preprocess(...)

หรือ

ให้ Form State เป็น Number ตั้งแต่ต้น

เลือกวิธีที่สอดคล้องกับ Architecture ของโปรเจกต์

ห้ามเพิ่ม Logic ซ้ำซ้อน

---

Phase 6 — Fix API

ตรวจสอบ Request Payload

ก่อนส่ง API

ต้องเป็น

number;

ไม่ใช่

string;

ตรวจสอบ

• mutation
• fetch
• api client

ทุกจุด

---

Phase 7 — Fix Backend

ตรวจสอบ

• Route Handler
• Service
• DTO
• Validation

ต้องรับ Type ตรงกับ Frontend

ห้ามเกิด

string -> number

Mismatch

---

Phase 8 — UX Improvement

ปัจจุบัน

ผู้ใช้เห็น

Invalid input: expected number, received string

ซึ่งเป็น Technical Error

ให้ปรับเป็นข้อความที่ผู้ใช้เข้าใจได้

เช่น

กรุณาเลือก Permission Template

หรือ

กรุณาเลือกเทมเพลตสิทธิ์การใช้งาน

โดยยังคงเก็บ Technical Error ไว้สำหรับ Developer

---

Phase 9 — Regression Testing

ตรวจสอบ

Create

• เปิดหน้า
• ไม่มี Error
• เลือก Permission Template
• Submit ได้

---

Edit

• โหลดค่าเดิมได้
• แสดงค่าใน Select ถูกต้อง
• เปลี่ยนค่าได้
• Save ได้

---

Validation

• ไม่เลือก Template
• แสดงข้อความภาษาไทย

---

API

ตรวจสอบ Payload

ต้องเป็น

permissionTemplateId: number;

---

Database

ตรวจสอบข้อมูลที่บันทึก

ต้องตรงกับ Template ที่เลือก

---

TypeScript

ต้องไม่มี

• type error
• eslint error
• any ใหม่

---

Code Quality

หลังแก้ไขแล้ว

ตรวจสอบ

• ไม่มี duplicated logic
• ไม่มี dead code
• ไม่มี unused imports
• ไม่มี console.log
• ไม่มี TODO ค้าง
• ไม่มี workaround ชั่วคราว
• ใช้ Shared Component เดิม
• ใช้ Shared Utility เดิม
• ไม่สร้าง Helper ใหม่โดยไม่จำเป็น

---

Deliverables

1. แก้ไข Source Code

แก้ไขเฉพาะส่วนที่จำเป็น

ห้าม Refactor ส่วนอื่น

---

2. สร้างรายงาน

สร้างไฟล์

docs/permission-template-validation-fix-report.md

---

รายงานต้องประกอบด้วย

Permission Template Validation Fix Report

Executive Summary

สรุปปัญหา

---

Root Cause Analysis

อธิบายสาเหตุที่แท้จริง

---

Architecture Review

อธิบาย Flow

Frontend

↓

Validation

↓

API

↓

Backend

↓

Database

---

Files Modified

ระบุทุกไฟล์

พร้อมเหตุผลที่แก้ไข

---

Implementation Details

อธิบาย

• Form
• Select
• Schema
• API
• Backend

ที่ถูกแก้ไข

---

Before

อธิบายพฤติกรรมเดิม

---

After

อธิบายพฤติกรรมใหม่

---

Validation Result

ผลการทดสอบ

• Create
• Edit
• Validation
• API
• Database

---

Regression Check

รายการที่ตรวจสอบแล้ว

---

Risks

ผลกระทบที่อาจเกิดขึ้น

---

Recommendation

ข้อเสนอแนะเพิ่มเติม

---

Constraints

ต้องปฏิบัติตามข้อกำหนดดังต่อไปนี้

• ห้ามแก้ Database Schema โดยไม่จำเป็น
• ห้าม Hardcode Permission Template ID
• ห้ามเปลี่ยน Business Logic
• ห้ามเปลี่ยน Permission Logic
• ห้ามเปลี่ยน API Contract หากไม่จำเป็น
• ห้ามใช้ any
• ห้ามเพิ่ม Library ใหม่
• ต้องรักษา Type Safety
• ต้องใช้ Shared Component ของระบบ
• ต้องทำตาม Coding Standard ของโปรเจกต์
• ต้องรักษา Backward Compatibility หากมี

---

Final Response

เมื่อดำเนินการเสร็จ ให้สรุปผลเป็นภาษาไทย โดยประกอบด้วย

1. Root Cause ที่พบ
2. แนวทางการแก้ไข
3. รายชื่อไฟล์ที่แก้ไข
4. ผลการทดสอบ
5. ความเสี่ยงที่เหลือ (ถ้ามี)
6. Path ของรายงานที่สร้างใน docs/permission-template-validation-fix-report.md
7. ข้อเสนอแนะเพิ่มเติม (ถ้ามี)