You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It has been mentioned multiple times in issues and on the forum, the default osTicket behavior is to match incoming emails based on headers and/or ticket numbers remaining untouched in subject lines. When this results in duplicate tickets, the usual advice is "tell the customer not to do that" or "add the ticket number to the subject line".
I'm sure there's a good reason for this default, but I would love it there was a toggle that just lets us enable matching on the subject line of an incoming mail - or at the very least, a subject+sender combo.
I don't just use osTicket for human requests, the monitored mailbox also receives automated alerts sometimes. osTicket is perfect for this as it can notify the right people and make sure the alert is handled by someone... except the automated systems don't add ticket numbers to their subject line, they just send the same subject over and over. This is the same with spam messages.
I set a maximum open ticket limit of 3 per sender, but then I get spammed with system warnings in the logs instead. What I would really love is to just be able to make sure that if any sender sends the same subject multiple times, it arrives in the same ticket, not cluttering up the ticket list.
Perhaps there's a mailing list we've been added to
Steps to Reproduce
Get an automated email, ticket is created
Get the same automated email, another ticket is created
[and so on...]
Expected behavior:
Matched with existing ticket and added to thread.
Actual behavior:
Many tickets with the same subject and sender.
Versions
Server Information
osTicket Version v1.18.1 (0375576) — Up to date
Web Server Software Apache
MySQL Version 5.7.23
PHP Version 8.2.16
Running on Bluehost Shared (CentOS) via Softaculous installer
Viewing on Firefox 115 on Gnu/Linux
The text was updated successfully, but these errors were encountered:
Erudition
changed the title
Support for matching subject with existing tickets
Support for matching raw subject with existing tickets
Feb 29, 2024
This is actually something we've discussed internally before. This is added to the Feature Request list. In v2.0 we'll see if this (or something similar) comes to fruition.
Prerequisites
Description
It has been mentioned multiple times in issues and on the forum, the default osTicket behavior is to match incoming emails based on headers and/or ticket numbers remaining untouched in subject lines. When this results in duplicate tickets, the usual advice is "tell the customer not to do that" or "add the ticket number to the subject line".
I'm sure there's a good reason for this default, but I would love it there was a toggle that just lets us enable matching on the subject line of an incoming mail - or at the very least, a subject+sender combo.
I don't just use osTicket for human requests, the monitored mailbox also receives automated alerts sometimes. osTicket is perfect for this as it can notify the right people and make sure the alert is handled by someone... except the automated systems don't add ticket numbers to their subject line, they just send the same subject over and over. This is the same with spam messages.
I set a maximum open ticket limit of 3 per sender, but then I get spammed with system warnings in the logs instead. What I would really love is to just be able to make sure that if any sender sends the same subject multiple times, it arrives in the same ticket, not cluttering up the ticket list.
Perhaps there's a mailing list we've been added to
Steps to Reproduce
Expected behavior:
Matched with existing ticket and added to thread.
Actual behavior:
Many tickets with the same subject and sender.
Versions
Server Information
osTicket Version v1.18.1 (0375576) — Up to date
Web Server Software Apache
MySQL Version 5.7.23
PHP Version 8.2.16
Running on Bluehost Shared (CentOS) via Softaculous installer
Viewing on Firefox 115 on Gnu/Linux
The text was updated successfully, but these errors were encountered: