Fix PATCH project estimate validation bug

[SamuelTR20]

Description

Type of Change

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] Feature (non-breaking change which adds functionality)
• [ ] Improvement (change that would cause existing functionality to not work as expected)
• [ ] Code refactoring
• [ ] Performance improvements
• [ ] Documentation update

Screenshots and Media (if applicable)

Not applicable.

Test Scenarios

Verified that PATCH requests updating the estimate field now succeed when the estimate exists. Verified that other fields in the Project PATCH still work as expected.

References

---

[!NOTE] Fixes project update validation to check the estimate by its id, allowing PATCH updates when a valid estimate is provided.

• Backend/Serializers:
  • apps/api/plane/api/serializers/project.py:
    • In ProjectUpdateSerializer.update, validate estimate by its id when checking project association to allow PATCH updates with an existing estimate.

^{Written by Cursor Bugbot for commit d10a0bb6d547efb8a581be65ef011dbb4ad27a4e. This will update automatically on new commits. Configure here.}

Summary by CodeRabbit

• Bug Fixes
  • Resolved a validation issue when updating a project’s estimate. The API now correctly handles inputs provided as either an object or an ID, ensuring the correct estimate is referenced. This reduces unexpected 400 errors, improves compatibility with clients sending nested data, and stabilizes project update flows.

[coderabbitai[bot]]

Walkthrough

Updates a serializer in apps/api/plane/api/serializers/project.py: minor formatting tweak and a logic change in ProjectUpdateSerializer.update to validate the estimate field by using its id when an estimate object is provided.

Changes

Cohort / File(s)	Summary
Serializer update logic apps/api/plane/api/serializers/project.py	Formatting tweak in class declaration. In update(), estimate validation now dereferences validated_data.get("estimate").id to perform existence checks, handling cases where an estimate object (not just an id) is supplied.

Sequence Diagram(s)

sequenceDiagram
  actor Client
  participant API as API Endpoint
  participant Serializer as ProjectUpdateSerializer
  participant DB as Estimate Store

  Client->>API: PATCH /projects/{id} { estimate: {...} or id }
  API->>Serializer: validate & update(data)
  alt estimate provided
    Serializer->>Serializer: extract estimate_id<br/>(obj.id if object, else value)
    Serializer->>DB: check Estimate.exists(estimate_id)
    alt exists
      DB-->>Serializer: ok
      Serializer-->>API: proceed with update
      API-->>Client: 200 Updated
    else not found
      DB-->>Serializer: not found
      Serializer-->>API: raise ValidationError
      API-->>Client: 400 Invalid estimate
    end
  else no estimate
    Serializer-->>API: proceed without estimate change
    API-->>Client: 200 Updated
  end

  note over Serializer: Changed: uses estimate.id when object is provided

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

I twitch my nose at tidy code,
A hop, a skip—validation mode.
If estimate’s an object, aha, the id!
I nibble bugs where they might hide.
One small space, one safer check—
Carrots saved, no broken spec. 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description Check	⚠️ Warning	The description template’s “### Description” section contains only the placeholder comment and lacks a narrative of what was changed and why, and the “### References” section is empty instead of indicating related issue links or stating none apply, leaving required template fields incomplete.	Please replace the placeholder under “### Description” with a clear summary of the code changes and their rationale, and update “### References” by linking any relevant issues or explicitly note that no related issues exist.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title “Fix PATCH project estimate validation bug” succinctly captures the primary change by specifying the HTTP method affected (PATCH), the resource (project estimate), and the nature of the update (validation bug fix), making it clear and appropriately scoped for someone skimming the merge history.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• [ ] 📝 Generate Docstrings

🧪 Generate unit tests

• [ ] Create PR with unit tests
• [ ] Post copyable unit tests in a comment

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🧪 Early access (Sonnet 4.5): enabled

We are currently testing the Sonnet 4.5 model, which is expected to improve code review quality. However, this model may lead to increased noise levels in the review comments. Please disable the early access features if the noise level causes any inconvenience.

Note:

• Public repositories are always opted into early access features.
• You can enable or disable early access features from the CodeRabbit UI or by updating the CodeRabbit configuration file.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}