Hi. I’m testing Zammad to manage customer emails and I have found that the ticket timestamp is always the time at which the ticket was created (which makes some sense). Now there can be a huge difference between this time and the time the email was actually submitted by the customer, so old tickets can appear more recent then they really are and the only way to find out the real date is to download the raw email text and check the “Date” header.
I see two scenarios where having this improved would be useful:
If the scheduler dies for some reason and you find out and restart it some days later, all those newly fetched emails and created tickets will get the current time as timestamp.
Another scenario where having the actual email timestamp would be handy is when redirecting existing emails to Zammad, e.g. from Thunderbird, to “import” old emails or emails from other addresses managed outside of Zammad.
One way to implement this could be to save the email’s original time instead of the ticket creation time as “created_at” in the ticket_articles table so it will be displayed in the ticket under the respective email article. A further enhancement would be to make this timestamp of the first article available in reports so it can be displayed and tickets can be sorted by it.
While i’m agreeing with you i kinda have to disagree too.
An agent can only react to a ticket if it exists. As soon as the ticket exists your defined SLA will affect the escalation. If your scenario 1 becomes real that’ll probably become a huge problem because tickets which are already a few days old will pop up out of nowhere (which isn’t the agents fault ofc).
Instead of handling the consequences of scenario 1 you need to have the ability to react to it asap. Meaning there has to be some monitoring of the email fetching/running scheduler. As soon as there is any problem your admin has to fix it ASAP making it possible for the agents to do their work.
I agree to svnr-dvnkln - you should rather monitor the health state of Zammad instead of wanting to workaround of scheduler problems. By the way, just a small hint:
You can manipulate the sent header of an E-Mail just like you please - Spammer love to use this, as you as recipient have the feel “oh shoot, I oversaw this super important mail from xyz Bank” or something like that and might over see the trap. Exchange and many other E-Mail Servers also set the received time instead of showing the time the E-Mail has been send.
I’m well aware of having to take care of the scheduler being up all the time. But if it goes down, it goes down. Now it makes no real difference if I monitor that or not, the outcome is the same. I only might know about it a bit earlier.
I found another scenario: Adding a new email account or reenabling a previously disabled one will give all new fetched emails and tickets the current timestamp. No problem if there’s only a few mails, not so nice if
there are hundreds.
Imagine everytime somebody puts some documents or folders on your desk for you to work on, all those documents change their date (that the sender put on it) to the current timestamp. How confusing would that be?
Sure, I’m aware of this. But spam is a separate story, I think. There’s no reason for a customer to fake the date. And if the original timestamp is just saved and available as an additional one, everybody could create their overviews with their favorite timestamp, being aware of the fact that one of them could be tweaked.
Having the actual sending time as the ticket or article creation timestamp could also be configurable, e.g. on an e-mail account basis, where I could have a special mailbox set up to “import” old e-mails from other systems whereas the regular user requests use other mail boxes where the date cannot be faked.