You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add --list flag to todos position for cross-list moves (#372)
* Add --list flag to todos position for cross-list moves
Support moving a todo to a different todolist within the same project
via the reposition endpoint's parent_id field. Detects and rejects
cross-project moves with guidance.
Blocked on SDK exposing parentID on Reposition — will compile after
rebasing onto main with the new SDK release.
Closes#337
* Support todolist name resolution and improve cross-project validation
- Resolve --list via resolveTodolistInTodoset so names like "Sprint 1"
work, not just numeric IDs and URLs
- Use project context from todo URL, --in flag, and config for both
name resolution and cross-project validation
- Use ErrUsageHint for the cross-project error to show actionable guidance
- Update help text and SKILL.md placeholder to reflect name support
* Resolve project name before cross-project comparison
Project context from --in may be a name like "myproject" while the
list URL yields a numeric project ID. Resolve the name to an ID
before comparing, so --in myproject --list <same-project-url> doesn't
falsely reject.
Also consolidates project resolution: the resolved ID is reused for
both cross-project validation and todolist name resolution.
* Update surface snapshot with --list flag on todos position
* Add tests for --list flag on todos position
Cover the new cross-list move path:
- Cross-project URL rejection
- Same-project URL passes validation
- List name without project context requires --in
- Cross-project via config project ID
* Narrow cross-project guard to URL-sourced projects, include todolist_id in response
- Only fire the cross-project check when the todo's project comes from
its URL, not from config/flags. Config project is a default context
that may not match where a bare-ID todo actually lives.
- Include todolist_id in JSON response when --list is used so automation
can confirm the cross-list move.
* Defer project resolution to when it's actually needed
ResolveProject was called unconditionally when --list was provided and
the project context was non-numeric, even when the list was already a
numeric ID and no resolution was needed. This made otherwise valid
moves fail if the configured project name was stale.
Now only resolves when cross-project URL validation or todolist name
resolution actually requires the numeric project ID.
* Include --page in notifications list breadcrumb when not on first page
The read breadcrumb from 'notifications list --page 2' said
'basecamp notifications read <id>' without --page, leading users
into a "not found" error because read defaults to page 0. Now
carries the page context forward.
* Guard against empty list ID from malformed todolist URLs
extractWithProject can return an empty recording ID for URLs that
parse but have no recording segment (e.g. project URLs). Fail fast
with a targeted error instead of falling through to a confusing
"Invalid todolist ID".
* Validate --list URL type to reject non-todolist URLs
A todo URL or project URL passed as --list would silently extract the
wrong ID and use it as a todolist ID. Now validates via urlarg.Parse
that the URL is actually a todolists URL (correct type, not a
collection, has a recording ID).
0 commit comments