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​

  • admin.tickets.view for read-only access to the queue and ticket detail
  • admin.tickets.reply to create staff tickets, send public replies, pin messages, and upload evidence files
  • admin.tickets.internal_message to add internal notes
  • admin.tickets.assign to assign tickets, manage participants, and edit the subject
  • admin.tickets.change_status to change the ticket status manually
  • admin.tickets.add_participant to add participants directly from the Discord ticket channel using the user-select
  • admin.tickets.change_level to move a ticket to another support level
  • admin.tickets.manage_levels to open Tickets -> Levels and manage the levels themselves
  • admin.tickets.manage_categories to open Tickets -> Categories and manage the request types and their Discord panels
  • admin.tickets.level_<id> for each support level whose tickets the role should see
  • 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 admin.tickets.reply, admin.tickets.internal_message, admin.tickets.assign, or admin.tickets.change_status can still open the queue even without admin.tickets.view. For new role setups, grant admin.tickets.view explicitly if the role needs read-only access.

Support levels​

The badge and the filter only appear on servers that actually use more than one level — a single-level server sees no trace of the concept. The Levels button is the exception: it is shown to holders of admin.tickets.manage_levels regardless, because it is the only place a second level can be created.

On a multi-level server the queue gains:

  • a level badge on every ticket row, hidden again while a level filter is active (it would repeat the filter on every row)
  • a level chain next to the search box for picking the level to show
  • a warning banner when you hold ticket rights but no level right at all — an explicit "you are missing a level right" instead of a silently empty queue

Changing a ticket's level​

Change level on the ticket detail page opens a dialog with the target level (defaulting to the next one up) and a mandatory reason. Escalating above your own level is allowed: the dialog warns you that the ticket will disappear from your view, and the app returns you to the queue after saving.

The reason lands as an internal note naming both levels and you, the assignee is cleared so the ticket surfaces as unhandled in the receiving queue, and status and attention state stay untouched.

The same action is available from the pinned Discord ticket header.

Locked tickets​

A ticket in a level you do not hold stays visible as a reference in notes, restrictions and the player dossier: the link and the ticket number remain, marked with a lock, but the subject and status are withheld — paired with a ticket id they would otherwise turn any note into an existence-and-status oracle for the queue the levels are closing off. Opening the reference names the level instead of showing a generic access error. Such a reference also cannot be created or removed by someone who may not see the ticket.

Managing levels​

The Levels button opens a drawer over the queue — the list behind it keeps its filters and does not reload. It lists every level in order and lets you:

  • create a level (appended at the end), rename it, and reorder it
  • see how many tickets it holds and how many groups and players hold its right
  • see the state of its Discord category and role, with a Recreate action when either is missing
  • delete it, which asks for a target level when the level still holds tickets

Two rules to know:

  • Level 1 cannot be deleted — every new ticket starts there.
  • A new level is granted to nobody. Its tickets are invisible until you hand the right out, and the row warns you while that is the case with a link to the group rights editor. dzbot never writes rights on someone's behalf. Groups with an admin.* wildcard are covered automatically.

Reordering only changes the display position; the rights hang off the level's id, so no permission is reassigned. Reordering and dissolving a level do change what an existing right sees, though — visibility resolves cumulatively through the position — so both require access to every level, not just admin.tickets.manage_levels.

Attention badges​

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

  • Needs attention (amber pill) — the last public message is from a player; support has not yet replied
  • Waiting for response (hourglass, row dimmed) — the last public message is from support; the player has not yet replied

Rows are sorted by urgency by default, so the tickets waiting on staff sit at the top. The sort control next to the filters offers the other orders, and the filters for participant, assignee and state live in the filter menu beside it; whatever is active is repeated as a removable chip above the list. Each row also carries an age mark: how long the ticket has existed, and how long it has been waiting in its current state.

Request types​

Tickets -> Categories opens the request-type editor. A request type is what a player picks before the form appears; the form is what turns "hi I have a problem" into a complete report. For the mechanics behind templates, panels and the answer snapshot, see Tickets concept.

