[SILO-1158] chore: add context for project in relations API

[Saurabhkmr98]

Description

• Modified the work item relations GET endpoint to return {project_id, issue_id} objects instead of flat UUID arrays, enabling consumers to identify which project each related work item belongs to.
• Replaced the single aggregate + ArrayAgg query with a .values() query that fetches each relation row with its associated project IDs, then builds the response in Python with proper deduplication for symmetric relation types (duplicate, relates_to).
• Cleaned up unused imports (ArrayAgg, ArrayField, Coalesce, UUIDField) and updated the OpenAPI example to reflect the new response shape.

Response format change

Before:

{
  "blocking": ["<issue_uuid>", "<issue_uuid>"],
  "blocked_by": ["<issue_uuid>"],
  ...
}

After:

{
  "blocking": [
    {"project_id": "<project_uuid>", "issue_id": "<issue_uuid>"},
    {"project_id": "<project_uuid>", "issue_id": "<issue_uuid>"}
  ],
  "blocked_by": [
    {"project_id": "<project_uuid>", "issue_id": "<issue_uuid>"}
  ],
  ...
}

Type of Change

• 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

Summary by CodeRabbit

• Refactor
  • Relation endpoints now return structured relation entries (project_id + issue_id) instead of raw IDs, enabling clear cross-project references.
• Bug Fixes
  • Relation lists are consistently grouped, deduplicated, and initialized as empty when none exist, fixing incorrect/misplaced relation entries.

[makeplane]

Linked to Plane Work Item(s)

• [SILO-1158] Add project context in WI relations API (community)

This comment was auto-generated by Plane

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 788829e0-899f-4d11-8ec5-475268895d1f

📥 Commits

Reviewing files that changed from the base of the PR and between 7645c59 and 8fb1f22.

📒 Files selected for processing (1)

• apps/api/plane/api/serializers/issue.py

---

📝 Walkthrough

Walkthrough

The issue relations aggregation was moved from DB-level array aggregation to manual per-relation iteration with deduplication. The API response shape for relations changed from UUID lists to objects with project_id and issue_id; relation grouping logic was adjusted to populate bidirectional lists correctly.

Changes

Cohort / File(s)	Summary
Issue relations view refactor apps/api/plane/api/views/issue.py	Removed array-aggregation imports/usage (UUIDField, Coalesce, ArrayAgg, ArrayField). Replaced with iteration over a .values(...) queryset containing issue_project_id and related_issue_project_id. Reworked grouping logic for blocking/blocked_by, duplicate/relates_to, start_before/start_after, finish_before/finish_after. Implemented manual deduplication and initialize empty lists before iteration. Response entries now objects {project_id, issue_id}.
Serializers: relation ref type apps/api/plane/api/serializers/issue.py	Added IssueRelationRefSerializer (fields: project_id, issue_id). Updated IssueRelationResponseSerializer to use IssueRelationRefSerializer for lists blocking, blocked_by, duplicate, relates_to, start_after, start_before, finish_after, finish_before and revised help text to reflect (project_id, issue_id) pairs.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🐰 I hopped through relations, one by one,

swapped arrays for loops and careful fun,
paired each issue with its project ID,
deduped the paths so all is tidy,
nibbles of logic — a rabbit's small deed.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly identifies the main change: adding project context to the relations API response format.
Description check	✅ Passed	The PR description provides detailed information about the changes, includes before/after response format examples, and correctly identifies the change type.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore-modify_relations_response

---

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

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

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/api/plane/api/views/issue.py`:
- Around line 2291-2323: The API changed: list_work_item_relations now returns
relation refs ({project_id, issue_id}) but the serializer and web consumer still
expect flat UUID lists and issue objects; update
apps/api/plane/api/serializers/issue.py to document the new shape (replace the
ListField(UUIDField()) relation fields with a ListField of a dict/nested
serializer containing "project_id" and "issue_id") so the OpenAPI contract
matches list_work_item_relations, and update the consumer in
apps/web/core/store/issue/issue-details/relation.store.ts (the code that
currently iterates and calls addIssue(item) around lines 115-133) to either
extract and pass the correct issue id (item.issue_id) to addIssue or adapt
addIssue to accept the {project_id, issue_id} ref; make the serializer and the
web store consistent with list_work_item_relations across all relation fields
(blocking, blocked_by, duplicate, relates_to, start_after, start_before,
finish_after, finish_before).

🪄 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: 6bf17114-9b1c-4ece-bb20-9e3d7d964eb0

📥 Commits

Reviewing files that changed from the base of the PR and between bb128e3 and 7645c59.

📒 Files selected for processing (1)

• apps/api/plane/api/views/issue.py

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Propagate this response-shape change end-to-end.

list_work_item_relations now returns relation refs ({project_id, issue_id}), but apps/api/plane/api/serializers/issue.py still documents these fields as ListField(UUIDField()), and apps/web/core/store/issue/issue-details/relation.store.ts:115-133 still consumes issue.id and passes each item into addIssue(). As-is, this ships the wrong OpenAPI contract and will break the current relations UI unless the web consumer/service is updated in the same PR or the old id-based shape is preserved.

Also applies to: 2337-2413

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/api/plane/api/views/issue.py` around lines 2291 - 2323, The API changed:
list_work_item_relations now returns relation refs ({project_id, issue_id}) but
the serializer and web consumer still expect flat UUID lists and issue objects;
update apps/api/plane/api/serializers/issue.py to document the new shape
(replace the ListField(UUIDField()) relation fields with a ListField of a
dict/nested serializer containing "project_id" and "issue_id") so the OpenAPI
contract matches list_work_item_relations, and update the consumer in
apps/web/core/store/issue/issue-details/relation.store.ts (the code that
currently iterates and calls addIssue(item) around lines 115-133) to either
extract and pass the correct issue id (item.issue_id) to addIssue or adapt
addIssue to accept the {project_id, issue_id} ref; make the serializer and the
web store consistent with list_work_item_relations across all relation fields
(blocking, blocked_by, duplicate, relates_to, start_after, start_before,
finish_after, finish_before).