feat: add parent to work item comment models - #71
Conversation
The v1 API accepts parent on comment create (a top-level comment on the same work item to reply to) and returns it on read, but the SDK models did not declare it; with extra="ignore" the field was silently dropped.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe work item comment models now support optional parent comment IDs. Comment creation requests can identify the top-level comment that the new comment replies to. The package version changes to ChangesWork item comments
Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to The SDK now preserves the optional parent comment ID for creating and reading threaded work item comments. No actionable merge-blocking risk remains beyond normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 1 files. (1 skipped: 1 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Linked to Plane Work Item(s) References This comment was auto-generated by Plane |
Only conflict was the version: this branch had already bumped to 0.3.0 for the v2 surface, while main remained at 0.2.24. Kept 0.3.0. Two commits came in. "add parent to work item comment models" (#71) touches plane/models/work_items.py, which is v1; this branch never touched it, so it merged cleanly and both `parent` fields survive. No v2 mirror is needed -- the v2 golden does not declare `parent` on work item comment create. The other, bumping black 24.8.0 -> 26.3.1, needed checking rather than trusting. CI does not run `black --check`, but it does regenerate plane/api/v2/_generated/ constants.py and `git diff --exit-code` it, and the generator formats its output with black -- so a formatter that disagreed with the committed file would fail CI for a reason unrelated to any code change. Verified against black 26.3.1 in an isolated environment: constants.py is left byte-identical, so the drift check still passes. That check also showed the two files here were formatted by an older black. They are reformatted with the now-pinned version. The other 59 files the new black would touch predate this branch and are left alone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014QwQ1tqb3831E7rezg5zqs
2 participants
Description
Adds
parenttoCreateWorkItemCommentandWorkItemComment.The v1 API already accepts
parentwhen creating a work item comment (the id of a top-level comment on the same work item to reply to) and returns it on read, but the SDK models did not declare the field — and withextra="ignore"aparent=passed toCreateWorkItemCommentwas silently dropped rather than rejected. Threading a reply through the SDK was therefore impossible.UpdateWorkItemCommentis left unchanged.Test
Consumed by the Pi native-agent threading change in makeplane/plane-ee (PAI-1827).
Summary by CodeRabbit