Conversation
* feat(tasks): add framework instances support to task filtering * feat(tasks): define FrameworkInstanceForTasks type for task components and added a handler for non-existent frameworks * feat(tasks): add validation for frameworkFilter in TaskList component --------- Co-authored-by: Lewis Carhart <lewis@trycomp.ai>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryHigh Risk Overview Extends the API with endpoints to Updates the app UI to support approval: selecting an approver, preventing direct “done” transitions when approval is enabled (routing to submit-for-review instead), showing in-review banners/actions, adding an Activity tab/timeline backed by a new SWR hook, and enhancing task lists with Written by Cursor Bugbot for commit 218b7b9. This will update automatically on new commits. Configure here. |
|
|
#2111) * feat(context): resolve framework IDs to human-readable names in context entries * refactor(auditor): exclude framework selection and auditor sections from context --------- Co-authored-by: Lewis Carhart <lewis@trycomp.ai>
* feat(context): resolve framework IDs to human-readable names in context entries * refactor(auditor): exclude framework selection and auditor sections from context * feat(people): enhance JoinDate component with date parsing and dropdown * refactor(people): simplify JoinDate component by removing date parsing logic * refactor(people): update label in JoinDate component to 'Join Date' * fix(people): add button type to Done button in JoinDate component --------- Co-authored-by: Lewis Carhart <lewis@trycomp.ai>
* feat(tasks): add email templates and notification logic for evidence review requests * fix(tasks): adjust layout of TabsContent in SingleTask component --------- Co-authored-by: Tofik Hasanov <annexcies@gmail.com>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 4 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| } | ||
|
|
||
| const updatedCount = response.data?.updatedCount ?? selectedTaskIds.length; | ||
| toast.success(`${updatedCount} task${updatedCount === 1 ? '' : 's'} submitted for review`); |
There was a problem hiding this comment.
Response field name mismatch breaks task count display
Medium Severity
The frontend expects updatedCount in the response from the bulk submit-for-review endpoint, but the backend returns submittedCount. This causes response.data?.updatedCount to always be undefined, making the toast message fall back to selectedTaskIds.length instead of reflecting the actual number of tasks that were successfully submitted.
Additional Locations (1)
| ? `cancelled evidence review for ${assigneeName}` | ||
| : `rejected evidence by ${assigneeName}`, | ||
| data: { | ||
| action: isCancellation ? 'reject' : 'reject', |
There was a problem hiding this comment.
Audit log action always records 'reject' for cancellations
Medium Severity
In the rejectTask method, the audit log data.action field uses a ternary expression isCancellation ? 'reject' : 'reject' which always evaluates to 'reject'. When an admin/owner cancels a review (rather than the approver rejecting it), the audit trail cannot distinguish between the two different actions.
| activeMember?.id && task.approverId && activeMember.id === task.approverId; | ||
| const canApprove = evidenceApprovalEnabled && isInReview && isCurrentUserApprover; | ||
| const isCurrentUserAssignee = | ||
| activeMember?.id && task.assigneeId && activeMember.id === task.assigneeId; |
There was a problem hiding this comment.
Unused variable isCurrentUserAssignee is dead code
Low Severity
The variable isCurrentUserAssignee is defined but never referenced anywhere in the component. This appears to be leftover code from development that was either intended for a feature that wasn't completed or is simply dead code that clutters the approval state logic block.
| const dataToUpdate: { | ||
| status?: TaskStatus; | ||
| assigneeId?: string | null; | ||
| approverId?: string | null; |
There was a problem hiding this comment.
API allows in_review status without requiring approver
Medium Severity
The updateTask and updateTasksStatus methods accept in_review as a valid status without validating that an approverId is also set. While the frontend filters out in_review from status selectors, direct API calls can set tasks to in_review without an approver. This creates an inconsistent state where the task is pending approval but has no one who can approve it—only admins/owners can recover by rejecting.
Additional Locations (1)
1 participant
This is an automated pull request to release the candidate branch into production, which will trigger a deployment.
It was created by the [Production PR] action.