Yes, this should definitely be on the agenda. It would increase the scope of the use cases substantially. @tobiaseigen Could you assimilate the various pieces of feedback into a prioritised to do list with max 3 items on it?
2 Likes
Hi Angus!
I may be right, but I donāt think thereās much new feedback from others here. @WorldIsMine has suggested creating āticket healthā functionality which would be very handy to have and we would definitely use it if it existsed, but there are more important tasks.
If I were you, Iād work on these three tasks next to make the ticket system more stable and usable.
- bug: The hijacked link to a userās assigned tickets appears to not work for usernames that have mixed case.
- add ability to indicate the user a ticket is about. Add column on tickets dashboard for date ticket was created and date created, date of last activity. (ok, I see I may have snuck in some separate tasks here - so sue me
) - hijack
search on tickets dashboard to allow searching for tickets by keyword
Note: @Kankuro had reported 1 above but I didnāt understand it previously. Now I was able to replicate it.
click for replicable steps on namati
Steps to replicate:go to your own messages, then click on ASSIGNED on the menu. You will see it works! 
go to Mohammedās messages, then click on ASSIGNED on the menu. It does not work! 
Note lower-case on URL:
https://community.namati.org/admin/tickets?filters=assigned%3Amohammedaman
click link to Mohammedās assigned tasks on the dashboard - it works! Note case on URL:
https://community.namati.org/admin/tickets?filters=assigned%3AMohammedAman
If you wanted to add a feature to allow non staff to create tickets, I think it would make sense to do it after the above is in place. It doesnāt seem as pressing to me because it is possible to do just this using an external form and the API. The only thing missing now is that users canāt see the ticket status, priority and reason, or assigned. But that is less important in my view.
I donāt know exactly how it might look but we should talk through it and solicit ideas. Maybe the easiest thing is to add a group setting to enable tickets for the group. Then when enabled, a TICKET button shows up on the user card pop up and group landing page. (A URL method for starting a ticket would be provided, like we have for starting a message, so on other parts of our site we could write something like āstart a ticket by clicking hereā or whatever.) When selected, an interface pops up that looks much like the current add ticket interface, already enabled and including the group and perhaps with some default ticket tags already prefilled. To see and manage their tickets, users could get a TICKETS menu option on their messages to access their own tickets? Or the dashboard could be moved to the /tickets route and only show people the tickets they have access to?
1 Like
Thanks thatās useful.
Interesting.
I was thinking of hooking this plugin in with Quick Messages, so you could have a āHelpā button in the bottom right that would open a chat with support staff and also automatically create a ticket, intercom style.
Open to anyoneās thoughts on how to best implement user-created tickets.
3 Likes
I love this idea. I guess it could be in quick messages and on group usercard and page. wouldnāt have to exclude each other. People could also put a Submit Support Ticket wherever they want - eg on their main custom nav, hamburger menu or discourse link next to LATEST etc.
One issue that I can foresee is that for sites that use tickets in multiple ways you will want to have some ticket tags that are not shown to users. So maybe you want to set up at least another āreasonā tag group for public tickets. But maybe some people will even want to allow their members to set status and priority.
I can see this ballooning so would very much hope we can resolve the things I listed above first before we start on them. There are even other tasks that I think are more important, like revamping the tickets dashboard filtering/sorting/pagination. Including default filters and options on dashboard to quickly see only tickets assigned to me or only open tickets.
Good times! 
2 Likes
Hey, great plugin! Itās helping my staff organize a ton of tasks, and keeping them accountable without forcing them onto an external tool.
I unfortunately am having the same casing issue though. In my situation, going to my own userās messages does not work, as in the steps you mentioned to replicate. I always get linked to the lowercase version of my name, i_like_pie, instead of the properly cased I_like_pie.
It seems as though the tickets view is case sensitive on names, where the discourse messages view isnāt.
1 Like
Hey, I just un-installed this and wanted to provide some feedback.
It was initially great, and I still think itās a great plugin, but it ended up not working for us. Our staff of 6 tested it pretty aggressively for just over 3 weeks. We went through about 75 tickets overall, and decided that it just wouldnāt scale well for us.
Thatās not to say that it wonāt work for others; it might. Hereās what we found though in case itās useful:
Assignment Woes
As recommended, we used this plugin alongside Discourse Assign. The pairing makes great sense.
However, we quickly discovered that it fell short of our needs to view multiple staff members being involved in a single deliverable. This is obviously not the Tickets Pluginās fault, but it did effect our usage of it. Thereās debate on whether or not a task should have more than one assignee vs a single owner, but our situation didnāt allow for compromise on this matter.
Our workaround was to create a new āticket-topicā for each task, thats only purpose was to point to a unified discussion topic. This worked well enough at first, but even for a small staff of 6 this quickly grew out of control. We even set up a sub-category just for these new tickets, which did help a bit, but not enough.
A good example of how absurd this became is that when a community member reports an issue (PM topic 1) that requires our attention, we create a new staff-only discussion (topic 2) that points to topic 1 so that we can discuss privately. Whispers unfortunately donāt help us much here, for unrelated reasons.
Then, as this new topic requires multiple assignees, we create new tickets (topic 3 - up to topic 8) so that relevant staff members can be notified and their distinct ticket statuses can be monitored.
All this for a single issue.
Integration was both good and bad
Given the above, all the various ticket notifications quickly became noisy enough that it reduced the general usefulness of notifications as a whole.
Our other issue was that, especially given our workaround leading to duplicate ticket-topics, the āLatestā views within the forum quickly suffered from self-inflicted spam and also became fairly useless. We tried to use tickets as group PMs to get around this, but then they wouldnāt show up in the tickets view, so we stuck to regular topics.
Unfortunately, our primary reason for wanting tickets within Discourse in the first place ended up being the reason we changed our minds; it became overly present. In the end I am reminded that Discourse is built for discussion, and conceptually, bringing tickets in as literal topics breaks this model.
In other words, of course Discourse thinks every time we create a ticket that we also want to have a conversation. Why wouldnāt it? It has no reason to care that a ticket might not necessarily warrant a larger discussion.
Other minor issues
The tickets view itself was also broken for us, in that using a url that combined different options (for example, to-do sorted by owner) would intermittently negate any options, giving us a list of all tickets. Our solution was to just use a single āto doā filter and re-do whatever other options we wanted if we felt compelled to.
Speaking of the tickets view, it was generally very useful but we also did realize that thereās no way to express the effort that tickets require, which is important for us to evaluate how much work is being done as not all tickets are equal in scope. We need this to both plan upcoming work and to assess staff efficiency.
Thereās also the issue I mentioned in my post above about case sensitivity breaking individual staff membersā personal ticket views.
None of these by themselves are outright horrible, but given our overall experience it made it further difficult to argue to keep using this plugin in place of an external purpose-built tool.
We did end up moving to such a tool, and although I really wanted to keep using this plugin, I couldnāt form a good enough argument for it given everything above.
I appreciate all the work involved here! Please donāt take any of the above personally, Iām just providing my own experience in case others in my shoes later on find it helpful.
I would still recommend this plugin for those who donāt need multiple assignees on a ticket, and arenāt concerned with visualizing effort.
2 Likes
Thanks for such a detailed rundown! Iāll reply in more detail soon.
1 Like
Nevermind I just noticed you have to add tags to the tag groups created by this plugin. Totally missed that.
Iām checking this out now but canāt get the ticket tagging to work. When I edit a post the three dropdowns (priority, status and reason) are empty. Canāt select anything.
Is there a setting Iām getting wrong somewhere? I have both ticketing, tagging and assigning turned on. I can tag posts normally just fine.
1 Like
I am having an additional similar issue though. I canāt seem to use the ticketing plugin with private messages.
The ticket button appears but I canāt select priority, status or reason. I enabled tagging for private messages in my discourse settings.
Edit:
I believe there is a bug with the ātickets include groupā setting. Leaving it blank solved the above issue. It may have been because the group was already assigned.
1 Like
Hi Juno! Great
Cool! I have been having this same issue since a recent update to discourse. I have now made this setting blank so will see what happens. I did notice that by manually inviting that group to the message brings the ticket tag pulldowns back to life.
As regards @foohonpie feedbackā¦ thanks for it! Itās always good to have more people try it and give feedback on the experience.
I donāt share your requirement that tickets be assigned to more than one person at a time, and that (along with your attempts to make it fit your requirement) seems to be a source of all of your assignment woes. Also all of your āIntegration was both good and badā feedback.
As regards your āOther minor issuesā feedback - I agree with you here. The interface for viewing and filtering tickets needs a review, both because it is buggy and because maybe there is a better way to do it. Iāve suggested some next steps above. Would love to hear input on those suggestions, or offers to help!
This is a known issue that I do hope @angus prioritizes. Also mentioned above.
1 Like
Thanks for the update! Also btw, I should mention regarding this:
Iāve since discovered that we can mute specific categories, which would have solved this problem entirely.
Humorously enough (because laughing saves me from crying 
) the external tool we switched to, for as nice as it was, became a ghost town just as I feared. I may give this one another go with a change in approach this time around.
It turns out, a good tool that gets used may be better than a better tool that doesnāt.
4 Likes
This bug is now fixed
cc @tobiaseigen
https://github.com/angusmcleod/discourse-tickets/commit/ad6a38d7702861fb42d8bb7c5cc5be4d52c8500a
2 Likes
I still haven not figured out how to turn a topic into a āTicketā 
You can create topics or pms with tickets via the api, however there is currently no UI to add tickets in the composer (coming soon).
- How does one create a ticket via the api?
- What is the update on the ācoming soonā plan to add tickets in the composer?
You can add a ticket to a topic via the āedit topicā UI
You just need to make a normal API request to create a topic, and add is_ticket=true as a parameter.
@tobiaseigen Would you be able to set an agenda for this plugin? Iāll then see if I can fit it into my work agenda.
1 Like
Thanks @angus ā¦ apologies for the silly questions but how does one do a ānormal APIā request like the one in your screenshot? In my āedit topicā I donāt see the Ticket, Priority, Status or Reason? The āUnassignā also seems to be different in my setup?
1 Like
Thereās some great documentation on the API here: https://docs.discourse.org
That screenshot is from Postman which is great for testing out API calls.
Thatās the composer youāve got there. The Edit Topic UI can be accessed by clicking on the pencil here:
3 Likes
Ok, so below is what my Edit Topic UI looks like. Does it matter if the topic is in wiki mode?
I may give this Postman thing a whirl.
Thanks for the detailed instructions!
I still hope to use this plugin someday as an option to provide support to my customers (users) - that they would be able to open a support ticket in some way.
Looks to me like you need to enable the plugin. Are you sure you followed all the steps correctly to install it?
Itās alot of fun! Hereās a screenshot to get you on your way. Note the is_ticket to enable the ticket and that you need a tags[] for each tag you want to add. Also, note that to assign tickets via the API you need to do a follow-up call which I have not figured out how to do via postman.
I also found this useful when learning how to use the API: How to reverse engineer the Discourse API
I think so, I have the new Tickets tab in the admin panel and the 3 āticket_ā groups