Tickets (vendor ↔ admin)

Summary

Vendors open tickets in vendor web at /dashboard/support. Messages on a ticket form a thread: replies show an author kind (admin, vendor, vendor_employee, or retail user) plus a display name, matching how each message is stored (user_type + user_id on the comment row).

Where to use it

• Vendor: Dashboard → Support (sidebar under Organization). List, filter, create a ticket, open a ticket to read the description and discussion, and post replies. The ticket detail dialog loads the thread with limit = 5 per page (no in-list scroll), TablePaginationBar for pagination (same pattern as other dashboard tables). While comments load the first time, skeleton rows keep the modal height stable; when changing pages or refetching after a reply, the previous messages stay visible with a light loading overlay instead of flashing back to skeletons. A slim progress bar at the top of the thread indicates send in progress.
• Admin: Tickets at /dashboard/support-tickets — List view uses status tabs + table pagination; Kanban always shows all status columns (no status-tab filter on the board; vendor/store filters use shared FormSelectField). Each column has a capped height with an internal scroll, loads the first batch from GET /admin/support-tickets with status + pagination, then Load more fetches the next page for that column only. Detail at /dashboard/support-tickets/:id matches vendor discussion UX: SupportDiscussionThreadChrome, skeleton / overlay / pending bar, placeholderData, limit = 5, TablePaginationBar with from–to / total; header shows status / priority from the ticket API plus assignee.

API (vendor JWT)

All routes require Authorization: Bearer (vendor auth). Base path: /vendor/support-tickets.

Method	Path	Purpose
GET	/vendor/support-tickets	Paginated list (page, limit, optional status, priority, category, store_id, search).
POST	/vendor/support-tickets	Create ticket (subject, description, optional priority, category, store_id must belong to vendor).
GET	/vendor/support-tickets/:id	Ticket detail (vendor-scoped).
GET	/vendor/support-tickets/:id/comments	Paginated thread: query page (default 1), limit (default 10, max 100). Comments are newest first. Response shape { data, meta: { total, page, limit, total_pages } }.
POST	/vendor/support-tickets/:id/comments	Post reply (body).

Admin API parity

Admin GET /admin/support-tickets/:id/comments uses the same query parameters and { data, meta } response shape as the vendor comments endpoint (newest first, server-side pagination).

Access control

• vendor-module-access: the /dashboard/support route is registered so owners and employees can open it (same pattern as notifications when the product wants broad access).
• Data scope: list and detail only return tickets for the authenticated vendor_id. Optional store_id filter must reference a store owned by that vendor.

Operational notes

• Requires database mode (DB_ENABLED / configured TypeORM repositories). If repositories are not wired, the API responds with 503 and a clear error code.
• Ticket status values follow the shared support-ticket enum (e.g. open, in_progress, waiting, resolved, closed); vendors create tickets in open state.

Related

• Vendor panel overview — routing, ROUTE_RULES, and dashboard shell.
• Notifications & help settings — in-app notifications (separate from support threads).