feat(cli): add --assignee filter to tasks list#3972
Conversation
Brings the CLI in line with the SDK (`assigneeId`) and MCP-v2 (`assigneeId`) which both already exposed assignee-by-user-id filtering on `task.list`. The tRPC procedure has supported it all along — the CLI was the only surface missing it.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (2)
📝 WalkthroughWalkthroughAdds a new ChangesCLI Assignee Filter
Terminal Test Description Update
Import Reordering in Terminal Lifecycle Hook
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Review rate limit: 6/8 reviews remaining, refill in 8 minutes and 9 seconds.Comment |
Greptile SummaryAdds Confidence Score: 4/5Safe to merge; the change is a minimal, additive flag with no breaking impact. Only P2 findings — a style suggestion about documenting/guarding the overlap between No files require special attention.
|
| Filename | Overview |
|---|---|
| packages/cli/src/commands/tasks/list/command.ts | Adds --assignee <userId> CLI flag mapped to assigneeId on the tRPC query; change is minimal and correct, with a minor style note about undocumented overlap with --assignee-me |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A["superset tasks list"] --> B{Options present?}
B -->|"--assignee <userId>"| C["assigneeId = userId"]
B -->|"--assignee-me"| D["assigneeMe = true"]
B -->|both supplied| E["both forwarded (no guard)"]
C --> F["tRPC task.list.query"]
D --> F
E --> F
F --> G["Returns filtered task rows"]
Prompt To Fix All With AI
Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 1
packages/cli/src/commands/tasks/list/command.ts:11-12
**Conflicting filters can be silently combined**
`--assignee <userId>` and `--assignee-me` are mutually exclusive from a user-intent perspective, but neither the CLI nor the underlying tRPC call enforces that constraint. If a user accidentally passes both, both `assigneeId` and `assigneeMe` will be forwarded to the API together. Depending on how the tRPC procedure combines those predicates (AND vs OR), it may silently return an unexpected result set instead of an error. A short guard or at least a description note (e.g. `"Filter by assignee user id (mutually exclusive with --assignee-me)"`) would make the behaviour explicit.
Reviews (1): Last reviewed commit: "feat(cli): add --assignee filter to `tas..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| assignee: string().desc("Filter by assignee user id"), | ||
| assigneeMe: boolean().alias("m").desc("Filter to my tasks"), |
There was a problem hiding this comment.
--assignee <userId> and --assignee-me are mutually exclusive from a user-intent perspective, but neither the CLI nor the underlying tRPC call enforces that constraint. If a user accidentally passes both, both assigneeId and assigneeMe will be forwarded to the API together. Depending on how the tRPC procedure combines those predicates (AND vs OR), it may silently return an unexpected result set instead of an error. A short guard or at least a description note (e.g. "Filter by assignee user id (mutually exclusive with --assignee-me)") would make the behaviour explicit.
Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/cli/src/commands/tasks/list/command.ts
Line: 11-12
Comment:
**Conflicting filters can be silently combined**
`--assignee <userId>` and `--assignee-me` are mutually exclusive from a user-intent perspective, but neither the CLI nor the underlying tRPC call enforces that constraint. If a user accidentally passes both, both `assigneeId` and `assigneeMe` will be forwarded to the API together. Depending on how the tRPC procedure combines those predicates (AND vs OR), it may silently return an unexpected result set instead of an error. A short guard or at least a description note (e.g. `"Filter by assignee user id (mutually exclusive with --assignee-me)"`) would make the behaviour explicit.
How can I resolve this? If you propose a fix, please make it concise.![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
🧹 Preview Cleanup CompleteThe following preview resources have been cleaned up:
Thank you for your contribution! 🎉 |
…h-in-code-2026-05-01-23-27-59
PR #3968 (terminal key handler refactor) introduced two biome violations on main: an import sort order and a quote-style nit. Both auto-fixed by `biome check --write`. No behavior change.
Bundles the 5 feat(cli) commits since v0.2.2: - automations + tasks alignment with SDK and MCP-v2 (#3966) - cross-device login via OAuth code + PKCE (#3965) - 'automations prompt' split into 'prompt get' / 'prompt set' (#3959) - --name filter on automations list (#3952) - --assignee filter on tasks list (#3972) Push cli-v0.2.3 after this lands to fire the release pipeline.
1 participant
Summary
Audited CLI / SDK / MCP-v2 alignment across all five domains (automations, tasks, workspaces, projects, hosts). Found and fixed one drift: the CLI's
tasks listwas missing the--assignee <userId>filter that both the SDK (assigneeId) and MCP-v2 (assigneeId) already expose. The tRPC procedure has supported it all along — the CLI was the only surface missing it.After this change, all three surfaces expose the same
task.listfilter set:statusId,priority,assigneeId,assigneeMe,creatorMe,search,limit,offset.Other findings (intentional, no fix needed)
workspaces.create({ agents })in the SDK is a higher-level helper that chainsworkspace.create+automation.create+automation.runNow. CLI/MCP users compose those calls directly. Documented as a defensible asymmetry.v2Project.create/v2Project.deleteexist in tRPC asjwtProcedure(added in feat(api): v2Project.delete via JWT, create accepts client-supplied id #3913) but aren't exposed via SDK/CLI/MCP-v2. Those are reserved for cloud-first create pipelines used by desktop and the host service.Test plan
superset tasks list --assignee <user-id>filters tasks to that assignee--assignee-mestill works as beforeSummary by cubic
Add
--assignee <user-id>totasks listto filter by assignee, aligning the CLI with the SDK and MCP‑v2 (assigneeIdontask.list);--assignee-meis unchanged. Also fixes minor desktop lint nits (import order, quote style) with no behavior change.Written for commit 7dd0bb1. Summary will update on new commits.
Summary by CodeRabbit