Extends the existing PATCH /admin/agents/:agentId with an optional userId to finish wiring 010's Agent.userId link, and adds GET /agents/me/tickets + GET /admin/agents/:agentId/tickets sharing one ticketing/tickets service method, backed by a new Assignment @@index([agentId, isCurrent]). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
1.8 KiB
1.8 KiB
Quickstart: Validating Agent Ticket Queue
Prerequisites: 010-identity-auth's login working; an existing Team/Agent/User (role
AGENT) to link.
Scenario 1 — linking (User Story 1)
PATCH /admin/agents/:agentIdwith{ "userId": "<agent's User.id>" }as an admin. Expected:200, response'suserIdmatches.- Repeat with a
userIdbelonging to aUserwhose role isADMIN. Expected:400. - Repeat step 1's
userIdagainst a differentagentId. Expected:409.
Scenario 2 — an agent lists their own tickets (User Story 2)
- With two tickets currently assigned to the linked agent (via the existing orchestration
assignment flow) and one assigned to a different agent, log in as that agent and call
GET /agents/me/tickets. Expected:200, exactly the two tickets, each withproduct/customer/priority/severity/status/assignedAt/slapopulated. - Reassign one of those two tickets away (to a different agent or node). Expected: calling
GET /agents/me/ticketsagain returns only the one remaining ticket. - Log in as a
User(roleAGENT) with no linkedAgentrow and call the same endpoint. Expected:404with the specific "no agent profile linked" message, not[].
Scenario 3 — an admin lists a specific agent's tickets
- Log in as admin; call
GET /admin/agents/:agentId/ticketsfor the agent from Scenario 2. Expected:200, same ticket set and shape as that agent's ownGET /agents/me/ticketscall. - Log in as a non-admin agent; call the same admin route for another agent's
agentId. Expected:403.
What "done" looks like
All three scenarios pass, and Scenario 2 step 2 specifically confirms the list reflects live assignment state rather than a snapshot from when the agent first logged in.