Fixes #8221 - Listing work items with API request does not filter by user ID

[Karthik7406]

Description

Fixes issue #8221

Type of Change

• Bug fix

Screenshots and Media (if applicable)

Test Scenarios

References

---

Note

Adds assignee query parameter to list work items and filters both results and total count by assignee ID.

• Backend/API
  • Work Items list (apps/api/plane/api/views/issue.py):
    • Accepts assignee query param and filters issue_queryset and total_issue_queryset by assignees__id.
    • Keeps existing ordering (priority/state/labels/assignees) behavior intact.

^{Written by Cursor Bugbot for commit 0b13a47. This will update automatically on new commits. Configure here.}

Summary by CodeRabbit

• New Features
  • Added assignee filtering for the issue list. You can now filter and view only items assigned to specific users.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The change adds an optional "assignee" query parameter to the issue listing endpoint that filters work items by the specified assignee ID. When provided, both the paginated results and total count queryset are filtered to return only issues assigned to that user.

Changes

Cohort / File(s)	Summary
Assignee filtering for issue listings apps/api/plane/api/views/issue.py	Added optional "assignee" GET parameter to IssueListCreateAPIEndpoint that filters issue_queryset and total_issue_queryset by assignees__id when provided

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Single file modification affecting one endpoint
• Addition follows existing filter pattern with minimal logic density
• Consider verifying filter applies correctly to both paginated and total querysets

Poem

🐰 An assignee filter hops into view,
Narrowing issues to just what's due,
One query parameter, clean and neat,
Makes filtering assignments quite sweet! 🔍

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description is largely incomplete. While it mentions the issue reference and includes screenshots, it lacks critical sections: detailed description of changes, properly checked Type of Change, and test scenarios.	Complete the description section with details about what was changed and why. Check the Bug fix checkbox. Add test scenarios describing how the assignee filter was verified to work correctly.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically describes the main change: adding assignee filtering to work item API listing, which directly addresses the referenced issue #8221.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[CLAassistant]

All committers have signed the CLA.

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

apps/api/plane/api/views/issue.py (1)

268-303: Document the new assignee query parameter and confirm naming consistency

Reading assignee_id = request.GET.get("assignee") wires in the filter, but work_item_docs(...parameters=[...]) above still doesn’t advertise this query param. For clients relying on the OpenAPI schema or auto‑generated SDKs, this makes the feature effectively hidden.

I suggest:

• Adding an explicit assignee/assignee_id parameter to the parameters list (via a shared constant in plane.utils.openapi if you follow that pattern).
• Double‑checking that "assignee" matches the parameter name used in the issue description/clients (e.g., whether the expected key is assignee, assignee_id, or assignees), and aligning here + in docs accordingly.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 22339b9 and 0b13a47.

📒 Files selected for processing (1)

• apps/api/plane/api/views/issue.py (2 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

apps/api/plane/api/views/issue.py (1)

apps/api/plane/app/views/issue/base.py (6)

• get (81-188)
• get (740-743)
• get (775-786)
• get (1001-1076)
• get (1161-1171)
• get (1180-1340)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Cursor Bugbot

🔇 Additional comments (1)

apps/api/plane/api/views/issue.py (1)

345-351: Assignee filtering logic looks correct and keeps pagination consistent

Filtering both issue_queryset and total_issue_queryset by assignees__id=assignee_id when the param is present correctly narrows the listed items and ensures the total count used for pagination matches what’s returned.

No further changes needed here for correctness relative to the stated bug.