Wir möchten die Volltextsuche als kleines Eingabefenster in der Titelleiste zurück, wie bei Version 5 und 6. Die zwei neuen kleinen Fenster für CustomerID und CustomerName sind nutzlos, wenn man zB eine Ticketnummer suchen möchte oder Volltext und die Elasticsearch bringt nicht die Ergebnisse die man braucht. Wir möchten daher das Fensterchen aus Version 5 und 6 zurück. Es wäre auch ok, wenn man die zwei kleinen Fenster... more »
With integrating ElasticSearch in OTRS 7 the input-field for FulltextSearch disappeared in the main menu. Suggestion for OTRS 8 Agent-Frontend: It should be possible for agents to search a ticket by ticketnumber without opening another window (like still existing search for customer / customer-user). Maybe other companys are focused on different search-attributes. So it would be great to select in sysconfig the search-attributes... more »
I would like to add the possibility for agents to send the whole ticket including all notes to a customer by mail.
For now, people press the print button and then append the pdf in the mail that is being sent to the customer. Adding a button or maybe allowing the agent to choose that action when closing a ticket would make that process way faster.
Although fields can be "no mandatory", it would be great to disable some "system" (non-dynamic) fields in the "new ticket phone", such as "SLA" or "Owner", because we caould configure a form cleaner and easier, viewing just the fields we use in our organization.
Web notifications' visual alarm effect is not strong enough. The different browsers and operation systems display the notifications in a different way, so these notifications may be not realized or realized too late by the agent. In OTRS 5 a new notifications has been introduced that calls the attention to a network bug. Similar type of notifications could be introduced for ticket and chat notifications, too. See the... more »
It would be nice to be able to split a ticket from a generic agent.
This would allow upon field selection to create subtasks without a human intervention.
It would be helpful if receipients in BCC would be visible in the ticket for the agents. Of course this attribute may not be accessible for the customers due to data protection but for the agents it would save much time. To work with the ticket history shouldn't be the general way for this.
It would be very cool and useful if when clicking a bar on a dashboard statistics graphic, OTRS would show the user the ticket list corresponding to that specific bar (like a normal ticket search, but with the search parameters used for the value of the bar).
I suggest that add History events for marking articles as important. It would be nice to know who marked the article as such and when. We use this feature in a slightly different manner. We use language translations to change the text from "Mark as Important" to "Mark as Bad Information". We also changed the icon from an exclamation mark to a traffic cone. The History entry would need to be impacted by the the Language... more »
The list of possible new ticket owners on "Move Queue" can be expanded from the default subscribed agents to all that have permission by clicking the symbol ("Get all") to the right of the dropdown list for New Owner. When you then select another "New Queue", the possible owner list remains expanded and is not reset to the subscribed agents for that new queue, obscuring who whould be appropriate to select. There had... more »
I think a filter on the History tab would be very useful. Filtering to a user, time, or action would make the History view much more useful.
We need to look for tickets by number a lot. Search field
is good, but full text search takes a lot of time.
And a switch that says that we are looking for a ticket number, or a separate search field like
could be a great thing.
There are several key things that all our teams do in all our OTRS systems: Open, Answer and Close Tickets Assign Tickets to People and Queues Delete Tickets, and finally MERGE Tickets As we use the email-to-OTRS mechanism for ticket creation quite heavily, merging tickets is probably about the 4 or 5 most common task our teams perform to properly organize support issues. Unfortunately, merging ticket is also, bar none... more »
Sometimes it happens that for example after a ticket-split the customer is sending replies onto the ("wrong") original ticket. You would like to have this response onto the new created (splitted) ticket. I suggest to have a possibility to move such articles in a quick and easy manner into the other (linked) ticket, so that agent can directly place a response on this article inside the correct ticket. This will help... more »
I suggest to hold back the Autoresponse for a Ticket with a Checkbox in the Ticketmask. In some cases I want to hold back the Autoresponse although the Autoresponses are activated.