Scrip Help

RT Users
1

I had a tech make a suggestion that I think would be cool - we have users
that will put the entire request in the Subject line of the email that
opens the ticket. Would it be possible to write a scrip that would look at
the length of the subject line and copy the line into the body instead? It
would be fine to replace the long subject line with something like “Long
Subject” or even truncate the subject line to like 20 characters.

2

Hi,

Is it possible to differentiate via Scrip whether a ticket is created via
the RT Gui or an email being sent? I cannot seem to come up with something
concrete that works just yet.

Regards,

*Aaron Guise
027 212 6638
aaron@guise.net.nz

3

What if you put in something to pull info from the headers? I have a line in a scrip that determines which support account an email was sent to. It’s empty if the ticket was sent through the GUI.

my $to = $self->TransactionObj->Attachments->First->GetHeader(‘To’);

$RT::Logger->debug(“To email was: $to”);
.
.
.From: rt-users-bounces@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Aaron Guise
Sent: Wednesday, June 10, 2009 5:47 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Scrip Help

Hi,

Is it possible to differentiate via Scrip whether a ticket is created via the RT Gui or an email being sent? I cannot seem to come up with something concrete that works just yet.

Regards,

Aaron Guise
[http://www.guise.net.nz/images/signatures/mob.gif]027 212 6638
[http://www.guise.net.nz/images/signatures/email.gif]aaron@guise.net.nzmailto:aaron@guise.net.nz

4

This info exists somewhere on the wiki as a user-contributed enhancement.

Cambridge Energy Alliance: Save money. Save the planet.

5

Thanks Jerrad,

I couldn’t remember where I had seen this before. I since had a good
search and found it on the Wiki.

Regards,

*Aaron Guise
027 212 6638
aaron@guise.net.nzOn Thu, Jun 11, 2009 at 12:59 PM, Jerrad Pierce < jpierce@cambridgeenergyalliance.org> wrote:

This info exists somewhere on the wiki as a user-contributed enhancement.

–
Cambridge Energy Alliance: Save money. Save the planet.

6

Aaron,

We use this code:

condition set on email transaction to create

my $trans = $self->TransactionObj;
my $msgattr = $trans->Message->First;

return 0 unless $trans->Type eq “Create”;
return 0 unless $msgattr;
return 1 if $msgattr->GetHeader(‘Received’);
return 0;

Hope this helps.

Kenn
LBNLOn 6/10/2009 7:04 PM, Aaron Guise wrote:

Thanks Jerrad,

I couldn’t remember where I had seen this before. I since had a good
search and found it on the Wiki.

*Regards,*

*Aaron Guise
027 212 6638
aaron@guise.net.nz <mailto:aaron@guise.net.nz>
 *

On Thu, Jun 11, 2009 at 12:59 PM, Jerrad Pierce <jpierce@cambridgeenergyalliance.org mailto:jpierce@cambridgeenergyalliance.org> wrote:

This info exists somewhere on the wiki as a user-contributed
enhancement.

--
Cambridge Energy Alliance: Save money. Save the planet.

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

7

Hi All
Firstly, I should say, I’m really no coder. I can hack things about a bit, but thats about it.
I’ve adapted http://requesttracker.wikia.com/wiki/AutoCloseOnNagiosRecoveryMessages into the following.
We use Opsview, which is a modified version of Nagios, and formats its emails slightly differently. I’ve a scrip which is set for just the queue we need it for, with:
Condition: on create
Action: user defined
Template: global template: blank
Stage TransactionBatch

I’ve mashed the following:

my $problem_desc = undef;
my $problem_host = undef;
my $problem = undef;
my $search = undef;
my $Transaction = $self->TransactionObj;
my $subject = $Transaction->Attachments->First->GetHeader(‘Subject’);
if ($subject =~ /RECOVERY: (.+) is OK on host (.*)/) {
# This looks like a nagios recovery message
$problem_desc = $1;
$problem_host = $2;
$problem = “$problem_desc on $problem_host”;
$RT::Logger->debug(“found a recovery msg: $problem”);
} else {
$RT::Logger->debug(“not a recovery msg”);
return 1;
}

Ok, now let’s merge this ticket with it’s PROBLEM msg.

my $search = RT::Tickets->new($RT::SystemUser);
$RT::Logger->debug(“doing search”);
$search->LimitQueue(VALUE => ‘Reports’);
$search->LimitStatus(VALUE => ‘new’, OPERATOR => ‘=’, ENTRYAGGREGATOR => ‘or’);
$search->LimitStatus(VALUE => ‘open’, OPERATOR => ‘=’);
$RT::Logger->debug(“did search”);
if ($search->Count == 0) { return 1; }
$RT::Logger->debug(“starting loop”);
my $id = undef;
while (my $ticket = $search->Next) {
# Ignore the ticket that opened this transation (the recovery one…)
next if $self->TicketObj->Id == $ticket->Id;
# Look for nagios PROBLEM warning messages…
if ( $ticket->Subject =~ /PROBLEM: (.+) is (CRITICAL|WARNING|UNKNOWN) on host (.*)/ ) {
$RT::Logger->debug(“checking msg”);
$RT::Logger->debug(“problem $problem checking $1 on $3”);
if (“$1 on $3” eq $problem){
$RT::Logger->debug(“found ticket”);
# Aha! Found the Problem TICKET corresponding to this RECOVERY
# ticket
$id = $ticket->Id;
# Nagios may send more then one PROBLEM message, right?
$RT::Logger->debug(“Merging ticket " . $self->TicketObj->Id . " into $id because of OA number match.”);
$self->TicketObj->MergeInto($id);
# Keep looking for more PROBLEM tickets…
}
}
}

$id || return 1;

Auto-close/resolve this whole thing

$self->TicketObj->SetStatus( “resolved” );
1;

Which is designed to look for messages with the subject line of:
RECOVERY: name of service is OK on host name.of.host
and then parse the remainder of the queue for associated problem tickets with the subject line of
PROBLEM: name of service is CRITICAL on host name.of.host
when it finds them - it should merge and close.

I actually want to extend this further to merge the ‘problem’ emails along the way, but wanted to get this first stage working properly first.

The above works, if I email in myself with a relevant subject line (scrip 62 is the relevant scrip)

[Wed Feb 16 15:42:27 2011] [debug]: About to think about scrips for transaction #1467131 (/opt/rt3/bin/…/lib/RT/Transaction_Overlay.pm:163)
[Wed Feb 16 15:42:27 2011] [debug]: Committing scrip #55 on txn #1467130 of ticket #252411 (/opt/rt3/bin/…/lib/RT/Scrips_Overlay.pm:190)
[Wed Feb 16 15:42:27 2011] [info]: Ticket 252411 created in queue ‘Reports’ by tom.elliott (/opt/rt3/bin/…/lib/RT/Ticket_Overlay.pm:667)
[Wed Feb 16 15:42:27 2011] [debug]: Found 1 scrips for TransactionBatch stage with applicable type(s) Create (/opt/rt3/bin/…/lib/RT/Scrips_Overlay.pm:370)
[Wed Feb 16 15:42:27 2011] [debug]: Committing scrip #62 on txn #1467130 of ticket #252411 (/opt/rt3/bin/…/lib/RT/Scrips_Overlay.pm:190)
[Wed Feb 16 15:42:27 2011] [debug]: Found a recovery msg: name of service on name.of.host ((eval 29152):20)
[Wed Feb 16 15:42:27 2011] [debug]: doing search ((eval 29152):28)
[Wed Feb 16 15:42:27 2011] [debug]: did search ((eval 29152):32)
[Wed Feb 16 15:42:27 2011] [debug]: starting loop ((eval 29152):34)

(heavily trimmed log)

However, when our monitoring system emails in, it generates an email with exactly the same subject and we get:

Wed Feb 16 15:39:04 2011] [info]: Ticket 252408 created in queue ‘Reports’ by nagios@opsview.[masked] (/opt/rt3/bin/…/lib/RT/Ticket_Overlay.pm:667)
[Wed Feb 16 15:39:04 2011] [debug]: Found 0 scrips for TransactionBatch stage with applicable type(s) (/opt/rt3/bin/…/lib/RT/Scrips_Overlay.pm:370)

Any ideas? I’m aware this probably isn’t enough information, but I’m not sure what else to provide. I think I am probably doing something quite silly or missing something fundamental. Perhaps I need a custom condition? Any input really appreciated. Thanks all.

Kind regards,
Tom Elliott
Gyron Internet Ltd
mail: tom.elliott@gyron.net
web: http://gyron.net/
tel: 0845 888 6900
fax: 0845 888 6910
24 hour customer support: 0845 888 6999

This message may be private and confidential. If you have received this message in error, please notify us and remove it from your system.

Gyron may monitor email traffic data and the content of email for the purposes of security and staff training.

Gyron Internet Ltd is a limited company registered in England and Wales. Registered number: 4239332. Registered office: 3 Centro, Boundary Way, Hemel Hempstead, HP2 7SU. VAT reg no 804 2532 63. Gyron is a registered trademark.

Gyron is a Deloitte Technology Fast 50 ranked company.

8

Hi All

Did anyone get a chance to look at this - really can’t solve it :(On 17 Feb 2011, at 08:57, Tom Elliott - Gyron wrote:

Hi All
Firstly, I should say, I’m really no coder. I can hack things about a bit, but thats about it.
I’ve adapted http://requesttracker.wikia.com/wiki/AutoCloseOnNagiosRecoveryMessages into the following.
We use Opsview, which is a modified version of Nagios, and formats its emails slightly differently. I’ve a scrip which is set for just the queue we need it for, with:
Condition: on create
Action: user defined
Template: global template: blank
Stage TransactionBatch

I’ve mashed the following:

my $problem_desc = undef;
my $problem_host = undef;
my $problem = undef;
my $search = undef;
my $Transaction = $self->TransactionObj;
my $subject = $Transaction->Attachments->First->GetHeader(‘Subject’);
if ($subject =~ /RECOVERY: (.+) is OK on host (.*)/) {

This looks like a nagios recovery message

$problem_desc = $1;
$problem_host = $2;
$problem = “$problem_desc on $problem_host”;
$RT::Logger->debug(“found a recovery msg: $problem”);
} else {
$RT::Logger->debug(“not a recovery msg”);
return 1;
}

Ok, now let’s merge this ticket with it’s PROBLEM msg.

my $search = RT::Tickets->new($RT::SystemUser);
$RT::Logger->debug(“doing search”);
$search->LimitQueue(VALUE => ‘Reports’);
$search->LimitStatus(VALUE => ‘new’, OPERATOR => ‘=’, ENTRYAGGREGATOR => ‘or’);
$search->LimitStatus(VALUE => ‘open’, OPERATOR => ‘=’);
$RT::Logger->debug(“did search”);
if ($search->Count == 0) { return 1; }
$RT::Logger->debug(“starting loop”);
my $id = undef;
while (my $ticket = $search->Next) {
# Ignore the ticket that opened this transation (the recovery one…)
next if $self->TicketObj->Id == $ticket->Id;
# Look for nagios PROBLEM warning messages…
if ( $ticket->Subject =~ /PROBLEM: (.+) is (CRITICAL|WARNING|UNKNOWN) on host (.*)/ ) {
$RT::Logger->debug(“checking msg”);
$RT::Logger->debug(“problem $problem checking $1 on $3”);
if (“$1 on $3” eq $problem){
$RT::Logger->debug(“found ticket”);
# Aha! Found the Problem TICKET corresponding to this RECOVERY
# ticket
$id = $ticket->Id;
# Nagios may send more then one PROBLEM message, right?
$RT::Logger->debug(“Merging ticket " . $self->TicketObj->Id . " into $id because of OA number match.”);
$self->TicketObj->MergeInto($id);
# Keep looking for more PROBLEM tickets…
}
}
}

$id || return 1;

Auto-close/resolve this whole thing

$self->TicketObj->SetStatus( “resolved” );
1;

Which is designed to look for messages with the subject line of:
RECOVERY: name of service is OK on host name.of.host
and then parse the remainder of the queue for associated problem tickets with the subject line of
PROBLEM: name of service is CRITICAL on host name.of.host
when it finds them - it should merge and close.

I actually want to extend this further to merge the ‘problem’ emails along the way, but wanted to get this first stage working properly first.

The above works, if I email in myself with a relevant subject line (scrip 62 is the relevant scrip)

[Wed Feb 16 15:42:27 2011] [debug]: About to think about scrips for transaction #1467131 (/opt/rt3/bin/…/lib/RT/Transaction_Overlay.pm:163)
[Wed Feb 16 15:42:27 2011] [debug]: Committing scrip #55 on txn #1467130 of ticket #252411 (/opt/rt3/bin/…/lib/RT/Scrips_Overlay.pm:190)
[Wed Feb 16 15:42:27 2011] [info]: Ticket 252411 created in queue ‘Reports’ by tom.elliott (/opt/rt3/bin/…/lib/RT/Ticket_Overlay.pm:667)
[Wed Feb 16 15:42:27 2011] [debug]: Found 1 scrips for TransactionBatch stage with applicable type(s) Create (/opt/rt3/bin/…/lib/RT/Scrips_Overlay.pm:370)
[Wed Feb 16 15:42:27 2011] [debug]: Committing scrip #62 on txn #1467130 of ticket #252411 (/opt/rt3/bin/…/lib/RT/Scrips_Overlay.pm:190)
[Wed Feb 16 15:42:27 2011] [debug]: Found a recovery msg: name of service on name.of.host ((eval 29152):20)
[Wed Feb 16 15:42:27 2011] [debug]: doing search ((eval 29152):28)
[Wed Feb 16 15:42:27 2011] [debug]: did search ((eval 29152):32)
[Wed Feb 16 15:42:27 2011] [debug]: starting loop ((eval 29152):34)

(heavily trimmed log)

However, when our monitoring system emails in, it generates an email with exactly the same subject and we get:

Wed Feb 16 15:39:04 2011] [info]: Ticket 252408 created in queue ‘Reports’ by nagios@opsview.[masked] (/opt/rt3/bin/…/lib/RT/Ticket_Overlay.pm:667)
[Wed Feb 16 15:39:04 2011] [debug]: Found 0 scrips for TransactionBatch stage with applicable type(s) (/opt/rt3/bin/…/lib/RT/Scrips_Overlay.pm:370)

Any ideas? I’m aware this probably isn’t enough information, but I’m not sure what else to provide. I think I am probably doing something quite silly or missing something fundamental. Perhaps I need a custom condition? Any input really appreciated. Thanks all.

–
Kind regards,
Tom Elliott
Gyron Internet Ltd
mail: tom.elliott@gyron.net
web: http://gyron.net/
tel: 0845 888 6900
fax: 0845 888 6910
24 hour customer support: 0845 888 6999

This message may be private and confidential. If you have received this message in error, please notify us and remove it from your system.

Gyron may monitor email traffic data and the content of email for the purposes of security and staff training.

Gyron Internet Ltd is a limited company registered in England and Wales. Registered number: 4239332. Registered office: 3 Centro, Boundary Way, Hemel Hempstead, HP2 7SU. VAT reg no 804 2532 63. Gyron is a registered trademark.

Gyron is a Deloitte Technology Fast 50 ranked company.

Kind regards,

Tom Elliott

Gyron Internet Ltd

mail: tom.elliott@gyron.net
web: http://gyron.net/

tel: 0845 888 6900
fax: 0845 888 6910

24 hour customer support: 0845 888 6999

This message may be private and confidential. If you have received this message in error, please notify us and remove it from your system.

Gyron may monitor email traffic data and the content of email for the purposes of security and staff training.

Gyron Internet Ltd is a limited company registered in England and Wales. Registered number: 4239332. Registered office: 3 Centro, Boundary Way, Hemel Hempstead, HP2 7SU. VAT reg no 804 2532 63. Gyron is a registered trademark.

Gyron is a Deloitte Technology Fast 50 ranked company.