aboutsummaryrefslogtreecommitdiff
path: root/tests/test-bootstrap.el
diff options
context:
space:
mode:
authorCraig Jennings <c@cjennings.net>2026-06-03 06:52:14 -0500
committerCraig Jennings <c@cjennings.net>2026-06-03 06:52:14 -0500
commit483660f9477cc9504a35a3a29ee1fbca52cccdb1 (patch)
tree35177a9c002d37d5773289a6a04b4e05dbe3aa09 /tests/test-bootstrap.el
parent8acc99d88527a9dfecf7ebceb858f344819d10c3 (diff)
downloadpearl-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-bootstrap.el')
0 files changed, 0 insertions, 0 deletions