Your server already has one type named General, asking for a subject and a message. Existing servers were migrated with it and every new server starts with it, so the shop can take a ticket before anyone opens this editor — its form and templates reproduce exactly what opening a ticket looked like before request types existed. It is an ordinary type in every other respect: rename it, rebuild its form, or add types beside it.

The list​

Each row shows the type's name, how many fields its form has, how many tickets already use it, and which channels its panels are published in. Drag a row to reorder; the order is what players see in the shop.

The Active / Inactive toggle is the only visibility control. Discord already gates by channel permissions, and a second gate would only become the second truth. Deactivating a type hides it from the shop and takes all of its Discord panels down; the type's existing tickets are untouched.

The last remaining type cannot be deleted — the shop would have no way to open a ticket at all. Deactivating all of them is possible, and the shop then says so explicitly instead of falling back to a generic form.

The editor​

  • Name and description are per-language. The description is the thing that makes a player pick the right type, so it is worth writing: it appears on every Discord panel of the type and on the card in the shop.
  • Welcome message is posted into the ticket as the opening staff message, before the player's own first message. Leave it empty for none. This replaces the former server-wide Ticket Welcome Message setting, which no longer exists.
  • Support level routes tickets of this type straight to a team instead of the entry queue.
  • Form: up to five fields, each with a type, a stable key, a required flag, per-language label, hint and placeholder, and type-specific settings (length limits, file counts, choice options). Drag to reorder.
  • Templates: the generated subject and first message, with a cheat sheet of the placeholders available for this type's fields.
  • Panels: a per-language readiness list, the channels the type is already published in, and a picker to publish it into another one.

The field key is what {field:…} in the templates and the Discord component refer to. It is derived from the English label while the field is new, and becomes read-only once tickets reference the type — renaming it then would silently detach both the template and the recorded answers.

Publishing panels​

A type can be published once it has at least one field and at least one complete language. The readiness list names what is missing per language, so "why is there no German button" is answerable without guessing.

The panel is written in the server's language first: title, description and the leftmost button follow the language set under Settings, and the other complete languages come after it, each behind a heading in its own language.

A type can carry one panel per channel, as many channels as you need — a support channel for registered players and one for guests both get their own button, and both open the same form. Publishing into a channel that already has a panel replaces that one message; the panels in the other channels stay where they are. To move a panel, publish it into the new channel and remove the old one from the list.

Saving the type edits every one of its panels in place. Two limits worth knowing:

  • Discord cannot move a message, so reordering the list does not reorder the panels in the channel. Rebuild panels deletes every panel in one channel and reposts them in the current order — at the bottom of the channel. It asks for confirmation and says exactly that.
  • Rebuilding is scoped to one channel. A type's panels in other channels keep their place, because reposting them would move them to the bottom of a channel nobody asked about.

If the bot lacks permission in the chosen channel, publishing fails with a warning and nothing else breaks — ticket creation does not depend on panels. A save that cannot update one channel's panel still updates the rest, so a single misconfigured channel never freezes the others on an outdated form.

Queue overview​

The queue supports these filters:

  • status tabs
  • unassigned tickets
  • tickets assigned to the current staff member
  • participant search
  • assignee search
  • request type, including a No type option for staff-created, AI-created and pre-feature tickets

The request-type filter and the per-row type badge only appear once the server has more than one type — with a single type they would say nothing.

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 admin.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​

When the ticket came in through a request-type form, an intake card sits directly above the message thread, showing every field that was asked and what the player entered — including the fields left empty, greyed out as a dash. The card is deliberately redundant with the ticket's first message: that message follows an admin-authored template that may reorder, reword or omit fields, while the card is the raw intake.

The card is read-only in this version — a ticket's request type and its recorded answers cannot be changed anywhere — and admin-only; the player already sees their own answers as the opening message. Staff-created, AI-created and pre-feature tickets show no card at all.

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 admin.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 admin.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.