Tickets Plugin 🎟



This plugin adds a ticketing system to Discourse. It requires tagging to be enabled and works best alongside the Assign Plugin.

It is based on @tobiaseigen’s original spec, and has been built in collaboration with @tobiaseigen and an awesome Ruby for Good team, for the benefit of both Namati and the Discourse community.


  • When you install the plugin, three new tag groups are added tickets_priority, tickets_reason and tickets_status. Add tags to these groups (at /tag_groups) to add tickets to each ticket type.

  • Tickets are added in the ‘edit topic’ UI (see screenshot below).

  • You can create topics or PMs with tickets via the api using is_ticket and a tags[] for each ticket tag (learn more)

  • There are four site settings you need to look at. To access quickly, go to ADMIN > SETTINGS on your instance and search for tickets.

    • tickets enabled: Enable tickets on topics (requires tagging to be enabled).

    • tickets icon: set the font-awesome class of the tickets icon

    • tickets include group: default group to include on private messages with tickets (on Global Legal Empowerment Network forum this is a helpdesk group).

    • tickets redirect assigned: redirects the user from the ‘assigned topics’ route in their profile to Tickets dashboard filtered by tickets assigned to them.

Tickets Dashboard


Topic List

Tasks list

This list pulls together bug reports and feature requests that have come up in this discussion below and in the active usage of this plugin by @tobiaseigen and colleagues on the Global Legal Empowerment Network. @angus has agreed to schedule some time regularly to try to chip away at this list via, but can always use help! :seedling:


  1. Hijacked link to a user’s assigned tickets appears to not work for usernames that have mixed case.
  2. Ticket tags showing up in print view, also for those without access to ticket system

Features we’d like to add:

  1. Add ability to indicate the user (or users) a ticket is about.
  2. Add columns on tickets dashboard for date ticket was created and date created, date of last activity.
  3. Hijack :mag: search on tickets dashboard to allow searching for tickets by keyword
  4. Revamp tickets dashboard filtering/sorting/pagination
  5. Add to tickets dashboard default filters and options to quickly see only tickets assigned to me or only open tickets
  6. Add ability to monitor overall health of ticket system (time to resolution, open tickets, etc)
  7. (low priority) Add “Settings” button in /admin/plugins (details)
  8. (low priority) Allow ticket system and ticket tag groups to be renamed (requested by @GeertClaes)

Requested features that are low priority/hard/likely not to be added:

  • add TICKET options to topic menu at bottom as well as topic title edit.
  • notify user of number of open tickets assigned to user every time they log in
  • automated system messages are always tickets marked low, waiting
  • ticket PMs are sent to group messages archive by default so they don’t clutter group messages inbox
  • typically when we create a ticket, we set the status tag to #waiting. If there were some way to change this status to #underway when someone replies, that would be a big help… if not, we can rely on the ticket dashboard if it shows activity so we know someone has replied and we need to take action.
  • for sake of transparency, would be interesting to indicate in a whisper when ticket tags are added or changed, following the example of the assign behavior.
  • on the flag interface it’s possible for moderators to “claim” spam posts. Maybe this is a model we can follow for tickets? This would speed things up - right now the flow is to unassign then assign.

Other discourse functionality that would help

  • bulk select and update ticket priority, status, reason, group, assignee (if not on the UI, then command line queries?)

I take it this is still missing the bit that lets one turn something into a ticket?

should I create the different tags myself or should the ticket system do that (I mean the actual tags here, not the tags on a topic)?

Any way to make new posts in a specific group as tickets?

We’re been using Discourse for support for a file but were missing something like this, where we can properly see and maintain the status of tickets/support items.


Thanks for trying it out :slight_smile:

You can add a ticket to a topic in the topic edit area, the same place you edit the topic title and tags. Make sure the “tickets enabled” setting is on.

Could you elaborate on this? Do you mean all topics in a category? Or all private messages involving a group?

I need to create the tag types as specified here? Using discourse as ticket system, so no balls are dropped 🤹‍♀️
#ticket #status-new #status-resolved #priority- * etc first?

Basically if something comes in via the support or sales groups, I want it to be a ticket from the start.

Give that a whirl.

How are they coming in? People send a message, or is it created via the api? If folks are sending messages, there’s no way of doing this currently, but if it’s via the api, yes you can add a ticket directly.

Ah yes. Having a few status, reason and priorities now I can make something into a ticket.

ah oke. Yes mail in via support@ and sales@

Awesome! So glad to see this ticket plugin become a reality. Angus has done some terrific work here, and has been very patient with my feature requests and feedback. He deserves a medal. :1st_place_medal:

I hope more communities decide to use this plugin, and help to make it even better by contributing use cases, feedback and code. I am also hoping to see some improvements to other discourse features to make tickets even more awesome.

We’ve been using it on our site for a few weeks already and it works well, though I have yet to properly roll it out to my team. As that happens I’ll be able to give more feedback on what’s working and what needs improvements from our point of view.

