Add --sort and --reverse flags to list commands#299
Conversation
There was a problem hiding this comment.
4 issues found across 10 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="internal/commands/cards.go">
<violation number="1" location="internal/commands/cards.go:160">
P2: Validate the sort field before making API calls. Currently `validateSortField` runs after all data has been fetched, so `--sort bogus` wastes API round-trips (especially in the aggregate path which fetches N columns). Move an early validation against the full superset of allowed fields to the top of the function, alongside the other flag-combination checks.</violation>
</file>
<file name="internal/commands/projects.go">
<violation number="1" location="internal/commands/projects.go:120">
P2: `--reverse` without `--sort` is silently ignored. The default alphabetical sort in the `else if` branch doesn't consult the `reverse` flag, so `basecamp projects list --reverse` has no effect. Either warn that `--reverse` requires `--sort`, or apply `reverse` to the default sort too.</violation>
</file>
<file name="internal/commands/people.go">
<violation number="1" location="internal/commands/people.go:250">
P2: `--reverse` is silently ignored when `--sort` is not specified. The default name sort in the `else` branch doesn't consult the `reverse` flag, so `basecamp people list --reverse` produces the same output as `basecamp people list`.</violation>
</file>
<file name="internal/commands/messages.go">
<violation number="1" location="internal/commands/messages.go:148">
P2: Sort field validation runs after the API call. Move `validateSortField` to the top of `runMessagesList` (alongside the other flag-combination checks) so an invalid `--sort` value fails fast instead of making a wasted network round-trip.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
There was a problem hiding this comment.
Pull request overview
Adds client-side sorting support to multiple list subcommands in internal/commands, exposing consistent --sort <field> and --reverse flags and implementing shared sort helpers with validation.
Changes:
- Introduces shared sort/validation helpers (
sort.go) and unit tests (sort_test.go) for supported resource types and edge cases (notably due-date ordering). - Adds
--sort/--reverseflags and applies client-side sorting to list outputs across todos, todolists, cards, messages, projects, people, and schedule entries. - Updates CLI surface snapshot to reflect the new flags.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 12 comments.
Show a summary per file
| File | Description |
|---|---|
| internal/commands/todos.go | Adds --sort/--reverse, applies sorting for single-list and aggregate paths, and adds an aggregate guard requiring --all when sorting. |
| internal/commands/todolists.go | Adds --sort/--reverse and sorts todolist results client-side. |
| internal/commands/cards.go | Adds --sort/--reverse and sorts cards in single-column and aggregate column modes with field restrictions. |
| internal/commands/messages.go | Adds --sort/--reverse and sorts message results client-side. |
| internal/commands/projects.go | Adds --sort/--reverse while preserving the prior default alphabetical sort when --sort is not provided. |
| internal/commands/people.go | Adds --sort/--reverse, sorts raw SDK people before slimming output, preserves previous default sort when --sort is not provided. |
| internal/commands/schedule.go | Adds --sort/--reverse and sorts schedule entry results client-side. |
| internal/commands/sort.go | New shared sort helpers + sort-field validation and due-date comparison behavior. |
| internal/commands/sort_test.go | New unit tests for sort helpers, validation, reverse behavior, and due-date edge cases. |
| .surface | Records new flags in the CLI surface snapshot. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c3fc42a5bd
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
All four issues fixed in 6405ffe:
|
There was a problem hiding this comment.
1 issue found across 9 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="internal/commands/todos.go">
<violation number="1" location="internal/commands/todos.go:454">
P2: The `position` rejection should come before the `--all` requirement check. Currently, `--sort position` without `--all` returns the misleading error "use --all when listing across todolists" instead of the correct "position requires --list". Swapping these two guards fixes the message.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
validateSortField checks field against an allowed set and returns a usage error listing valid values. Per-type sort functions (sortTodos, sortCards, sortMessages, sortTodolists, sortProjects, sortPeople, sortScheduleEntries) apply default directions: title/position/name ascending, created/updated descending, due ascending with empties last. --reverse flips via slices.Reverse. 30 unit tests cover every sort function, field validation, due-date edge cases, reverse behavior, and position scoping rules.
Wire sort helpers into todos, cards, messages, todolists, projects, people, and schedule entries list commands. When --sort is set it overrides any hardcoded default (projects alphabetical, people name). When not set, existing behavior is preserved exactly. Position is scoped to single-parent contexts: allowed with --list (todos) or --column (cards), omitted when aggregating. The todos aggregate path requires --all when --sort is passed because default paging silently samples per-todolist. People sorts the raw []basecamp.Person before slimming to the display type. The only allowed field is "name" (not "title", which is the job title field on Person).
- Validate sort field early (alongside other flag checks) before any API
calls, so --sort bogus fails fast without wasting network round-trips
- Honor --reverse on default sorts for projects and people, so
`basecamp projects list --reverse` works without --sort
- Sort schedule entries by Summary with Title fallback, matching the
display behavior in schedule show
- Make default people sort case-insensitive (ToLower) to match --sort
name semantics
- Reject --sort position early in aggregate paths with specific error
messages ("requires --column" / "requires --list")
Swap the guard order so `--sort position` without `--list` gets the
correct error ("requires --list") rather than the misleading "--sort
requires --all" message.
There was a problem hiding this comment.
Pull request overview
Adds client-side sorting controls to multiple list commands across the Basecamp CLI, enabling consistent ordering via --sort <field> and --reverse while preserving existing default behaviors when sorting is not requested.
Changes:
- Introduces
--sort/--reverseflags and early sort-field validation for todos, todolists, cards, messages, projects, people, and schedule entries. - Adds shared sorting utilities (
validateSortField, per-typesort*helpers, due-date comparison) ininternal/commands/sort.go. - Adds unit tests for sort helpers and updates
.surfaceto reflect the new flags.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| internal/commands/todos.go | Adds sort/reverse flags, validates sort fields, applies client-side sorting, and enforces --all when sorting across todolists. |
| internal/commands/todolists.go | Adds sort/reverse flags, validation, and applies client-side sorting to todolist results. |
| internal/commands/cards.go | Adds sort/reverse flags, validates sort fields early, enforces no position sorting in aggregate mode, and applies client-side sorting. |
| internal/commands/messages.go | Adds sort/reverse flags, validation, and applies client-side sorting to message lists. |
| internal/commands/projects.go | Adds sort/reverse flags, validation, and hooks project sorting helpers while preserving the existing default alphabetization behavior. |
| internal/commands/people.go | Adds sort/reverse flags, validation, and sorts raw SDK people before slimming output. |
| internal/commands/schedule.go | Adds sort/reverse flags, validation, and applies client-side sorting to schedule entry lists. |
| internal/commands/sort.go | New shared sorting/validation helpers and per-entity sorting implementations. |
| internal/commands/sort_test.go | New unit tests covering validation, due-date comparator behavior, and sort helpers. |
| .surface | Captures the new CLI flags in the surface snapshot. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…schedule Covers --reverse behavior and updated/created sort directions for types that were only tested on title/position.
Summary
--sort <field>and--reverseflags to 7 list commands: todos, cards, messages, todolists, projects, people, and schedule entriessort.gowith per-type functions, field validation, and default sort directions (title/position ascending, created/updated descending, due ascending with empties last)--allwhen--sortis passed (results are sampled per-list without it)[]basecamp.Personbefore slimming; usesnamefield (nottitle, which is job title)--sortis not set, with one intentional change: people default sort is now case-insensitive (strings.ToLower) to match--sort namesemantics and projects default sortTest plan
sort_test.gocovering every sort function, field validation, due-date edge cases, reverse behavior across all types, and position scopingbin/cipasses (formatting, vetting, linting, unit tests, e2e tests, surface snapshot, skill drift, bare groups)basecamp todos list --list <id> --sort dueshows soonest-first with empties at bottombasecamp projects list --sort created --reverseshows oldest projects firstbasecamp todos list --sort title(without --list or --all) returns usage error