Quando installi il plugin, vengono aggiunti tre nuovi gruppi di tag: tickets_priority, tickets_reason e tickets_status. Aggiungi tag a questi gruppi (in /tag_groups) per creare ticket di ciascun tipo.
I ticket vengono aggiunti nellâinterfaccia âmodifica argomentoâ (vedi screenshot sotto).
Puoi creare argomenti o messaggi privati (PM) con ticket tramite lâAPI utilizzando is_ticket e un tags[] per ogni tag del ticket (ulteriori informazioni).
Ci sono quattro impostazioni del sito da esaminare. Per accedervi rapidamente, vai su AMMINISTRAZIONE > IMPOSTAZIONI nella tua istanza e cerca tickets.
tickets enabled: Abilita i ticket negli argomenti (richiede che il tagging sia abilitato).
tickets icon: imposta la classe font-awesome dellâicona dei ticket.
tickets include group: gruppo predefinito da includere nei messaggi privati con ticket (nel forum della Global Legal Empowerment Network questo è un gruppo helpdesk).
tickets redirect assigned: reindirizza lâutente dalla rotta âargomenti assegnatiâ nel suo profilo alla dashboard dei Ticket filtrata per i ticket assegnati a lui/lei.
allow staff to tag pms deve essere abilitato se desideri utilizzare i ticket nei messaggi privati.
Questa lista raccoglie segnalazioni di bug e richieste di funzionalitĂ emerse in questa discussione qui sotto e nellâuso attivo di questo plugin da parte di @tobiaseigen e colleghi della Global Legal Empowerment Network. @angus ha accettato di dedicare regolarmente del tempo per lavorare su questa lista tramite https://discourse.angusmcleod.com.au/c/work/l/agenda, ma può sempre usare aiuto!
Bug:
Il link dirottato ai ticket assegnati a un utente sembra non funzionare per gli username con lettere maiuscole e minuscole miste.
I tag dei ticket che appaiono nella vista di stampa, anche per chi non ha accesso al sistema di ticketing.
FunzionalitĂ che vorremmo aggiungere:
Aggiungere la possibilitĂ di indicare lâutente (o gli utenti) di cui tratta il ticket.
Aggiungere colonne nella dashboard dei ticket per la data di creazione del ticket, la data di creazione e la data dellâultima attivitĂ .
Dirottare la ricerca nella dashboard dei ticket per permettere la ricerca dei ticket per parola chiave.
Rivisitare il filtraggio/ordinamento/paginazione della dashboard dei ticket.
Aggiungere alla dashboard dei ticket filtri predefiniti e opzioni per visualizzare rapidamente solo i ticket assegnati a me o solo i ticket aperti.
Aggiungere la possibilitĂ di monitorare la salute complessiva del sistema di ticketing (tempo di risoluzione, ticket aperti, ecc.).
(bassa prioritĂ ) Aggiungere il pulsante âImpostazioniâ in /admin/plugins (dettagli).
(bassa prioritĂ ) Consentire la ridenominazione del sistema di ticketing e dei gruppi di tag dei ticket (richiesto da @GeertClaes).
FunzionalitĂ richieste a bassa prioritĂ /difficili/probabilmente non aggiunte:
aggiungere le opzioni TICKET al menu degli argomenti anche in fondo, oltre che nella modifica del titolo dellâargomento.
notificare allâutente il numero di ticket aperti assegnati ogni volta che effettua il login.
i messaggi di sistema automatizzati sono sempre ticket contrassegnati come âbassa prioritĂ â e âin attesaâ.
i ticket nei messaggi privati vengono inviati allâarchivio dei messaggi di gruppo per default, cosĂŹ da non intasare la casella di posta dei messaggi di gruppo.
solitamente quando creiamo un ticket, impostiamo il tag dello stato su #waiting. Se ci fosse un modo per cambiare questo stato in #underway quando qualcuno risponde, sarebbe di grande aiuto⌠in caso contrario, possiamo fare affidamento sulla dashboard dei ticket se mostra lâattivitĂ , cosĂŹ sappiamo che qualcuno ha risposto e dobbiamo intervenire.
per trasparenza, sarebbe interessante indicare in un sussurro quando i tag dei ticket vengono aggiunti o modificati, seguendo lâesempio del comportamento di assegnazione.
nellâinterfaccia delle segnalazioni è possibile per i moderatori âreclamareâ i post spam. Forse questo è un modello che possiamo seguire per i ticket? Questo accelererebbe le cose: al momento il flusso è de-assegnare e poi assegnare.
Altre funzionalitĂ di Discourse che sarebbero utili
selezione e aggiornamento in blocco della prioritĂ , dello stato, del motivo, del gruppo e dellâassegnatario del ticket (se non presenti nellâinterfaccia utente, allora tramite query da riga di comando?).
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.
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 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
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?
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.
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.
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.
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.
We also have it as a notification, but weâve encountered âoh I must of missed itâ and âit got lost with other notificationsâ responses from users, who neglected open tickets because of those reasons. So, thatâs why we have a site-wide banner. We do three way tickets, so to keep the other party waiting to a minimum, we remind users about their tickets in a bold way
Iâm not sure if Iâm missing something, but this doesnât seem to be working for me, Iâll list what isnât working right for me.
The redirect to the ticket dashboard doesnât seem to follow caps cases; it takes me to admin/tickets?filters=assigned%3Akankuro instead of admin/tickets?filters=assigned%3AKankuro which results in no tickets being shown.
The tags donât stick for any of the fields after refreshing or changing pages.
Iâm not getting any sort of PM or notification to tell when there is a new ticket, not sure if this is intentional or if there is supposed to be some sort of alert to let people know when they have a new ticket.
All Iâve done is installed the plugin, enabled it, added tags to the tag groups, and created a new group with all mods called âhelpdeskâ and added that to tickets include group.
la ricerca nella dashboard dei ticket per permettere la ricerca dei ticket per parola chiave.
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
