
The problem is you're working against the intended nature of OTRS by
allowing agents to submit via email. This isn't my preference either, but
TPTB want agents to work with an iPhone or the web interface and not use
email to respond because it's unsafe for whatever reason for agents to
answer via email. To a point, I can understand because, with a ticket number
*ANYONE* can spoof being an agent... On the one hand, that's true, on
another, you've got to consider what the point of the man-in-the-middle
attack is intending to do with a request. It also becomes problematic for
in-house technical support when agents can be ticket submitters for
themselves via email.
Disclaimer aside, the next thing is to use postmaster filter to change
something about an article that's received by an agent (Match: From: agent
email, Set: X-OTRS-ArticleType: something), and use that in your
notification (Event).
Get a current list of ArticleTypes from Notification(Event). Customers will
get notifications from autoresponses but because (if) they won't match the
article type in notification (Event), it won't send a second notification.
At least, that's the plan.
Body and Subject can't be used, because it *might* be possible to spoof or
reply-and-spoof by customer.
On Fri, Feb 11, 2011 at 8:19 PM,
Thank you for your response, Gerald.
We are using Autoreplies to notify the customer that a ticket has been successfully submitted. But customers also need to receive updates to tickets as we are working on them.
Because we would like to perform as much of the support process from our email clients as possible, we need to come up with a way to notify customers of ticket updates. This is why I was looking into the notification section of the config. This allows us to notify customers of new "article" creations.
The problem is that customers are notified of 'articles' (ticket updates) that they just created. We would like customers to receive notification of new 'articles' we create on a ticket but need to figure out a method to prevent their own 'article' creations from being sent to them as a notifications (else this will seem very spammy to the customer).
It appears to me that if we were using the web interface to communicate with customers, this would not really be an issue as 'event notifications' would not be needed. But the company would like to use an email client as much as possible.
Do you know if what I am seeking is even possible without modifying source code? This seems like a function that other support companies would need as well.
--Chance
-----Original Message----- From: Gerald Young [mailto:crythias@gmail.com] Sent: Friday, February 11, 2011 04:49 PM To: 'User questions and discussions about OTRS.' Subject: Re: [otrs] Customers Receiving Their Own Updates
Autoreplies "generally" go to the customer, and Notifications "generally" go to agents.
On Fri, Feb 11, 2011 at 6:11 PM, Chance Ervin
wrote: OTRS Version: 3.0.5 I have been able to configure much of the OTRS system but I have a nagging issue.
When using an email client, both Agents and Customers receive notifications. The issue is that if a customer sends in an update to a ticket, a notification for that same update is then sent back to the customer. While I want the customer to receive updates that Agents create, I do not want them receiving notification back on the update they just created. I have been through several test scenarios with notifications (event) but I cannot seem to get notifications to customers without also sending them their own updates.
Am I trying to configure the wrong section of OTRS for this functionality? Or am I just not configuring notifications correctly for this behavior?
Thank you,
-- Chance Ervin Sr. Systems and Network Engineer
--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs