feat: update Customers API#59
Conversation
|
Warning Review limit reached
Next review available in: 50 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughCustomer APIs now support property values, work-item associations, external-ID deletion, richer customer/property models, and paginated customer requests. HTTP POST and DELETE helpers accept query parameters, while unit tests cover the expanded customer workflows. ChangesCustomer API expansion
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant Client
participant Customers
participant CustomerWorkItems
participant PlaneAPI
Client->>Customers: access customer resources
Customers->>CustomerWorkItems: link or unlink work items
CustomerWorkItems->>PlaneAPI: send query parameters and payload
PlaneAPI-->>CustomerWorkItems: return linked or removed work-item data
CustomerWorkItems-->>Client: return validated response
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
plane/api/customers/requests.py (2)
17-35: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winVersion the paginated request-list return type as a breaking change.
plane/api/customers/requests.py#L17-L35: preserve the previous list contract or explicitly introduce the pagination model as a breaking API change.pyproject.toml#L7-L7: use a minor version such as0.3.0if compatibility is not retained.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@plane/api/customers/requests.py` around lines 17 - 35, The customers.requests.list method changes its return contract to PaginatedCustomerRequestResponse; either preserve the previous list-compatible contract or explicitly release this as a breaking change. If retaining the new pagination model, update pyproject.toml to the next minor version (such as 0.3.0); otherwise adjust list to return the prior type and behavior.
48-70: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winAccept only
CreateCustomerRequesthere.CustomerRequestis a response model withextra="allow", so passing it throughmodel_dump(exclude_none=True)can send read-only extras back to the create endpoint. Normalize legacy callers throughCreateCustomerRequestbefore posting.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@plane/api/customers/requests.py` around lines 48 - 70, Update the create method in the customer requests client to accept only CreateCustomerRequest and normalize any legacy CustomerRequest input into that model before calling _post. Ensure the payload comes exclusively from the normalized CreateCustomerRequest.model_dump(exclude_none=True), preventing response-only extra fields from being submitted.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@plane/api/customers/base.py`:
- Around line 84-97: Rename the affected customer resource methods to use
standard CRUD verbs: change delete_by_external_id to delete in
plane/api/customers/base.py lines 84-97; rename the bulk set method to create in
plane/api/customers/property_values.py lines 42-61; rename the work-item linking
method to create in plane/api/customers/work_items.py lines 54-78; and rename
the unlinking method to delete in plane/api/customers/work_items.py lines
80-102. Preserve each method’s existing behavior and parameters.
In `@plane/api/customers/property_values.py`:
- Around line 27-40: Add response DTOs for customer property values and update
both list() and retrieve() to validate _get() results through the appropriate
DTO model_validate() calls before returning them. Preserve the documented empty
mapping behavior where applicable, while ensuring malformed responses are
rejected before callers can access unexpected shapes or invoke .get().
In `@tests/unit/test_customers.py`:
- Around line 53-65: Update test_list_customers_with_params and
test_list_customers_paginates to create at least two customers before listing,
assert the expected page size and pagination state unconditionally, and clean up
the created customers afterward. Reuse the existing customer creation and
deletion helpers/fixtures in the test suite.
- Around line 143-146: Update the cleanup blocks in the customer tests,
including the repeated cleanup handlers, to suppress only the expected
not-found/404 exception from delete operations. Re-raise all other exceptions so
failures deleting customers, properties, requests, or work items are visible
instead of silently ignored.
---
Outside diff comments:
In `@plane/api/customers/requests.py`:
- Around line 17-35: The customers.requests.list method changes its return
contract to PaginatedCustomerRequestResponse; either preserve the previous
list-compatible contract or explicitly release this as a breaking change. If
retaining the new pagination model, update pyproject.toml to the next minor
version (such as 0.3.0); otherwise adjust list to return the prior type and
behavior.
- Around line 48-70: Update the create method in the customer requests client to
accept only CreateCustomerRequest and normalize any legacy CustomerRequest input
into that model before calling _post. Ensure the payload comes exclusively from
the normalized CreateCustomerRequest.model_dump(exclude_none=True), preventing
response-only extra fields from being submitted.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: f537a59a-8a9f-4a59-abac-bf1388641eaa
📒 Files selected for processing (8)
plane/api/base_resource.pyplane/api/customers/base.pyplane/api/customers/property_values.pyplane/api/customers/requests.pyplane/api/customers/work_items.pyplane/models/customers.pypyproject.tomltests/unit/test_customers.py
…ences and improve error handling
Description
Adds support for the latest Customers API, including:
Type of Change
Screenshots and Media (if applicable)
N/A
Test Scenarios
References
N/A
Summary by CodeRabbit
New Features
Bug Fixes
Chores