[feature]: Expose comment count on work-item lists without fetching comment bodies #10104

Is there an existing issue for this?

• I have searched the existing issues

Summary

Please expose lightweight comment metadata on work-item list responses, ideally an optional comment_count field (or at least has_comments), without embedding comment bodies.

The use case is a dashboard listing work items across cycles and projects. Each row should show a comment icon/count only when comments exist. The actual discussion is fetched from the existing per-work-item comments endpoint only when the user clicks the icon.

In the current v2 documentation, neither the project nor workspace work-item list exposes comment count/presence among its requestable fields, and comments is not an allowed expansion:

• List work items
• List work items across a workspace
• Expanding relations

We also checked the v1 issues list on Plane Cloud: requesting candidate count/presence fields or expand=comments does not add this information to the response.

A proposed response could include:

{
  "id": "<work-item-id>",
  "name": "Example work item",
  "comment_count": 3
}

Ideally this would be available on both project and workspace work-item lists, optionally requested so integrations that do not need it incur no additional cost. The count should follow the requesting token's comment visibility permissions; its treatment of hidden comments and replies should be documented.

Alternatively, a batch endpoint returning only work-item IDs and comment counts would address the same need.

If an existing supported parameter or endpoint already provides this, please point us to it.

Why should this be worked on?

Without this metadata, displaying comment badges requires one additional comments request per work item, even though the discussion itself may never be opened. A list of 50 items can therefore require 50 extra requests just to discover which items have comments.

Requesting only one comment and minimal fields reduces payload size but does not remove the N+1 request pattern. In our integration, these requests compete with cycle/item loading and can trigger HTTP 429 responses.

Caching helps repeated reads, and webhook-based synchronization is another workaround, but maintaining a separate comment-count store and initial synchronization is substantial overhead for a basic list indicator.

A count/presence field or batch counts endpoint would let integrations render the list with a small number of requests and fetch comment content strictly on demand. This is a REST API capability request, independent of the Python SDK.