Projects: ProjectV2.views(orderBy:) silently ignores field

[MarkBennett]

Describe the bug

ProjectV2.views accepts orderBy: ProjectV2ViewOrder, and ProjectV2ViewOrderField offers POSITION, CREATED_AT and NAME. The direction is honoured, but the field appears to be ignored — every value returns the same sequence.

Steps to reproduce

Against any org project with several views:

{
  organization(login: "ORG") {
    projectV2(number: N) {
      views(first: 20, orderBy: { field: POSITION, direction: ASC }) {
        nodes { number name }
      }
    }
  }
}

Run it four times, varying only field and direction. On a project with seven views — numbered 1–6 and 8, view 7 having been deleted — whose names do not sort alphabetically into the same order as their numbers:

field: POSITION, direction: ASC   ->  1,2,3,4,5,6,8
field: NAME,     direction: ASC   ->  1,2,3,4,5,6,8
field: POSITION, direction: DESC  ->  8,6,5,4,3,2,1
field: NAME,     direction: DESC  ->  8,6,5,4,3,2,1

CREATED_AT gives the same. Note the second line: NAME returns exact view-number order even though the names are not in alphabetical order, so it is demonstrably not being applied. On this project, sorting the names properly would have given 4,1,5,3,2,8,6.

Expected behaviour

field: POSITION returns the views in the order they appear as tabs; field: NAME returns them alphabetically. At the moment direction is the only argument that changes anything, and the results always come back in view-number order.

Why it matters

There is no other way to read a view's tab position. A view's number is a stable identifier, not a position — numbers aren't reused after a delete, so the sequence has gaps (7 is missing above), and reordering views in the UI produces no observable change anywhere in the API.

That means documentation or tooling that mirrors a project's views can't be kept in the order a person actually sees, and a reconciler can't detect or restore an accidental reorder. POSITION existing in the enum suggests this is meant to work.

Version

Reproduced against api.github.com today, via gh api graphql (gh 2.89.0).

Related

Part of the same gap as a view's contents cannot be read from any API — the API exposes a view's definition but nothing about how it presents.

[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.