When we started talking about implementing RT it was to solve an issue
we have between our help desk and the help desk of our biggest customer.
The idea was to have their Altiris system send emails to our RT install
regarding issues we needed to deal with, and for RT to be able to keep
their Altiris system updated as to whether the ticket was rejected or
completed by us.
One of the unforeseen issues is the email loop caused by both systems
tracking email correspondence by ticket number in the subject. Altiris
sets the subject to something like:
Medium Incident #11495 has been reassigned by Somebody
So of course our RT makes it:
[rt.local #104] Medium Incident #11495 has been reassigned by Somebody
Anytime the Altiris system updates their ticket we create a new one and
anytime RT updates our ticket they create a new one.
If anyone has ideas around this issue, I would love to hear them.
Thanks in advance,
Jeremy
Medium Incident #11495 has been reassigned by Somebody
So of course our RT makes it:
[rt.local #104] Medium Incident #11495 has been reassigned by Somebody
Anytime the Altiris system updates their ticket we create a new one and
anytime RT updates our ticket they create a new one.
If anyone has ideas around this issue, I would love to hear them.
You need a script at both ends to massage the outgoing subject into the one
needed by the other end, after it comes out of the tracking system in
question. It would need to store ticket number associations for future
emails, possibly in a database table. You could attach this script to a
special email alias just for this purpose on both ends, which then generates
a new email with the desired subject line to the real email address for the
tracking system.
– ============================
Tom Lahti
BIT Statement LLC
(425)251-0833 x 117
http://www.bitstatement.net/
– ============================
Medium Incident #11495 has been reassigned by Somebody
So of course our RT makes it:
[rt.local #104] Medium Incident #11495 has been reassigned by Somebody
Anytime the Altiris system updates their ticket we create a new one and
anytime RT updates our ticket they create a new one.
If anyone has ideas around this issue, I would love to hear them.
You need a script at both ends to massage the outgoing subject into the one
needed by the other end, after it comes out of the tracking system in
question. It would need to store ticket number associations for future
emails, possibly in a database table. You could attach this script to a
special email alias just for this purpose on both ends, which then generates
a new email with the desired subject line to the real email address for the
tracking system.
We have a system setup here to receive emails from a few different
ticketing systems (FootPrints, Remedy & GGUS). Our system works with a
few coordinated pieces, using custom fields in RT to store the other
ticketing system’s identifier.
-
A scrip in RT is triggered on transactions and when a message is
present it scans the message subject for an appropriate regex pattern
that identifies an external ticketing system and saves the identifier in
a custom field.
-
A procmail filter script that processes all incoming email before it
is passed to the rt-mailgate. This filter does the same subject search
for the external ticketing system’s identifier. When an identifier is
found, the RT API is used to perform a search on the appropriate custom
field. When a matching ticket is found, the email subject is modified
to insert our RT ticket identifier for that matching ticket number,
which allows the rt-mailgate to route the email to the correct RT
ticket. This filter, if necessary, will also modify the ticket subject
directly in RT to contain the identifier of all ticket systems, so email
properly (assuming that they tag email subjects with their identifiers
just like RT does).
To prevent mail loops, we need to have NotifyActor disabled on our RT
server. Also, since some other ticket systems have their equivalent of
NotifyActor enabled, emails we receive for resolved RT tickets have our
RT address modified to the comment address to prevent reopening tickets.
Otherwise the resolved email RT sends would reopen the ticket when the
other ticketing system echos that email back to us.
~Jason
/------------------------------------------------------------------
| Jason A. Smith Email: smithj4@bnl.gov |
| Atlas Computing Facility, Bldg. 510M Phone: +1-631-344-4226 |
| Brookhaven National Lab, P.O. Box 5000 Fax: +1-631-344-7616 |
| Upton, NY 11973-5000, U.S.A. |
------------------------------------------------------------------/
smime.p7s (3.81 KB)
When we started talking about implementing RT it was to solve an issue
we have between our help desk and the help desk of our biggest customer.
The idea was to have their Altiris system send emails to our RT install
regarding issues we needed to deal with, and for RT to be able to keep
their Altiris system updated as to whether the ticket was rejected or
completed by us.
One of the unforeseen issues is the email loop caused by both systems
tracking email correspondence by ticket number in the subject. Altiris
sets the subject to something like:
Medium Incident #11495 has been reassigned by Somebody
So of course our RT makes it:
[rt.local #104] Medium Incident #11495 has been reassigned by Somebody
Anytime the Altiris system updates their ticket we create a new one and
anytime RT updates our ticket they create a new one.
If anyone has ideas around this issue, I would love to hear them.
RT 3.8 has a built-in Scrip which should take care of this for you once
it’s taught to recognize the subject tags from altiris.
You want to look at the documentation for ExtractSubjectTagMatch in your
RT_Config.pm
RT 3.8 has a built-in Scrip which should take care of this for you once
it’s taught to recognize the subject tags from altiris.
You want to look at the documentation for ExtractSubjectTagMatch in your
RT_Config.pm
This looks like exactly what I’m after, however I’m been playing with it
for a few hours now and can’t seem to get it working.
I have the following in my RT_SiteConfig.pm file:
Set( $ExtractSubjectTagMatch, qr/Incident #\d+ has/);
Thinking it should match the header from Altiris which is something
like, ‘Medium Incident #111 has been reassigned to somebody’. I also
ensured the Global script for the On Transaction Extract Subject Tag was
present and enabled. But still no joy. Any email from Altiris creates a
new ticket for us, and the emails outbound for Altiris still contain the
RT tagging.
Am I missing something stupid or is there another way I can turn off the
subject tagging for email to a certain address?
Thanks,
Jeremy
I’m attempting to write a scrip to merge incoming tickets based off the
Altiris Incident number. I started by following the example here
http://wiki.bestpractical.com/view/AutoCloseOnNagiosRecoveryMessages But
I’m getting the following error in my logs:
[error]: Scrip 16 Commit failed: Can’t call method “GetHeader” on an
undefined value at (eval 2220) line 11.
This is what I have in the Custom action cleanup code:
If the subject of the ticket matches a pattern suggesting that it is
from
Altiris AND there is an existing ticket with the same Incident number,
merge this ticket into that ticket.
Based on
http://wiki.bestpractical.com/view/AutoCloseOnNagiosRecoveryMessages
my $incident_number = undef;
my $transaction = $self->TransactionObj;
my $subject = $transaction->Attachments->First->GetHeader(‘Subject’);
if ($subject =~ /Incident #(\d+) has/) {
# This looks like a Altiris incident message
$incident_number = $1;
$RT::Logger->debug("Found an Altiris Incident #:
$incident_number");
} else {
return 1;
}
Also, if it helps, I’m running RT 3.8.3.
Thanks of any help anyone can give me,
Jeremy
my $transaction = $self->TransactionObj;
add:
return unless ( $transaction->Attachments->First );
here
Thanks, I also found this threat
Re: [rt-users] Scrip needed that automaticaly closes tickets with a special subject so I changed my script to use $transaction->Subject(); then I also discovered by reading the log more closely it was the approval ticket that was being matched not the original. So I moved the scrip from the Global scrips to the main queue.
Now I just need to figure out why I’m not finding any other tickets with
that incident number. But I’ll do some Googling before I ask anymore
dump questions.
Thanks again,
JeremyOn Wed, 2009-06-10 at 17:08 +0200, Emmanuel Lacour wrote:
On Wed, Jun 10, 2009 at 10:56:08AM -0400, Jeremy Winder wrote:
my $transaction = $self->TransactionObj;
add:
return unless ( $transaction->Attachments->First );
here
my $subject = $transaction->Attachments->First->GetHeader(‘Subject’);
if ($subject =~ /Incident #(\d+) has/) {
# This looks like a Altiris incident message
$incident_number = $1;