Projects: a view's contents cannot be read from any API

[MarkBennett]

What's happening

A project view's contents cannot be read from any API. ProjectV2View exposes a view's definition — filter, layout, groupByFields, sortByFields, visibleFields — but there is no items connection, and gh project has no equivalent command. There is no way to ask GitHub "what does view 5 show?".

{ __type(name: "ProjectV2View") { fields { name } } }

configuration, createdAt, databaseId, fields, filter, fullDatabaseId, groupBy,
groupByFields, id, layout, name, number, project, sortBy, sortByFields,
updatedAt, verticalGroupBy, verticalGroupByFields, visibleFields

Every field there describes how the view is configured. None of them returns what it shows.

Why it matters

We drive automation off an org project: a small number of saved views are the queues that people and scripts work from. Because a view's contents aren't readable, every automated query re-implements its view — one paginated items query for the whole board, then a jq expression that reproduces the view's filter by hand.

That works, but it means the project's views and the automation's queries are two independent definitions of the same queue, kept in step by convention rather than by construction. Drift is silent, and it has already happened twice on our board: one view quietly lost an is:open and kept looking correct, and another gained a qualifier that doesn't resolve (see the documentation note below for why that fails silently).

We deliberately are not building a filter → jq translation layer. The two filter languages aren't equivalent — see the parity note below — so it would be a lossy approximation that fails silently, which is worse than the honest duplication we have now.

The ask

An items connection on ProjectV2View, applying the view's filter, grouping and sort server-side, so a query can return exactly what a person sees in that view. Read-only is all we need.

A CLI surface for the same thing (gh project item-list --view <n>) is filed separately with cli/cli, since it depends on this.

Two related gaps, while I'm here

Filter parity — one qualifier, not a category. To be clear about what already works: is:blocked, is:blocking, blocked-by: and blocking: are supported in project view filters — they shipped with issue dependencies (changelog, 2025-08-21) and I've verified them in the UI. The one thing a view can't express is leaf-only: "issues that have no sub-issues". A project has a Parent issue field, so no:parent-issue works, and a Sub-issues progress field — but no sub-issue count, so there's no way to drop parent issues from a view. Automation that wants only actionable leaves therefore can't be mirrored by a view even once an items connection exists; the view would always be a superset.

The filtering documentation is incomplete, and unknown qualifiers fail silently. The qualifiers that shipped with issue dependencies aren't on the project filtering docs page — they're only in the changelog. That's compounded by the UI accepting an unrecognised qualifier without complaint: it's ignored rather than rejected, so someone who trusts the docs page writes something like no:blocked-by, sees a plausible-looking result, and ends up with a filter that matches far more than they think. That's exactly how one of our two drift incidents happened. Two asks: complete the page, and surface a warning in the UI when a qualifier isn't recognised.

[github-actions[bot]]

Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided.

This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers.

[MarkBennett]

Two related gaps filed alongside this one, since each is separately actionable:

• ProjectV2Workflow exposes no configuration — the auto-add workflows that guard project membership are unauditable by script.
• ProjectV2.views(orderBy:) silently ignores field — a bug rather than a request; a view's tab position is unreadable as a result.

And the CLI half of the ask above: cli/cli#14306.