Type — Supplement, Approval And Resolution

1. Resolver path: tiếp nhận và giải trình

Action complaintScheduleResolve chỉ hợp lệ khi complaint đang ở new_complaint.

Update semantics

Field	Hành vi
explanation	Ghi nội dung giải trình
solution	Ghi phương án xử lý
files	File đính kèm của phần giải trình
status	Đổi sang pending_inspection_complaint
session_updated_by	Ghi user thao tác

History insert

History status	Nội dung
receive_history_complaint	Snapshot giải trình + phương án xử lý + file

2. Approver path từ pending_inspection_complaint

Approver có 3 nhánh:

A. Approve

Thuộc tính	Giá trị
Preconditions	complaint đang pending_inspection_complaint
New status	approved_complaint
History status	approved_history_complaint
Content chính	Kết luận thanh tra

B. Reject

Thuộc tính	Giá trị
Preconditions	complaint đang pending_inspection_complaint
New status	rejected_complaint
History status	rejected_history_complaint
Content chính	Lý do

C. Request supplement

Thuộc tính	Giá trị
Preconditions	complaint đang pending_inspection_complaint
New status	pending_supplement_complaint
History status	request_supplement_history_complaint
Content chính	Lý do

3. Resolver path từ pending_supplement_complaint

complaintScheduleSupplement cho phép resolver trả lời yêu cầu bổ sung.

Thuộc tính	Giá trị
Preconditions	complaint đang pending_supplement_complaint
New status	pending_inspection_complaint
History status	process_supplement_history_complaint
Content chính	Nội dung bổ sung + Phương án bổ sung
Files	Có thể đính kèm

Điều này cho thấy supplement không phải terminal step; nó đưa complaint quay lại cùng approver queue như sau lần resolve đầu tiên.

4. Permission guard drift giữa các action

Đây là finding quan trọng nhất của complaint workflow hiện tại.

Logic hợp lý theo detail action role

Từ complaintScheduleDetail, một user nên được thao tác nếu:

1. là resolver/approver của branch phù hợp,
2. hoặc có full-permission role.

Nói cách khác, guard đúng phải tương đương:

allow if hasBranchPermission OR isFullPermission

Logic hiện thấy trong nhiều mutate actions

Ở resolve, requestSupplement, supplement, reject, code đang có dạng:

deny if len(branchPermission) == 0 OR !isFullPermission

Tương đương business effect:

allow only if hasBranchPermission AND isFullPermission

Hệ quả:

• user đã được gán resolver/approver theo branch nhưng không thuộc full-permission role có thể bị chặn,
• UI detail vẫn có thể hiện nút vì complaintScheduleDetail dùng semantics khác,
• bug sẽ xuất hiện dưới dạng "thấy nút nhưng submit bị permission denied".

File có dấu hiệu lỗi

Action	Dấu hiệu guard
complaintScheduleResolve	Dùng `len(resolvers)==0
complaintScheduleRequestSupplement	Dùng `len(approvers)==0
complaintScheduleSupplement	Dùng `len(resolvers)==0
complaintScheduleReject	Dùng `len(approvers)==0

File khác semantics

Action	Dấu hiệu guard
complaintScheduleApprove	Dùng len(approvers)==0 && !isFullPermission

approve vì vậy đang cho phép:

• approver branch bình thường,
• hoặc full-permission role,

trong khi các action sibling lại yêu cầu chặt hơn. Đây là inconsistency rõ ràng.

5. QA matrix nên test theo guard thật

Case	Kỳ vọng nghiệp vụ	Risk hiện tại
Resolver có branch permission nhưng không có full-permission role	Resolve được complaint mới	Có thể fail
Approver có branch permission nhưng không có full-permission role	Request supplement / reject được	Có thể fail
Full-permission role không có branch permission	Tùy semantics mong muốn	Code hiện tại không đồng nhất giữa actions
bod thấy complaint ở detail	Có thể view	Chưa đủ bằng chứng là mutate được tương ứng

6. Rủi ro / Findings

ID	Finding
SAR-F01	Guard ở resolve/requestSupplement/supplement/reject có dấu hiệu bug logic thật, không chỉ naming mơ hồ.
SAR-F02	approve dùng semantics khác các action sibling, nên complaint mutate paths hiện không nhất quán.
SAR-F03	QA nếu chỉ test happy path bằng tài khoản admin/full-role sẽ bỏ sót lỗi permission theo branch.