API: project column issues endpoint lacks state filter #4

New Issue

2026-05-15T21:28:31+03:00

oleks commented

2026-05-15 21:28:31 +03:00

Context

The user/org/repo project column-issues endpoint returns issues regardless of state. There's no way to ask "open only" — open and closed are intermixed in the response.

Example: GET /api/v1/users/{username}/-/projects/{id}/{column_id}/issues (and the analogous org / repo routes) returns every issue ever linked to that column, including closed ones.

Impact

Callers that want to render an active kanban column must filter state == "open" client-side after pulling the full list, including any closed cards that drifted into a non-Closed column or were closed without being moved.
Pagination is computed against the unfiltered total, so deep columns waste round trips returning closed items.

Proposed fix

Add a state query parameter on the column-issues endpoint matching the convention used elsewhere in the API: state=open (default), state=closed, state=all.

This mirrors GET /repos/{owner}/{repo}/issues?state=… and the project-list endpoint that already accepts state.

Workaround

Filter client-side on state == "open" after fetching.

## Context The user/org/repo project column-issues endpoint returns issues regardless of state. There's no way to ask "open only" — open and closed are intermixed in the response. Example: `GET /api/v1/users/{username}/-/projects/{id}/{column_id}/issues` (and the analogous org / repo routes) returns every issue ever linked to that column, including closed ones. ## Impact - Callers that want to render an active kanban column must filter `state == "open"` client-side after pulling the full list, including any closed cards that drifted into a non-Closed column or were closed without being moved. - Pagination is computed against the unfiltered total, so deep columns waste round trips returning closed items. ## Proposed fix Add a `state` query parameter on the column-issues endpoint matching the convention used elsewhere in the API: `state=open` (default), `state=closed`, `state=all`. This mirrors `GET /repos/{owner}/{repo}/issues?state=…` and the project-list endpoint that already accepts `state`. ## Workaround Filter client-side on `state == "open"` after fetching.

oleks added this to the (deleted) project 2026-05-15 21:29:24 +03:00

oleks referenced this issue from a commit

2026-05-15 21:54:46 +03:00

feat(api): state filter + populated num_issues on project columns

oleks referenced a pull request that will close this issue

2026-05-15 21:55:03 +03:00

feat(api): state filter + populated num_issues on project columns #6

oleks commented

2026-05-15 21:55:15 +03:00

PR up: #6 — adds ?state=open|closed|all (default open) on all three column-issues endpoints (user / org / repo), wired at the IssuesOptions.IsClosed layer via common.ParseIssueFilterStateIsClosed. Integration tests in all three suites verify default-open hides closed cards, state=closed returns them, and state=all returns both.

Not merging yet — the patched Gitea is the same instance hosting this issue, so a redeploy would interrupt the active session.

PR up: #6 — adds `?state=open|closed|all` (default `open`) on all three column-issues endpoints (user / org / repo), wired at the `IssuesOptions.IsClosed` layer via `common.ParseIssueFilterStateIsClosed`. Integration tests in all three suites verify default-open hides closed cards, `state=closed` returns them, and `state=all` returns both. Not merging yet — the patched Gitea is the same instance hosting this issue, so a redeploy would interrupt the active session.

oleks closed this issue

2026-05-15 22:00:51 +03:00

oleks moved this to Closed in My issues on 2026-05-15 22:08:22 +03:00

oleks referenced this issue

2026-05-17 14:15:19 +03:00

open_issues_count in /user/repos is stale — not invalidated/recomputed on issue create #16

Sign in to join this conversation.