diff options
| author | Craig Jennings <c@cjennings.net> | 2026-06-03 06:52:14 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-06-03 06:52:14 -0500 |
| commit | 483660f9477cc9504a35a3a29ee1fbca52cccdb1 (patch) | |
| tree | 35177a9c002d37d5773289a6a04b4e05dbe3aa09 /tests/test-pearl-compose.el | |
| parent | 8acc99d88527a9dfecf7ebceb858f344819d10c3 (diff) | |
| download | pearl-483660f9477cc9504a35a3a29ee1fbca52cccdb1.tar.gz pearl-483660f9477cc9504a35a3a29ee1fbca52cccdb1.zip | |
feat(views): run a Linear view in its configured sort order
A Linear view's issue query passed no orderBy, so issues came back in Linear's API default, createdAt descending. That's neither the order set on the view in Linear nor the updatedAt-desc the rest of pearl uses, and the two unrelated defaults colliding is what made a view's order look random.
Linear exposes a view's configured sort in viewPreferencesValues (viewOrdering plus viewOrderingDirection), and the issues connection accepts an IssueSortInput sort arg that applies it server-side. I read the view's ordering when running it, translate it to that sort arg, and pass it through, so a view arrives in the order you gave it in Linear. The sort is stamped on the recorded source so a refresh keeps the same order. An ordering pearl can't map, or a view with no preference, falls back to updatedAt-desc rather than the createdAt default, so it lines up with every other pearl fetch.
This is the sort half of matching the Linear UI. Grouping (issueGrouping into org sections) is the larger remaining half and is tracked separately.
Diffstat (limited to 'tests/test-pearl-compose.el')
0 files changed, 0 insertions, 0 deletions
