Skip to main content

Tickets in management view

This page explains how staff use the ticket queue in the admin area.

Navigation path:

  • Server Admin -> Tickets

For the shared lifecycle and Discord behavior behind the queue, see Tickets concept.

Access requirementsโ€‹

  • tickets.admin_view for read-only access to the queue and ticket detail
  • tickets.reply to create staff tickets, send public replies, pin messages, and upload evidence files
  • tickets.internal_message to add internal notes
  • tickets.assign to assign tickets, manage participants, and edit the subject
  • tickets.change_status to change the ticket status manually
  • tickets.add_participant to add participants directly from the Discord ticket channel using the user-select
  • logs.view to access the Investigation tab and re-run saved log queries from the Review tab
  • restrictions.view to view linked restrictions on the Review tab
  • restrictions.create to create new restrictions directly from a ticket

Compatibility note: Existing support groups that already have tickets.reply, tickets.internal_message, tickets.assign, or tickets.change_status can still open the queue even without tickets.admin_view. For new role setups, grant tickets.admin_view explicitly if the role needs read-only access.

Attention badgesโ€‹

Every ticket row in the queue displays a badge indicating who should respond next:

  • Needs Attention (red) โ€” the last public message is from a player; support has not yet replied
  • Waiting for Response (grey) โ€” the last public message is from support; the player has not yet replied

Use the Needs Attention badge to quickly spot tickets that are waiting for a staff response.

Queue overviewโ€‹

The queue supports these filters:

  • status tabs
  • unassigned tickets
  • tickets assigned to the current staff member
  • participant search
  • assignee search

Use these filters to split first-response work, assigned follow-up work, and player-specific investigations.

Participant and assignee search each use the player lookup. Start typing at least two characters to narrow the queue to a specific player.

Creating a staff ticketโ€‹

If tickets.reply is granted, staff can create a ticket directly from the queue.

This is useful for:

  • internal support follow-up
  • staff-initiated outreach
  • moving Discord-side support into a tracked ticket flow

Staff-created tickets start without a player participant until one is added.

Ticket detailโ€‹

The detail page is organized into three tabs: Conversation, Investigation, and Review.

The Conversation and Review tabs are always visible. The Investigation tab is only shown for active tickets (Open or In Progress) and requires logs.view.

Conversation tabโ€‹

The Conversation tab contains the full message thread and the core ticket operations:

  • public replies for player-visible communication
  • internal notes for staff-only context
  • assignment and unassignment
  • participant management
  • subject editing
  • status changes
  • manual response-waiting state

Important behavior:

  • the first public support reply auto-assigns an unassigned ticket to that staff member
  • adding a faction includes all current faction members as participants
  • internal notes stay private in dzbot and do not expose their content to players
  • each message can be pinned using the pin icon; pinned messages appear on the Review tab for quick reference during case review

Response-waiting state

Staff can manually set the response-waiting state on active tickets without sending a message:

  • Waiting for Support โ€” marks the ticket as needing a staff response
  • Waiting for Player โ€” marks the ticket as waiting on the player

This controls the same field that updates automatically when a public message is sent. Use the manual toggle when working on a ticket internally without yet sending a public reply, so the queue badges stay accurate.

Requires tickets.reply.

Investigation tabโ€‹

Requires logs.view. Only visible on active tickets (Open or In Progress).

Embeds the log explorer directly in the ticket, so staff can research in-game events without leaving the page:

  • filter logs by event type, player, coordinates, and time range
  • save the current filter configuration as a named query attached to the ticket
  • pin individual log events with an optional annotation note

Saved queries and pinned events are stored against the ticket and remain accessible on the Review tab to staff who do not have logs.view. Only running new queries or pinning new events requires the right.

Review tabโ€‹

Always visible. Collects all evidence and outcomes accumulated for a ticket.

Linked restrictions โ€” requires restrictions.view. Shows all restrictions linked to this ticket. Staff with restrictions.create can open the New restriction menu to create an event or system restriction directly from the ticket. New restrictions open in a side drawer and are automatically linked.

Evidence files โ€” files attached to the ticket (images, PDF, video). Staff with tickets.reply can upload additional files using Upload evidence file. Attachments added inline during a reply also appear here.

Saved queries โ€” filter configurations saved from the Investigation tab. Each can be re-run (requires logs.view) to fetch fresh results in a modal. Queries can be deleted when no longer needed.

Pinned events โ€” log events pinned during investigation, displayed with any annotation added at pin time. Events can be unpinned directly from this tab.

Pinned messages โ€” conversation messages marked with the pin icon on the Conversation tab. Messages can be unpinned from here.