hamid
24 lines
1.4 KiB
Markdown
24 lines
1.4 KiB
Markdown
# Phase 02 — Reviews can never go live
|
|
|
|
**Blocker:** blockers.md § "Reviews."
|
|
**Depends on:** [01-admin-rbac.md](01-admin-rbac.md) — same root cause, no separate code fix.
|
|
|
|
---
|
|
|
|
**Root cause.** Same broken policy as phase 01, nothing else. `AdminReviewsController.cs:20` (the moderation
|
|
queue) and `ReviewsController.cs:33` (the `PATCH {reviewId}/status` publish action) are both gated by
|
|
`[Authorize(ConstantPolicies.DynamicPermission)]` → the same `CanAccess` check.
|
|
|
|
**The fix:** none needed beyond phase 01 — once `moderation`/`super_admin` pass `CanAccess`, both endpoints
|
|
become reachable immediately.
|
|
|
|
## Two secondary things worth doing in the same pass (not required to "unstick" reviews)
|
|
|
|
- `ReviewModerationStatus.Rejected` is currently unreachable end-to-end even after the RBAC fix — the
|
|
submit-time banned-word path maps to `Hidden`, not `Rejected` (`SubmitReviewCommand.Handler.cs:77`), and the
|
|
only other producer of `Rejected` is the admin PATCH. Once RBAC is fixed this stops being a dead state (an
|
|
admin really can reject a review), so no code change is actually required — just noting the client's
|
|
`rejected` chip (`review/page.tsx:48`) was previously unreachable and will start being exercised.
|
|
- **Flag, don't guess:** should `Seams:ReviewModeration:AutoApproveClean` be turned on so reviews aren't stuck
|
|
pending an admin action that may not happen promptly? That's a product call, not inferable from code.
|