Existing issue check: Searched open issues/discussions; didn't find this already requested — happy to close as a duplicate if one exists.
Summary
On self-hosted Plane (Community, v1.3.1), new comments and activity added to a work item by another actor — another user in a different session, or an integration posting via the REST API — do not appear on an already-open issue page until a manual reload (or until a window refocus triggers SWR revalidation).
The realtime live service (Hocuspocus/Yjs) currently powers collaborative editing of the description and Pages, but not the comments/activity feed, and the web client has no websocket/polling subscription for them.
Use case
We run an automated agent (a dedicated user-type account) that comments on and transitions work items via the REST API. Reviewers watching a ticket must reload the page to see the agent's responses and state changes, which breaks the human-in-the-loop flow. The same applies to any multi-user team where one person's comment should appear live for others viewing the work item.
Proposed solution
Broadcast comment/activity events to connected clients and apply them live — for example, extend the existing live server (or add a lightweight WS/SSE channel) to publish issue.comment.* / issue.activity.* events (the backend already emits issue activity via issue_activity), plus a client-side subscription that updates the comment/activity store. Scope could start with comments + activity on the work-item detail view.
Contribution
Per CONTRIBUTING ("if you would like to implement it, an issue with your proposal must be submitted first, to be sure that we can use it"), we'd like to implement this and submit a PR upstream, with unit tests as required. Before we invest, a few questions:
- Is real-time comment/activity push aligned with your architecture/roadmap, or intentionally out of scope for the Community edition?
- Is extending the
live server the direction you'd prefer, or is there an existing/planned mechanism we should build on instead?
- Any constraints we should follow (event schema, auth on the live channel, CE vs Cloud parity)?
Happy to adjust the approach based on your guidance. Thanks!
Version
v1.3.1, self-hosted (Community edition), Docker Compose.
Existing issue check: Searched open issues/discussions; didn't find this already requested — happy to close as a duplicate if one exists.
Summary
On self-hosted Plane (Community, v1.3.1), new comments and activity added to a work item by another actor — another user in a different session, or an integration posting via the REST API — do not appear on an already-open issue page until a manual reload (or until a window refocus triggers SWR revalidation).
The realtime
liveservice (Hocuspocus/Yjs) currently powers collaborative editing of the description and Pages, but not the comments/activity feed, and the web client has no websocket/polling subscription for them.Use case
We run an automated agent (a dedicated user-type account) that comments on and transitions work items via the REST API. Reviewers watching a ticket must reload the page to see the agent's responses and state changes, which breaks the human-in-the-loop flow. The same applies to any multi-user team where one person's comment should appear live for others viewing the work item.
Proposed solution
Broadcast comment/activity events to connected clients and apply them live — for example, extend the existing
liveserver (or add a lightweight WS/SSE channel) to publishissue.comment.*/issue.activity.*events (the backend already emits issue activity viaissue_activity), plus a client-side subscription that updates the comment/activity store. Scope could start with comments + activity on the work-item detail view.Contribution
Per CONTRIBUTING ("if you would like to implement it, an issue with your proposal must be submitted first, to be sure that we can use it"), we'd like to implement this and submit a PR upstream, with unit tests as required. Before we invest, a few questions:
liveserver the direction you'd prefer, or is there an existing/planned mechanism we should build on instead?Happy to adjust the approach based on your guidance. Thanks!
Version
v1.3.1, self-hosted (Community edition), Docker Compose.