Add admin_assignee_id and team_assignee_id to conversation part and ticket part schemas - #635
Conversation
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
0 only appears when the part named which assignee it cleared; an unassignment that named neither returns null on both. Also documents that a bot is reported in admin_assignee_id. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
dan0505
changed the title
Every other scalar property on the part schemas carries an example, and the endpoint response examples are what a reader checks the shape against, so the new fields need both. The assignment parts show the two shapes worth seeing: the conversation part is the Round Robin case with a teammate and a team set at once, the ticket part a plain teammate assignment. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Is this correct? Don't we also return team as assigned_to if there's no teammate assigned to it? Can be fixed as follow up since it's existing bug.
There was a problem hiding this comment.
You're right. assigned_to reports whatever the part actually assigned, so a part that assigns a team returns {"type": "team", "id": "..."} and one that assigns a bot returns {"type": "bot", "id": "..."} — neither is an admin, and the current sentence describes only the admin case.
Two more gaps in the same sentence while we're here:
- it's a reference object with
typeandid, not a scalar id; and - an unassignment returns
{"type": "nobody_admin", "id": null}, notnull.nullmeans the part changed no assignment at all.
Agreed this is pre-existing and out of scope for this PR, so I've filed a follow-up rather than widening it. Worth flagging that the sentence is duplicated per version rather than shared, so it reads wrong on every published version too, not just Preview — the follow-up covers the scope question of whether to correct released versions or Preview only.
The two fields added in this PR are unaffected.
2 participants
Why?
A conversation part records a single assignee, so when a part assigns a conversation to both a team and a teammate at once, only the teammate was reported and the team the conversation went to was not visible on the API. Two new Preview fields report each assignee separately; this documents them.
How?
Adds
admin_assignee_idandteam_assignee_idto the Previewconversation_partandticket_partresponse schemas, describing when each is set, cleared, or absent.