AzuTear
94 lines
2.4 KiB
Markdown
94 lines
2.4 KiB
Markdown
# Feature: Request Assignment
|
|
|
|
## Objective
|
|
|
|
Allow agents and managers to assign an open support request to an active agent.
|
|
|
|
## User Or System Value
|
|
|
|
Support teams can see clear ownership for every active request and reduce
|
|
duplicate work.
|
|
|
|
## Requirements
|
|
|
|
- Agents can assign unowned requests to themselves.
|
|
- Managers can assign requests to any active agent.
|
|
- Assignment creates an audit event.
|
|
- Closed requests cannot be reassigned.
|
|
|
|
## Non-Goals
|
|
|
|
- Automated assignment rules.
|
|
- Workload balancing.
|
|
- External notifications beyond a basic assignment event.
|
|
|
|
## Acceptance Criteria
|
|
|
|
- [ ] An agent can assign an unowned open request to themselves.
|
|
- [ ] A manager can assign an open request to another active agent.
|
|
- [ ] A non-manager cannot assign a request to another user.
|
|
- [ ] Closed requests return a domain error when assignment is attempted.
|
|
- [ ] Every successful assignment writes an audit event.
|
|
|
|
## Architecture Notes
|
|
|
|
- Affected modules: Requests, Users.
|
|
- Dependency concerns: Requests queries Users through a user lookup interface.
|
|
- Data ownership: Requests owns assignments and audit events.
|
|
- Related ADRs: ADR-001, ADR-003.
|
|
|
|
## API Or Interface Changes
|
|
|
|
```http
|
|
POST /api/requests/{requestId}/assignment
|
|
Content-Type: application/json
|
|
|
|
{
|
|
"assigneeUserId": "usr_123"
|
|
}
|
|
```
|
|
|
|
Successful response:
|
|
|
|
```json
|
|
{
|
|
"requestId": "req_456",
|
|
"assigneeUserId": "usr_123",
|
|
"status": "open"
|
|
}
|
|
```
|
|
|
|
## Data Changes
|
|
|
|
- Add `assigned_to_user_id` to requests if not already present.
|
|
- Add `RequestAssigned` audit event type.
|
|
- Index active requests by assigned user for queue views.
|
|
|
|
## Security And Authorization
|
|
|
|
- Authenticated agents can assign requests to themselves.
|
|
- Managers can assign requests to any active agent.
|
|
- Backend policies enforce assignment permissions.
|
|
- Frontend controls are not considered a security boundary.
|
|
|
|
## Testing Plan
|
|
|
|
- Unit: request assignment state transitions and closed-request rejection.
|
|
- Integration: authorization cases and audit event persistence.
|
|
- End-to-end: create request, assign, and confirm queue ownership changes.
|
|
- Manual: verify manager and agent UI states.
|
|
|
|
## Rollout Plan
|
|
|
|
Deploy backend and frontend together. Run a smoke test that assigns a staging
|
|
request as an agent and as a manager.
|
|
|
|
## Risks
|
|
|
|
- Authorization drift between UI and API.
|
|
- Assignment race when two users assign the same request at the same time.
|
|
|
|
## Open Questions
|
|
|
|
- Should assignment notify the assignee immediately in the first release?
|