# Support module

## Agent flow

Authenticated agents can list their own tickets, create a ticket with its first message, read their own conversation, and reply while the ticket is not closed. Tickets are ordered by `updated_at DESC, id DESC`; conversation messages are ordered by `created_at ASC, id ASC`.

## Admin flow

Administrators can list every ticket, open its detail, reply, and set its status. The admin list supports server-side search by subject, agent name, agent email, and MTA number; category and status filters; 25-row pagination; and preserved filter query strings. Results are ordered by `updated_at DESC, id DESC`.

## Categories

The only supported categories are:

- `general`
- `membership`
- `lead_credit`
- `billing`
- `balance_inquiry`
- `technical_issue`
- `bug_report`
- `feature_request`

There is no `migration` category.

## Status machine

- An admin reply moves `open` or `in_review` tickets to `waiting_user`.
- An agent reply moves `waiting_user` tickets to `in_review`.
- An agent reply to `resolved` moves it to `in_review` and clears `resolved_at`.
- Admins may set `resolved` (setting `resolved_at`) or `closed` (setting `closed_at`). Moving away from `resolved` clears `resolved_at`.
- Closed tickets reject normal agent and admin replies.

## Authorization and privacy

Agents are scoped to their own tickets for listing, detail, and replies. Admin Support routes require admin middleware. Listing and detail props use curated ticket, safe agent identity, and message fields; they do not expose IC, credentials, E-Wallet or Lead Credit balances, Partner financial data, or payment/provider fields. The admin list eager-loads its safe agent identity fields to avoid an N+1 query.

Returning-agent onboarding may create one normal `balance_inquiry` ticket for a Membership Balance, Lead Credit Balance, or both. The ticket remains visible in normal Agent and Admin Support and uses the existing review/reply/status workflow. It does not perform an old-system lookup, automatic balance calculation, E-Wallet credit, or refund. Attachments and Support notifications remain deferred.

After manual review, an administrator may make one approved MYR Balance Inquiry refund per eligible ticket. The refund is credited only to the ticket owner's normal E-Wallet through its ledger, recorded in a durable audit row, and resolves the ticket with an agent-visible Support reply. It is not a direct Membership restoration or Lead Credit grant, and there is no Migration category, bulk refund, or old-system lookup.

Admin replies, resolved/closed transitions, and successful Balance Inquiry refunds create safe database notifications for the ticket owner. They appear in the existing agent bell and Notifications page and link to the ticket. Payloads contain only the event type, ticket identity/subject, short message, and ticket URL; email, push, SMS, attachments, SLA alerts, and an admin notification center are deferred.