I updated to “5.3.1-1674475260.6b8ca02d.focal” we have the same issue, since we got a new ticket form the same customer, which then generate dan email in zammad, but there was no ticket created. It works.
for other customers.
Use your production.log of the day the issue occured and lookup the message id.
If it hits your instance then you will be able to find it within the log and will also be able to see what happened to it.
As I said, the classics are:
no permissions in the affected group
another instance is pulling the mail (e.g. test instances)
(doesn’t match your case but for completeness) Zammad is unable to process the mail and puts it to tmp/unprocessible_mail/
Zammad will never generate a answer mail or agent notification unless the ticket has been created successfully. Never ever.
It looks like there is an issue with a user which is in agents but his email-address is not working.
I, [2023-04-25T09:40:33.337088#3050887-106446000] INFO -- : Process email with msgid '<f050af4a31934153b202cff88365287b@somecompany.somedomain>'
I, [2023-04-25T09:40:33.368250#3050887-106446000] INFO -- : set_attributes_by_x_headers header x-zammad-article-preferences found. Assign preferences={"send-auto-response"=>true, "is-auto-response"=>false}
I, [2023-04-25T09:40:33.511392#3050887-106446000] INFO -- : ended Channel.fetch took: 0.450103184 seconds.
I, [2023-04-25T09:40:34.379823#3050855-9557400] INFO -- : Started GET "/api/v1/tickets/239?full=true&_=1681986001288" for 157.143.2.173 at 2023-04-25 09:40:34 +0200
I, [2023-04-25T09:40:34.385290#3050855-9557400] INFO -- : Processing by TicketsController#show as JSON
I, [2023-04-25T09:40:34.385356#3050855-9557400] INFO -- : Parameters: {"full"=>"true", "_"=>"1681986001288", "id"=>"239"}
I, [2023-04-25T09:40:34.433252#3050855-9557400] INFO -- : Completed 200 OK in 48ms (Views: 1.7ms | ActiveRecord: 17.7ms | Allocations: 14518)
I, [2023-04-25T09:40:36.744674#3050887-112260] INFO -- : ProcessScheduledJobs running...
I, [2023-04-25T09:40:36.746758#3050887-112260] INFO -- : Running job thread for 'Check channels.' (Channel.fetch) status is: sleep
I, [2023-04-25T09:40:36.746831#3050887-112260] INFO -- : Running job thread for 'Process ticket escalations.' (Ticket.process_escalation) status is: sleep
I, [2023-04-25T09:40:36.746971#3050887-112260] INFO -- : Running job thread for 'Check 'Channel' streams.' (Channel.stream) status is: sleep
I, [2023-04-25T09:40:36.747076#3050887-112260] INFO -- : Running job thread for 'Generate 'Session' data.' (Sessions.jobs) status is: sleep
I, [2023-04-25T09:40:36.747776#3050887-112260] INFO -- : Running job thread for 'Execute planned jobs.' (Job.run) status is: sleep
I, [2023-04-25T09:40:37.095194#3050887-112440] INFO -- : 2023-04-25T09:40:37+0200: [Worker(host:zammad pid:3050887)] Job TransactionJob [be71116a-9d98-4a28-9452-36c27fbfd4ce] from DelayedJob(default) with arguments: [{"object"=>"Ticket", "object_id"=>239, "user_id"=>121, "created_at">
E, [2023-04-25T09:40:38.424763#3050887-112440] ERROR -- : Can't use Channel::Driver::Smtp: #<Net::SMTPFatalError: Net::SMTPFatalError>
E, [2023-04-25T09:40:38.424838#3050887-112440] ERROR -- : 550 5.1.1 <sdsdsd.jikji@ourcompany.ourdomain>: Recipient address rejected: User unknown in virtual mailbox table
(Net::SMTPFatalError)
app/models/channel/driver/smtp.rb:93:in `send'
app/models/channel.rb:257:in `deliver'
lib/notification_factory/mailer.rb:170:in `send'
lib/notification_factory/mailer.rb:223:in `notification'
app/models/transaction/notification.rb:216:in `block in perform'
app/models/transaction/notification.rb:105:in `each'
app/models/transaction/notification.rb:105:in `perform'
lib/transaction_dispatcher.rb:61:in `execute_single_backend'
app/jobs/transaction_job.rb:25:in `block in perform'
app/jobs/transaction_job.rb:21:in `perform'
lib/background_services/service/process_delayed_jobs.rb:25:in `block (2 levels) in launch'
lib/background_services/service/process_delayed_jobs.rb:23:in `block in launch'
lib/background_services/service/process_delayed_jobs.rb:20:in `loop'
lib/background_services/service/process_delayed_jobs.rb:20:in `launch'
lib/background_services/service.rb:27:in `block in run'
lib/application_handle_info.rb:19:in `use'
lib/background_services/service.rb:33:in `block in run_in_service_context'
lib/background_services/service.rb:32:in `run_in_service_context'
lib/background_services/service.rb:26:in `run'
lib/background_services.rb:67:in `block in start_as_thread'
E, [2023-04-25T09:40:38.436283#3050887-112440] ERROR -- : Can't use Channel::Driver::Smtp: #<Net::SMTPFatalError: Net::SMTPFatalError> (RuntimeError)
app/models/channel.rb:270:in `rescue in deliver'
app/models/channel.rb:245:in `deliver'
lib/notification_factory/mailer.rb:170:in `send'
lib/notification_factory/mailer.rb:223:in `notification'
app/models/transaction/notification.rb:216:in `block in perform'
app/models/transaction/notification.rb:105:in `each'
app/models/transaction/notification.rb:105:in `perform'
lib/transaction_dispatcher.rb:61:in `execute_single_backend'
app/jobs/transaction_job.rb:25:in `block in perform'
app/jobs/transaction_job.rb:21:in `perform'
lib/background_services/service/process_delayed_jobs.rb:25:in `block (2 levels) in launch'
lib/background_services/service/process_delayed_jobs.rb:23:in `block in launch'
lib/background_services/service/process_delayed_jobs.rb:20:in `loop'
lib/background_services/service/process_delayed_jobs.rb:20:in `launch'
lib/background_services/service.rb:27:in `block in run'
lib/application_handle_info.rb:19:in `use'
lib/background_services/service.rb:33:in `block in run_in_service_context'
lib/background_services/service.rb:32:in `run_in_service_context'
lib/background_services/service.rb:26:in `run'
lib/background_services.rb:67:in `block in start_as_thread'
I, [2023-04-25T09:40:38.438225#3050887-112440] INFO -- : 2023-04-25T09:40:38+0200: [Worker(host:zammad pid:3050887)] Job TransactionJob [be71116a-9d98-4a28-9452-36c27fbfd4ce] from DelayedJob(default) with arguments: [{"object"=>"Ticket", "object_id"=>239, "user_id"=>121, "created_at">
I
You are affected by this issue. The ticket is probably generated fine, but you’re just not getting any notifications of it. Search for the ticket manually.
Also: change the email address of the affected agent or disable them temporarily to allow notifications to be sent again. See my post for further details on this issue and how to work around it.
As MrGeneration stated earlier in his post: it is likely a group permission error that you’re not seeing the ticket. The SMTP error you posted is of a notification failure to an agent about a created ticket. The ticket should really be in your instance somewhere.
it has nothing to do with “it is likely a group permission error that you’re not seeing the ticket”.
The customer gets an email with a link to the “created” ticket… BUT it will just give him a link to another ticket which is not even his ticket so he ha sno access to it.
my user has access to everything so the link works for me, but shows me this old ticket of another customer…
No, it isn’t. I can support letmesetupthis, as we are having this issue too with some of our tickets.
We have a support mail address setup and the mails are not kept in the mailbox. The user writes an email to the address and gets the automatic response “Thanks for your ticket bla bla”. The Ticket-ID is set to the next free ID and a link is created to this ID (as with every new ticket). But the ticket is not created. The next ticket that is successfully created with receive the new free ID, which has been linked in the last automatic reply of the not successful ticket creation.
So the customers link shows the ID from their created ticket, but it’s actually the ticket after this one, as it was not created.
We use MS Exchange 2016 and the support address is a shared mailbox with an user account behind that.
It’s not an issue with the Zammad version, as we are still on 4.x.
If it would be an issue with Zammad 4.x and 5.x people would have noticed like MUCH EARLIER.
Run zammad run rails r "pp Ticket.find(<ID from mail>)"
I bet you do get a response. That is if you use the ID not the number (or the other way around).
Wouldn’t be the first time people confuse ticket ID and number and use it incorrectly in triggers.
And what you both have in common that the mail is based on a trigger.
Ticket number and ID are not necessarily the exact same and can drift.
Alright. Send me a PM with the production.log where this occured and the rough time so I don’t have to search the whole log, please. I can provide a drop link if you don’t want to send it via PM directly.
After reviewing the log files we noticed the (cloned) test instance being the culprit (so the wrong instance fetched the mail and generated a ticket number that obviously can’t exist on the production one.