For right now, here’s my wish list:

  • improved functionality on topic and message lists for selecting and bulk updating, to e.g. change category, add/remove tags, create ticket, mark solved, open/close, reassign, change priority, change status, etc. (discussed elsewhere)
  • solved plugin: Allow staff to select OP to be solution, if no replies.
  • solved plugin: Prevent staff from selecting whispered replies as solution, as risks exposing private conversation. (discussed elsewhere)
  • “ticket system heath” statistics, e.g. number of tickets by status, time to completion, ratio of tickets by status, charts showing above over time. Not sure where this should live - is the dashboard extendable through plugins?
  • automatic ticket updates when reply is sent (e.g. change status tag to waiting/underway, add reminder for assignee with interval based on priority, etc)
  • automatic assignee based on ticket reason
  • automatic tickets based on group or group email
  • automatic solved/unsolved based on ticket status
  • default filters and options on dashboard to more quickly see only tickets assigned to me, or only open tickets etc.
  • not directly related but a common ticket task for our helpdesk: UI method for merging users, with ability to choose which email address is primary and which is secondary. (discussed elsewhere)

In case you’re wondering, here are some notes on the api method we use for creating tickets. We use it to create a new ticket for each new member as they join, for the purposes of onboarding and welcoming them, and when reaching out to members for feedback when they download resources from our resource library. We also use it when inviting lists of people (e.g. event attendees) to join the network, instead of email.

  • is_ticket = 1
  • tags[] = tag1 each on a separate line, use ticket tags and any additional tags to help find messages later (note square brackets - required!)
  • target_usernames = should always contain helpdesk group accessible to the staff in charge of ticket follow-up. Can contain an email address instead of username to create staged users (handy for sending bulk invites and making them tickets for follow-up)

Agreed I should have started with that :slight_smile: This looks very promising, and your wish list contains several things that I’d probably get to if we get to use this properly here


I am super excited to see this. I currently have my own custom made (mock) ticketing system. It basically converts any PM into a ticket upon user request, adds a ticket number, organizes all tickets under a custom appointed user (@TICKETS) for easier tracking, and notifies admins. We do tagging/assign via discourse options. But this is more elaborate, if you keep developing this I will jump in and try it out :smiley:

1 Like

Interesting! It sounds like you’ve got a “support” use case there, letting a user create a ticket. This system was designed more for internal use for managing tasks and assignments. @tobiaseigen What do you think about allowing users to create tickets?

1 Like

Our site is a marketplace. Tickets are used between users for managing transactions. Basically, user A strikes a deal with user B via PM. When ready, they click a button converting the PM into a ticket. The PM is assigned a ticket number, and admins are notified. The first one to assign it to him self gets it and manages the transaction.


Do you mean allow users to see and use the tickets interface and see ticket tags on tickets? And see the tickets dashboard?

I can see a use case for it, and also can see it maybe being useful in our community. Assigned and solved is already visible to users. Letting them see the ticket details about their tickets is potentially interesting. But I don’t see the need to let them change ticket tags.

If you just mean letting users create tickets but then not see the ticket interface, ticket tags and ticket dashboard, maybe there is a use case for this too. The API can already make tickets while adding messages, so an external form could do it. Maybe a new group setting could enable auto tickets with default ticket status, priority and reason. E.g. include @tickets and the message is made into a ticket.


No. The tickets are basically PM’s with an edited title (the includes the ticket number). The tickets are accessible from users inbox.

Interesting. Can you share a screenshot of what your tickets look like? Generally, if you have screenshots that illustrate what you are doing I think that would help us to understand your need better and if/how it fits in with this plugin.

Ticket number: I guess the ticket number could just be the topic ID. Displaying that would be easy, I suspect. I also agree displaying a ticket number would be helpful, as well as in any email notifications about the ticket in the subject line etc. The ability to search by ticket number on the tickets dashboard might also be helpful. But again this is for a different use case than yours… more of a helpdesk need for quickly finding a ticket, for example when talking on the phone with someone about their ticket.

This already works - messages that are tickets appear in user inboxes. They are identifiable with tags in the message list. So if users had access to tickets, they’d be able to see the ticket tags. They could also click through to the tickets dashboard, to see only their tickets, which I think would also be handy for them.

@angus I remember when we made a strategic decision to put tickets in the /admin/tickets route instead of /tickets. I guess if giving users access to tickets were to become a thing, we’d want to move it.

1 Like

Here are all tickets organized for staff under an account of our choosing, in this case, @CHECKOUT

Here is what the ticket looks like inside. Included in the screenshot it an automated message from @CHECKOUT to the users when they start a ticket.

1 Like

It’s kind of a crude system, but it works :smiley: However, once (if) traffic picks up we will need a more refined ticket system.

We’re talking reminders/performance reports/sorting/etc. Basically, the basics of a good ticketing system.

1 Like

Much of what you are describing is available through this plugin or could be. I think @angus would welcome your contributions to this plugin. I know one area we want to prioritize next is performance reports (I was calling it ticket system health) which is described above somewhere.

Another is functionality for bulk updating tickets from filtered lists. This is still fairly nascent in discourse. But as the number of tickets grows it will be needed.

1 Like

I mainly need this feature to award admins for their work, vs. using it to measure actual response times/etc. (although that is useful info, also). Our site pools all the income and splits the profit among admins. Obviously, who works more gets a bigger share.


Thanks to the great work of @mbcahyono we’ve upgraded our (mock) ticket plugin. It now features site-wide notifications for open tickets, and a dedicated ticket area for ticket holders.


Nice! I like the use of a notification about open tickets. Seems to me this should be a proper discourse notification though. Also, it would be handy to have a quick link to display only open tickets on the dashboard.