Gap
GET /v1/workspaces/WS/tasks accepts status as a query filter but not assignee_id. The CLI tflowctl task list wants both for symmetric filtering. Currently the CLI exposes only --status; --assignee was dropped from the PR scope.
Proposed
Add a query parameter to the existing handler:
| Aspect |
Shape |
| Name |
assignee_id |
| Location |
query |
| Type |
UUID, optional |
| Behavior |
When present, filter results to tasks where assignee_id matches. Combines with status as logical AND. |
| Null filter |
Open question: do we want a way to filter for unassigned tasks? Possible mechanism: assignee_id=null (string literal) maps to IS NULL. Decide when implementing. |
Why
Symmetric with status. Reduces client-side filtering. Lets the CLI add --assignee without changing pagination assumptions when pagination eventually arrives.
Consumer
CLI Issue #104 ships without --assignee. Once this lands, --assignee becomes a one-line addition to the list params dict in api/tasks.py.
Gap
GET /v1/workspaces/WS/tasks accepts status as a query filter but not assignee_id. The CLI tflowctl task list wants both for symmetric filtering. Currently the CLI exposes only --status; --assignee was dropped from the PR scope.
Proposed
Add a query parameter to the existing handler:
Why
Symmetric with status. Reduces client-side filtering. Lets the CLI add --assignee without changing pagination assumptions when pagination eventually arrives.
Consumer
CLI Issue #104 ships without --assignee. Once this lands, --assignee becomes a one-line addition to the list params dict in api/tasks.py.