Skip to content

Conversation

@Marfuen
Copy link
Contributor

@Marfuen Marfuen commented Nov 13, 2025

  • Add failed and not_relevant statuses to task list display
  • Update StatusId type to include all task statuses
  • Add filter buttons for failed and not_relevant statuses
  • Sort tasks alphabetically by title (A-Z) instead of by order field

What does this PR do?

  • Fixes #XXXX (GitHub issue number)
  • Fixes COMP-XXXX (Linear issue number - should be visible at the bottom of the GitHub issue description)

Visual Demo (For contributors especially)

A visual demonstration is strongly recommended, for both the original and new change (video / image - any one).

Video Demo (if applicable):

  • Show screen recordings of the issue or feature.
  • Demonstrate how to reproduce the issue, the behavior before and after the change.

Image Demo (if applicable):

  • Add side-by-side screenshots of the original and updated change.
  • Highlight any significant change(s).

Mandatory Tasks (DO NOT REMOVE)

  • I have self-reviewed the code (A decent size PR without self-review might be rejected).
  • I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
  • I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

  • Are there environment variables that should be set?
  • What are the minimal test data to have?
  • What is expected (happy path) to have (input and output)?
  • Any other important info that could help to test that PR

Checklist

  • I haven't read the contributing guide
  • My code doesn't follow the style guidelines of this project
  • I haven't commented my code, particularly in hard-to-understand areas
  • I haven't checked if my changes generate no new warnings

- Add failed and not_relevant statuses to task list display
- Update StatusId type to include all task statuses
- Add filter buttons for failed and not_relevant statuses
- Sort tasks alphabetically by title (A-Z) instead of by order field
@vercel
Copy link

vercel bot commented Nov 13, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
app Building Building Preview Comment Nov 13, 2025 1:13am
1 Skipped Deployment
Project Deployment Preview Comments Updated (UTC)
portal Skipped Skipped Nov 13, 2025 1:13am

@comp-ai-code-review
Copy link

comp-ai-code-review bot commented Nov 13, 2025

🔒 Comp AI - Security Review

🟡 Risk Level: MEDIUM

OSV: GHSA-rwvc-j5jr-mgvh in ai@5.0.0; code shows unvalidated client task id/status (TaskList.tsx) and page queries returning full user objects with weak status validation and unbounded findMany (page.tsx).


📦 Dependency Vulnerabilities

🟢 NPM Packages (LOW)

Risk Score: 2/10 | Summary: 1 low CVE found

Package Version CVE Severity CVSS Summary Fixed In
ai 5.0.0 GHSA-rwvc-j5jr-mgvh LOW N/A Vercel’s AI SDK's filetype whitelists can be bypassed when uploading files 5.0.52

🛡️ Code Security Analysis

View 2 file(s) with issues

🟡 apps/app/src/app/(app)/[orgId]/tasks/components/TaskList.tsx (MEDIUM Risk)

# Issue Risk Level
1 Unvalidated client-sent task id/status to server action MEDIUM
2 Possible privilege escalation if server action lacks auth checks MEDIUM
3 Debug console.log leaks task data in client console MEDIUM
4 No client-side error handling for updateTaskAction failures MEDIUM

Recommendations:

  1. Enforce strict server-side validation for task updates: validate that the task id exists, that the provided status is one of the allowed statuses, and that the id/status values are of the expected types (use a schema validator such as zod/ajv). Never trust client-provided ids or enums.
  2. Implement authorization/ownership checks in the server action (updateTaskAction): verify the requesting user is authenticated and authorized to modify the specific task (ownership or RBAC checks). Return appropriate 403/401 responses when checks fail.
  3. Remove debug console.log calls that print task or user data, or gate them behind a production-safe check (e.g., only log in development NODE_ENV). Avoid logging sensitive task/user data to the client console.
  4. Add robust client-side error handling for updateTaskAction: await/then/catch the action result (or use the status returned by useAction) and surface errors to the user (toasts, inline errors). Implement optimistic updates with rollback on failure or show a loading/disabled state while the update is executing.
  5. Prevent concurrent/conflicting updates: disable drag/drop or further update attempts while an update is in progress (the code already checks updateTaskStatus but should also prevent multiple rapid invocations).
  6. Add server-side input sanitization and canonicalization before persistence and ensure all DB queries use parameterized queries/ORM methods to avoid injection risks.
  7. Add centralized auditing/logging on the server for task update attempts (success/failure) so suspicious activity can be detected and investigated.
  8. Perform a security review of the updateTaskAction implementation (server-side) to ensure no missing checks; treat findings here as actionable until the server action proves correct.

🟡 apps/app/src/app/(app)/[orgId]/tasks/page.tsx (MEDIUM Risk)

# Issue Risk Level
1 Member queries include full user object (possible sensitive data exposure) MEDIUM
2 Weak validation of statusParam via 'in' operator MEDIUM
3 Unbounded findMany queries may return excessive rows MEDIUM

Recommendations:

  1. Instead of include: { user: true }, use select to return only the specific user fields required by the UI (e.g., id, name, email) and explicitly exclude sensitive fields such as passwords, tokens, or internal flags.
  2. Validate statusParam against an explicit whitelist or a strict enum check. For example, map allowed string values to TaskStatus members or use a Set of allowed values and check membership before using it in the query.
  3. Add pagination and limits to all findMany calls (e.g., take/skip or cursor-based pagination). Enforce a maximum page size server-side and consider returning counts separately or via a capped summary to avoid huge payloads or excessive DB load.
  4. Optional UI/consistency improvement: although DB queries use session.activeOrganizationId (so org access is enforced server-side), consider validating params.orgId === session.activeOrganizationId and returning 403 or normalizing the URL if they differ. This prevents confusing/incorrect breadcrumb links and avoids exposing UI-level inconsistencies.

💡 Recommendations

View 3 recommendation(s)
  1. Upgrade the vulnerable dependency: bump ai to >=5.0.52 (package.json + lockfile) and rebuild to apply the GHSA-rwvc-j5jr-mgvh fix.
  2. Harden task update flow (TaskList.tsx / updateTaskAction): add strict server-side validation (e.g., zod schema validating id type/format and status against TaskStatus enum) and enforce authorization in the server action (verify session user owns the task or has RBAC before applying updates; return 401/403 on failure).
  3. Limit and sanitize page queries (page.tsx): replace include: { user: true } with select of only required fields (e.g., id,name,email), validate statusParam against an explicit whitelist/enum before using in queries, and add pagination (take/skip or cursor) with a server-side max page size.

Powered by Comp AI - AI that handles compliance for you. Reviewed Nov 13, 2025

@Marfuen Marfuen merged commit 413b14c into main Nov 13, 2025
7 of 8 checks passed
@Marfuen Marfuen deleted the mariano/failed-tasks branch November 13, 2025 01:13
claudfuen pushed a commit that referenced this pull request Nov 13, 2025
## [1.57.1](v1.57.0...v1.57.1) (2025-11-13)

### Bug Fixes

* **tasks:** show all task statuses and sort alphabetically ([#1743](#1743)) ([413b14c](413b14c))
@claudfuen
Copy link
Contributor

🎉 This PR is included in version 1.57.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants