In heterogenious environments it would be helpful if ticket notifications could be configured per queue (similar to escalations) instead of configuring them globally. Some teams are working email focussed others are not. Some teams like to receive an email for every update of a ticket others want as few emails as possible. Ideally there could be a default configuration for all and a dedicated configuration per queue ...more »
With an increasing number of queues in the system it gets harder and harder to quickly pick the right queue in the To: / MoveTo: / ... dropdowns.
Adding the personal queues as favorites to the dialogue would increase the accessibility of the most important ones.
If you have a deep queue structure you have to click a long time after you reach your favorite queue.
My idea is to use a pulldown menu as it is used for the ticket move action.
Just a button add at the main bar. You choose your favorite queue and do not need to click subqueue per subqueue anymore.
When creating a new queue in admin interface you have to start from scratch each time. I do suggest to allow creation of a new queue by using an existing queue as template. All settings ( access rights, templates, etc.) are copied from the template - you just need to define a new name of the queue.
Mandatory "My Queues" for Agents Agents can select from the Queues they are able to Read (or further rights) those Queues from which they want to be informed of new Tickets. At the moment the agents are able to deselect all "My Queues" and will then do not receive notifications on new tickets and so on. Therefor I do suggest to add a new feature for a queue to be a mandatory queue. All agnets that are abel to read ...more »
I think it's very useful to see a tree view of the queue, being able to browse the ticket inside of each queue and sub queue.
Queueview in OTRS allows you to see the ticket in the queue, but only of those unlocked.
I suggest to enable some kind of grouping for response templates. Currently it gets quite messy if you define a lot of response templates for different queues. Therefore a sorting / filtering by queue or groups would be very helpful and you don't longer need some workarounds with running numbers at the beginning of the response template name.
Not every queue needs a salutations and or signatures. By now it's not even possible to define an empty salutations or signatures. It's not even possible to get a space accepted as text.
It would be great if queues could go without both. Easiest would be to set an empty salutation/signature as default. This would also speed up queue creation a big time.
Fix precedence on calendar usage when using SLAs.
If an SLA does not have a specific calendar, queue calendar should be used and if not set, use system default workhours/calendar.
Today if an SLA is used and has no calendar, OTRS uses system calendar even is the queue for the ticket has a calendar
Currently sub-queues and sub-services are represented in the database in an un-normalized manner, the parent child relationship is defined via the name string, not by a key reference. This will hamper efforts to improve the visual representation and functions of these items, requiring further perl hacks to manage the parent-child relationship until it becomes unmanageable.
I suggest to allow definition of email notifications individually for all "my queues". For example you should be able to define notification for new tickets in queue "A" and for queue "B" you just would like to be informed on follow-ups. Within preference page all my queues should be listed separately and for each queue I can select via a tick if I would like to get one of the different notifications (new, follow-up, ...more »
Often when working on tickets in different queues the 'back' button does not work as intended. In addition the way back into a queue or into the superordinate queue takes more than 3 clicks.
In the ticket zoom the queue display should be displayed as links into the given queues:
Queue::Subqueue should be [linktoqueue]::[linktosubqueue]
This would speed up queue access in complex setups.