Feat/ic 053 maker checker decisions - #250
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 640a814b94
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| path( | ||
| "manual-reviews/<str:verification_id>/approval", | ||
| ManualReviewApprovalView.as_view(), | ||
| name="manual-review-approval", | ||
| ), |
There was a problem hiding this comment.
Wire the approval endpoint into the reviewer UI
For high/critical cases submitted through the dashboard, dashboardApi.decideReview still calls only the /decision endpoint, and LiveVerificationDetail treats the resulting 202 response as a completed decision while continuing to render the same maker actions. A repo-wide search finds no frontend client for this new /approval route, so a second reviewer cannot complete these cases through the product UI and they remain in manual review indefinitely.
Useful? React with 👍 / 👎.
| "assigned_reviewer_id": ( | ||
| verification.assigned_reviewer.public_id | ||
| if verification.assigned_reviewer_id | ||
| else None |
There was a problem hiding this comment.
Eager-load assigned reviewers for verification lists
When a verification-list page contains assigned cases, this new dereference loads assigned_reviewer separately for every such row because VerificationListCreateView only selects verification_subject. With the supported page size of 100, the endpoint can now issue 100 additional queries; include assigned_reviewer in the list queryset's select_related call.
Useful? React with 👍 / 👎.
| decision = serializers.ChoiceField( | ||
| choices=[ | ||
| (VerificationStatus.VERIFIED, "Verified"), | ||
| (VerificationStatus.REJECTED, "Rejected"), | ||
| ] |
There was a problem hiding this comment.
Accept every outcome that can enter approval
For a high-risk or policy-selected case, the maker serializer accepts failed and manual_review_required and stores either as a pending proposal, but this approval serializer accepts only verified or rejected. The existing decision record prevents another proposal through /decision, so a checker cannot approve the requested failure or escalation without replacing it with a different outcome; align the proposal and approval choices or model escalation/rejection as separate approval actions.
Useful? React with 👍 / 👎.
No description provided.