Summary
A work item's milestone is not returned by the Work Items API. cycle_id is returned, but there is no equivalent milestone field on any work-item endpoint, and no expand value produces one. The only way to learn which milestone a work item belongs to is to list every milestone in the project and then list each one's work items, building the reverse mapping yourself.
Steps to reproduce
Take a work item that is on a milestone (confirmed via GET /milestones/{milestone_id}/work-items/, which does return it), then:
GET /api/v1/workspaces/{slug}/projects/{project_id}/work-items/{id}/
GET /api/v1/workspaces/{slug}/projects/{project_id}/work-items/{id}/?expand=state,milestone,milestones
GET /api/v1/workspaces/{slug}/projects/{project_id}/work-items/{id}/properties/
None of the three responses contains any key matching milestone. The same response does contain cycle_id.
Expected
A milestone_id on the work item, alongside cycle_id, and ideally an ?expand=milestone giving the milestone object (title and target_date).
Why it matters
We sync Plane work items into our own support portal and show clients the release date their fix is scheduled for. That date lives on the milestone. Because the API will not tell us which milestone a work item is on, we cannot read it at all on demand, and we cannot backfill existing tickets without walking every milestone in the project and inverting the relationship.
We currently get the milestone only because the v2 webhook happens to carry it on a milestone_issue event. That means the value is only ever knowable at the moment it changes. Anything that missed the webhook, or predates it, is unrecoverable through normal means.
Related
This is the same shape of problem as a few other reports: data that exists in the product but is either absent from the work-item response or shaped differently depending on which endpoint you ask.
Summary
A work item's milestone is not returned by the Work Items API.
cycle_idis returned, but there is no equivalent milestone field on any work-item endpoint, and noexpandvalue produces one. The only way to learn which milestone a work item belongs to is to list every milestone in the project and then list each one's work items, building the reverse mapping yourself.Steps to reproduce
Take a work item that is on a milestone (confirmed via
GET /milestones/{milestone_id}/work-items/, which does return it), then:None of the three responses contains any key matching
milestone. The same response does containcycle_id.Expected
A
milestone_idon the work item, alongsidecycle_id, and ideally an?expand=milestonegiving the milestone object (title andtarget_date).Why it matters
We sync Plane work items into our own support portal and show clients the release date their fix is scheduled for. That date lives on the milestone. Because the API will not tell us which milestone a work item is on, we cannot read it at all on demand, and we cannot backfill existing tickets without walking every milestone in the project and inverting the relationship.
We currently get the milestone only because the v2 webhook happens to carry it on a
milestone_issueevent. That means the value is only ever knowable at the moment it changes. Anything that missed the webhook, or predates it, is unrecoverable through normal means.Related
This is the same shape of problem as a few other reports: data that exists in the product but is either absent from the work-item response or shaped differently depending on which endpoint you ask.
stateUUID despite?expand=state#9534?expand=statereturning a bare UUIDlabelsas UUIDs in list responses but as objects in single-item responses #9594labelsas UUIDs in list responses but objects in single-item responses