คู่มือทีละขั้น
Access Permission — เข้าใจสิ่งที่ระบบรองรับในปัจจุบัน
อ่านโมเดล Role Group และ View/Create/Edit/Delete พร้อมข้อจำกัดตรงไปตรงมาว่าหน้า Access Permission ปัจจุบันยังไม่มี editor matrix ที่ใช้งานสมบูรณ์
อ่านบทนี้แล้วทำอะไรได้
- อธิบายการทำงานของ Role Group และ permission ได้
- ตรวจสาเหตุ Access denied ได้ตามลำดับ
- ไม่พยายามแก้ permission ด้วย UI ที่ยังไม่พร้อม
เตรียมก่อนเริ่ม
- เข้าใจประเภทบัญชีและ Branch scope
- ทราบ Role Group ที่ผู้ใช้ถูกผูกอยู่
- มีสิทธิ์เข้าหน้า Access Permission หากต้องตรวจข้อมูล
สารบัญในหน้านี้
1. Role Group เป็นชุด Permission
ตอน Add/Invite ผู้ใช้ ระบบให้เลือก Role Group ที่เตรียมไว้และกรอง Personal role ออก เมื่อเข้าแต่ละ module ระบบโหลด permission ของ Role Group แล้วใช้ canView/canCreate/canEdit/canDelete ควบคุม UI และ API
2. ข้อจำกัดของหน้า Access Permission ตอนนี้
หากองค์กรต้องปรับ Role matrix ให้ใช้กระบวนการดูแลระบบที่ทีมพัฒนากำหนด ไม่แก้ฐานข้อมูลเอง และบันทึก Role/Module/Action ที่ต้องการให้ชัดเจนก่อนส่งคำขอ
3. ตรวจปัญหาสิทธิ์โดยไม่ใช้ editor
- ขั้นตอนที่ 1
ยืนยัน Branch
สลับไป Branch ที่ผู้ใช้ถูกเพิ่มไว้
- ขั้นตอนที่ 2
ยืนยัน Status และไม่ถูกลบ
เปิด Invite Account ตรวจบัญชี Active และยังอยู่ในบริษัท
- ขั้นตอนที่ 3
ยืนยัน Role Group
ตรวจ Role ที่ผูกกับผู้ใช้ว่าตรงกับงาน
- ขั้นตอนที่ 4
แยก View ออกจาก Action
ไม่เห็นหน้า = canView; เห็นหน้าแต่ไม่มีปุ่ม = ตรวจ Create/Edit/Delete
- ขั้นตอนที่ 5
ตรวจ Subscription
Formula/Multi-branch อาจถูกแพ็กเกจบล็อกแม้ Role ถูกต้อง
Continue learning
Next Steps — อ่านอะไรต่อ
เลือกบทถัดไปตามงานที่คุณกำลังตั้งค่า เพื่อเรียนต่อได้โดยไม่ข้ามขั้นสำคัญ