https://rt-wiki.bestpractical.com/api.php?action=feedcontributions&user=Ghoti&feedformat=atomRequest Tracker Wiki - User contributions [en]2024-03-29T15:33:13ZUser contributionsMediaWiki 1.37.2https://rt-wiki.bestpractical.com/index.php?title=Ticket_Lifetime_Report&diff=26909Ticket Lifetime Report2019-04-18T15:20:07Z<p>Ghoti: github reference, reformatting</p>
<hr />
<div>==Advanced Reporting==<br />
I've been piloting RT for a few months and have been very happy with the system's operation and reporting capabilities. Recently, though, I've had the need to get some advanced reports from the system such as how well my team has been performing with respect to internal service levels. Specifically, I need to determine how long tickets "lived" from creation to resolution so I can gauge how effective the team is at completing requests. To do this, I need to find the age of resolved tickets and generate a histogram. I rolled my own script using RT's modules so that, hopefully, it's portable across RT versions.<br />
<br />
This and other scripts can be found [here, on github](https://github.com/RyanFrantz/Request-Tracker-Reports).<br />
<br />
==rtTicketLifetime.pl==<br />
<br />
#!/usr/bin/perl<br />
<br />
#<br />
# rtTicketLifetime.pl - query RT and generate a report on the lifetime of resolved tickets<br />
# Author: Ryan Frantz ryanfrantz [at] informed-llc [dot] com<br />
#<br />
<br />
use strict;<br />
use warnings;<br />
<br />
use lib "/usr/local/rt/lib";<br />
<br />
use RT;<br />
use RT::User;<br />
use RT::Interface::CLI qw( CleanEnv GetCurrentUser ); # I guess these aren't exported?<br />
<br />
use Date::Calc qw( Delta_DHMS );<br />
<br />
# TODO:<br />
# 1. add a break out of ticket lifetime by owner<br />
# 2. add email support<br />
# 3. make this available via the web interface with graphing goodness<br />
<br />
## start me up!<br />
<br />
# set the stage...<br />
CleanEnv();<br />
RT::LoadConfig;<br />
RT::Init;<br />
<br />
my $currentUser = GetCurrentUser();<br />
my $tickets = RT::Tickets->new( $currentUser );<br />
#my $query = qq[ Created > '2011-04-01' AND Queue = 'Support Desk' AND Status = 'resolved' ];<br />
my $query = qq[ Created > '3 months ago' AND Queue = 'Support Desk' AND Status = 'resolved' ];<br />
<br />
my $validQuery = $tickets->FromSQL( $query );<br />
#print "VALID QUERY!\n" if $validQuery;<br />
<br />
my $binThreshold = '7'; # 7 days, trust me...<br />
my @histogramData; # prep dat<br />
# initialize the bins, in case there are any that don't get incremented later<br />
# we'll use the array's indices to define the time period in which the ticket lived (i.e. $histogramData[0] is for tickets resolved in < 1 day)<br />
foreach my $day ( 0..$binThreshold ) {<br />
$histogramData[ $day ] = '0';<br />
}<br />
while ( my $ticket = $tickets->Next() ) {<br />
#my $owner = $ticket->OwnerObj; # we're not using this yet...<br />
<br />
# CreatedObj is available via RT::Record<br />
my $dateCreated = $ticket->CreatedObj->Get( Timezone => 'server' );<br />
my $dateResolved = $ticket->ResolvedObj->Get( Timezone => 'server' );<br />
my @dateCreated = split( /-|:| /, $dateCreated );<br />
my @dateResolved = split( /-|:| /, $dateResolved );<br />
my ( $deltaDays, $deltaHours, $deltaMinutes, $deltaSeconds ) = Delta_DHMS( @dateCreated, @dateResolved );<br />
<br />
# increment the bins; if the value is above the bin threshold, simply lump it into a "more" bin ( $binThreshold )<br />
if ( $deltaDays > $binThreshold ) {<br />
#print "DEBUG: $deltaDays > $binThreshold\n";<br />
$histogramData[ $binThreshold ]++;<br />
} else {<br />
#print "DEBUG: $deltaDays <= $binThreshold\n";<br />
$histogramData[ $deltaDays ]++;<br />
}<br />
}<br />
<br />
print "\n" . localtime() . "\n";<br />
print "\nQuery: $query\n";<br />
print "\nFound " . $tickets->CountAll . " tickets\n\n";<br />
<br />
my $day = '1';<br />
foreach my $ticketsResolved ( @histogramData ) {<br />
if ( $day <= $binThreshold ) {<br />
print $day - 1 . " < " . $day . ": " . $ticketsResolved . "\n";<br />
} else {<br />
print $day . "+ : " . $ticketsResolved . "\n";<br />
}<br />
$day++;<br />
}<br />
print "\n";<br />
<br />
<br />
==Output==<br />
When run, the script outputs its results to the screen as follows:<br />
Fri Jul 1 09:18:06 2011<br />
<br />
Query: Created > '3 months ago' AND Queue = 'Support Desk' AND Status = 'resolved'<br />
<br />
Found 72 tickets<br />
<br />
0 < 1: 58<br />
1 < 2: 2<br />
2 < 3: 4<br />
3 < 4: 2<br />
4 < 5: 1<br />
5 < 6: 1<br />
6 < 7: 0<br />
8+ : 4<br />
The output is simple but it clearly illustrates that the majority of my resolved tickets lived less than 24 hours (a very good thing!). Modify the $binThreshold and $query values to suit your own reporting needs.<br />
<br />
==TODO ==<br />
<br />
This work is far from complete. I've got a few items on my TODO list:<br />
* Add a break out of ticket lifetime by owner.<br />
* Add email support.<br />
* Make this available via the web interface with graphing goodness.<br />
<br />
==Warranty==<br />
This script is provided as-is with no implicit or explicit gaurantee that it will work or won't break your implementation; caveat emptor. It's all in the spirit of giving back to the community. It's free as in beer. I'm a big fan of pale ales...</div>Ghotihttps://rt-wiki.bestpractical.com/index.php?title=Ticket_Lifetime_Report&diff=26908Ticket Lifetime Report2019-04-18T14:48:38Z<p>Ghoti: /* TODO */ formatting</p>
<hr />
<div>==Advanced Reporting==<br />
I've been piloting RT for a few months and have been very happy with the system's operation and reporting capabilities. Recently, though, I've had the need to get some advanced reports from the system such as how well my team has been performing with respect to internal service levels. Specifically, I need to determine how long tickets "lived" from creation to resolution so I can gauge how effective the team is at completing requests. To do this, I need to find the age of resolved tickets and generate a histogram. I rolled my own script using RT's modules so that, hopefully, it's portable across RT versions.<br />
==rtTicketLifetime.pl==<br />
#!/usr/bin/perl<br />
<br />
<br />
#<br />
# rtTicketLifetime.pl - query RT and generate a report on the lifetime of resolved tickets<br />
# Author: Ryan Frantz ryanfrantz [at] informed-llc [dot] com<br />
#<br />
<br />
use strict;<br />
use warnings;<br />
<br />
use lib "/usr/local/rt/lib";<br />
<br />
use RT;<br />
use RT::User;<br />
use RT::Interface::CLI qw( CleanEnv GetCurrentUser ); # I guess these aren't exported?<br />
<br />
use Date::Calc qw( Delta_DHMS );<br />
<br />
# TODO:<br />
# 1. add a break out of ticket lifetime by owner<br />
# 2. add email support<br />
# 3. make this available via the web interface with graphing goodness<br />
<br />
## start me up!<br />
<br />
# set the stage...<br />
CleanEnv();<br />
RT::LoadConfig;<br />
RT::Init;<br />
<br />
my $currentUser = GetCurrentUser();<br />
my $tickets = RT::Tickets->new( $currentUser );<br />
#my $query = qq[ Created > '2011-04-01' AND Queue = 'Support Desk' AND Status = 'resolved' ];<br />
my $query = qq[ Created > '3 months ago' AND Queue = 'Support Desk' AND Status = 'resolved' ];<br />
<br />
my $validQuery = $tickets->FromSQL( $query );<br />
#print "VALID QUERY!\n" if $validQuery;<br />
<br />
my $binThreshold = '7'; # 7 days, trust me...<br />
my @histogramData; # prep dat<br />
# initialize the bins, in case there are any that don't get incremented later<br />
# we'll use the array's indices to define the time period in which the ticket lived (i.e. $histogramData[0] is for tickets resolved in < 1 day)<br />
foreach my $day ( 0..$binThreshold ) {<br />
$histogramData[ $day ] = '0';<br />
}<br />
while ( my $ticket = $tickets->Next() ) {<br />
#my $owner = $ticket->OwnerObj; # we're not using this yet...<br />
<br />
# CreatedObj is available via RT::Record<br />
my $dateCreated = $ticket->CreatedObj->Get( Timezone => 'server' );<br />
my $dateResolved = $ticket->ResolvedObj->Get( Timezone => 'server' );<br />
my @dateCreated = split( /-|:| /, $dateCreated );<br />
my @dateResolved = split( /-|:| /, $dateResolved );<br />
my ( $deltaDays, $deltaHours, $deltaMinutes, $deltaSeconds ) = Delta_DHMS( @dateCreated, @dateResolved );<br />
<br />
# increment the bins; if the value is above the bin threshold, simply lump it into a "more" bin ( $binThreshold )<br />
if ( $deltaDays > $binThreshold ) {<br />
#print "DEBUG: $deltaDays > $binThreshold\n";<br />
$histogramData[ $binThreshold ]++;<br />
} else {<br />
#print "DEBUG: $deltaDays <= $binThreshold\n";<br />
$histogramData[ $deltaDays ]++;<br />
}<br />
}<br />
<br />
print "\n" . localtime() . "\n";<br />
print "\nQuery: $query\n";<br />
print "\nFound " . $tickets->CountAll . " tickets\n\n";<br />
<br />
my $day = '1';<br />
foreach my $ticketsResolved ( @histogramData ) {<br />
if ( $day <= $binThreshold ) {<br />
print $day - 1 . " < " . $day . ": " . $ticketsResolved . "\n";<br />
} else {<br />
print $day . "+ : " . $ticketsResolved . "\n";<br />
}<br />
$day++;<br />
}<br />
print "\n";<br />
<br />
==Output==<br />
When run, the script outputs its results to the screen as follows:<br />
Fri Jul 1 09:18:06 2011<br />
<br />
Query: Created > '3 months ago' AND Queue = 'Support Desk' AND Status = 'resolved'<br />
<br />
Found 72 tickets<br />
<br />
0 < 1: 58<br />
1 < 2: 2<br />
2 < 3: 4<br />
3 < 4: 2<br />
4 < 5: 1<br />
5 < 6: 1<br />
6 < 7: 0<br />
8+ : 4<br />
The output is simple but it clearly illustrates that the majority of my resolved tickets lived less than 24 hours (a very good thing!). Modify the $binThreshold and $query values to suit your own reporting needs.<br />
<br />
==TODO ==<br />
<br />
This work is far from complete. I've got a few items on my TODO list:<br />
* Add a break out of ticket lifetime by owner.<br />
* Add email support.<br />
* Make this available via the web interface with graphing goodness.<br />
<br />
==Warranty==<br />
This script is provided as-is with no implicit or explicit gaurantee that it will work or won't break your implementation; caveat emptor. It's all in the spirit of giving back to the community. It's free as in beer. I'm a big fan of pale ales...</div>Ghotihttps://rt-wiki.bestpractical.com/index.php?title=SetCustomFieldViaMail&diff=26668SetCustomFieldViaMail2019-02-21T03:41:28Z<p>Ghoti: moar formatting</p>
<hr />
<div>= RT 3.8 =<br />
<br />
The following example Scrips will help set ticket's CF values, change title or parameters, and notify specific groups based on email properties as detected by RT; Examples partially based on older [[WiKi]] entries and adapted where needed. CF names and values are purely fictional examples, please don't copy and paste without proper understanding of setup and requirements. Requestors will need appropriate permissions to create/modify CF values for this to work.<br />
<br />
Posted &amp; Tested on 3.8.7 by [mailto:webdelic@gmail.com webdelic@gmail.com]<br />
<br />
== EXAMPLE 1: CF Value based on destination email address ==<br />
<br />
Condition: OnCreate<br />
Action: User Defined<br />
Template: Global template: Transaction<br />
Stage: TransactionCreate<br />
<br />
CUSTOM CONDITION:<br />
<br />
PREPARATION CODE:<br />
<br />
return 1;<br />
<br />
CLEANUP CODE:<br />
<br />
my $to = $self-&gt;TransactionObj-&gt;Attachments-&gt;First-&gt;GetHeader('To');<br />
<br />
if ($to =~/^partial\@.*\.?yourdomain\.net/) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'ONE' );<br />
}<br />
<br />
if ($to =~/fixed\@.*\.?yourdomain\.net/) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'TWO' );<br />
}<br />
<br />
$self-&gt;TicketObj-&gt;SetPriority( 1 );<br />
<br />
return 1;<br />
<br />
== EXAMPLE 2: CF Value based on requestor's email address (returns $1 @ $2) ==<br />
<br />
Condition: OnCreate<br />
Action: User Defined<br />
Template: Global template: Transaction<br />
Stage: TransactionCreate<br />
<br />
CUSTOM CONDITION:<br />
<br />
PREPARATION CODE:<br />
<br />
return 1;<br />
<br />
CLEANUP CODE:<br />
<br />
my $ticketRequestor = lc($self-&gt;TicketObj-&gt;RequestorAddresses);<br />
$ticketRequestor =~ /(^.+)@([^\.].*\.[a-z]{2,}$)/;<br />
<br />
if ( $1 =~ /^username$/m ) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'ONE' );<br />
}<br />
<br />
if ( $2 =~ /^yourdomain.net$/m ) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'TWO' );<br />
}<br />
<br />
$self-&gt;TicketObj-&gt;SetPriority( 1 );<br />
<br />
return 1;<br />
<br />
== EXAMPLE 3: CF &amp; Title change based on requestor's email address (returns $1 @ $2) ==<br />
<br />
Condition: OnCreate<br />
Action: User Defined<br />
Template: Global template: Transaction<br />
Stage: TransactionCreate<br />
<br />
<br />
CUSTOM CONDITION:<br />
<br />
PREPARATION CODE:<br />
<br />
return 1;<br />
<br />
CLEANUP CODE:<br />
<br />
my $ticketRequestor = lc($self-&gt;TicketObj-&gt;RequestorAddresses);<br />
$ticketRequestor =~ /(^.+)@([^\.].*\.[a-z]{2,}$)/;<br />
<br />
if ( $2 =~ /^gmail.com$/m ) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Some CF', Value =&gt; 'SOME VALUE' );<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'ONE' );<br />
$self-&gt;TicketObj-&gt;SetSubject ('TAG: '.$self-&gt;TicketObj-&gt;Subject);<br />
}<br />
<br />
<br />
<br />
<br />
== EXAMPLE 4: Notify Groups based on req/destination email or CF Values ==<br />
<br />
Pre-Requirements:<br />
<br />
* You will have to create specific sub-groups and add members to be notified<br />
* You will need "rt-notify-group-admin" to create scrip Actions to notify the above sub-groups<br />
<br />
<nowiki></nowiki><br />
<br />
Condition: User Defined<br />
Action: Notify YOURGROUP<br />
Template: Global template: Transaction<br />
Stage: TransactionCreate<br />
<br />
CUSTOM CONDITION:<br />
<br />
my $to = $self-&gt;TransactionObj-&gt;Attachments-&gt;First-&gt;GetHeader('To');<br />
my $ticketRequestor = lc($self-&gt;TicketObj-&gt;RequestorAddresses);<br />
$ticketRequestor =~ /(^.+)@([^\.].*\.[a-z]{2,}$)/;<br />
<br />
if ($to =~/^nms\@.*\.?yourdomain\.net/) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Type', Value =&gt; 'NAGIOS' );<br />
return 1;<br />
} else {<br />
return 0;<br />
}<br />
<br />
if ( $1 =~ /^nagios$/m ) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Type', Value =&gt; 'NAGIOS' );<br />
return 1;<br />
} else {<br />
return 0;<br />
}<br />
<br />
PREPARATION CODE:<br />
<br />
return 1;<br />
<br />
CLEANUP CODE:<br />
<br />
return 1;<br />
<br />
<br />
= RT 3.6 and older =<br />
<br />
See [[AutomaticCustomFieldValue]]</div>Ghotihttps://rt-wiki.bestpractical.com/index.php?title=SetCustomFieldViaMail&diff=26667SetCustomFieldViaMail2019-02-21T03:35:43Z<p>Ghoti: /* EXAMPLE 1: CF Value based on destination email address */ formatting</p>
<hr />
<div>= RT 3.8 =<br />
<br />
The following example Scrips will help set ticket's CF values, change title or parameters, and notify specific groups based on email properties as detected by RT; Examples partially based on older [[WiKi]] entries and adapted where needed. CF names and values are purely fictional examples, please don't copy and paste without proper understanding of setup and requirements. Requestors will need appropriate permissions to create/modify CF values for this to work.<br />
<br />
Posted &amp; Tested on 3.8.7 by [mailto:webdelic@gmail.com webdelic@gmail.com]<br />
<br />
== EXAMPLE 1: CF Value based on destination email address ==<br />
<br />
Condition: OnCreate<br />
Action: User Defined<br />
Template: Global template: Transaction<br />
Stage: TransactionCreate<br />
<br />
<br />
CUSTOM CONDITION:<br />
<br />
PREPARATION CODE:<br />
<br />
return 1;<br />
<br />
CLEANUP CODE:<br />
<br />
my $to = $self-&gt;TransactionObj-&gt;Attachments-&gt;First-&gt;GetHeader('To');<br />
<br />
if ($to =~/^partial\@.*\.?yourdomain\.net/) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'ONE' );<br />
}<br />
<br />
if ($to =~/fixed\@.*\.?yourdomain\.net/) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'TWO' );<br />
}<br />
<br />
$self-&gt;TicketObj-&gt;SetPriority( 1 );<br />
<br />
return 1;<br />
<br />
== EXAMPLE 2: CF Value based on requestor's email address (returns $1 @ $2) ==<br />
<br />
Condition: OnCreate<br />
Action: User Defined<br />
Template: Global template: Transaction<br />
Stage: TransactionCreate<br />
<br />
CUSTOM CONDITION:<br />
<br />
PREPARATION CODE:<br />
<br />
return 1;<br />
<br />
CLEANUP CODE:<br />
<br />
my $ticketRequestor = lc($self-&gt;TicketObj-&gt;RequestorAddresses);<br />
$ticketRequestor =~ /(^.+)@([^\.].*\.[a-z]{2,}$)/;<br />
<br />
if ( $1 =~ /^username$/m ) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'ONE' );<br />
}<br />
<br />
if ( $2 =~ /^yourdomain.net$/m ) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'TWO' );<br />
}<br />
<br />
$self-&gt;TicketObj-&gt;SetPriority( 1 );<br />
<br />
return 1;<br />
<br />
== EXAMPLE 3: CF &amp; Title change based on requestor's email address (returns $1 @ $2) ==<br />
<br />
Condition: OnCreate<br />
Action: User Defined<br />
Template: Global template: Transaction<br />
Stage: TransactionCreate<br />
<br />
<br />
CUSTOM CONDITION:<br />
<br />
PREPARATION CODE:<br />
<br />
return 1;<br />
<br />
<br />
CLEANUP CODE:<br />
<br />
my $ticketRequestor = lc($self-&gt;TicketObj-&gt;RequestorAddresses);<br />
$ticketRequestor =~ /(^.+)@([^\.].*\.[a-z]{2,}$)/;<br />
<br />
if ( $2 =~ /^gmail.com$/m ) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Some CF', Value =&gt; 'SOME VALUE' );<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'ONE' );<br />
$self-&gt;TicketObj-&gt;SetSubject ('TAG: '.$self-&gt;TicketObj-&gt;Subject);<br />
}<br />
<br />
<br />
<br />
<br />
== EXAMPLE 4: Notify Groups based on req/destination email or CF Values ==<br />
<br />
Pre-Requirements:<br />
<br />
<nowiki>* You will have to create specific sub-groups and add members to be notified<br />
* You will need "rt-notify-group-admin" to create scrip Actions to notify the above sub-groups<br />
<br />
<br />
<br />
Condition: User Defined<br />
Action: Notify YOURGROUP<br />
Template: Global template: Transaction<br />
Stage: TransactionCreate<br />
<br />
</nowiki><br />
<br />
CUSTOM CONDITION:<br />
<br />
my $to = $self-&gt;TransactionObj-&gt;Attachments-&gt;First-&gt;GetHeader('To');<br />
my $ticketRequestor = lc($self-&gt;TicketObj-&gt;RequestorAddresses);<br />
$ticketRequestor =~ /(^.+)@([^\.].*\.[a-z]{2,}$)/;<br />
<br />
if ($to =~/^nms\@.*\.?yourdomain\.net/) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Type', Value =&gt; 'NAGIOS' );<br />
return 1; } else { return 0;}<br />
<br />
if ( $1 =~ /^nagios$/m ) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Type', Value =&gt; 'NAGIOS' );<br />
return 1; } else { return 0;}<br />
<br />
<br />
<br />
PREPARATION CODE:<br />
<br />
return 1;<br />
<br />
<br />
CLEANUP CODE:<br />
<br />
return 1;<br />
<br />
<br />
= RT 3.6 and older =<br />
<br />
See [[AutomaticCustomFieldValue]]</div>Ghotihttps://rt-wiki.bestpractical.com/index.php?title=SetCustomFieldViaMail&diff=26666SetCustomFieldViaMail2019-02-21T03:34:45Z<p>Ghoti: /* EXAMPLE 2: CF Value based on requestor's email address (returns $1 @ $2) */ formatting</p>
<hr />
<div>= RT 3.8 =<br />
<br />
The following example Scrips will help set ticket's CF values, change title or parameters, and notify specific groups based on email properties as detected by RT; Examples partially based on older [[WiKi]] entries and adapted where needed. CF names and values are purely fictional examples, please don't copy and paste without proper understanding of setup and requirements. Requestors will need appropriate permissions to create/modify CF values for this to work.<br />
<br />
Posted &amp; Tested on 3.8.7 by [mailto:webdelic@gmail.com webdelic@gmail.com]<br />
<br />
== EXAMPLE 1: CF Value based on destination email address ==<br />
<br />
Condition: OnCreate<br />
Action: User Defined<br />
Template: Global template: Transaction<br />
Stage: TransactionCreate<br />
<br />
<br />
CUSTOM CONDITION:<br />
<br />
PREPARATION CODE:<br />
<br />
return 1;<br />
<br />
<br />
CLEANUP CODE:<br />
<br />
my $to = $self-&gt;TransactionObj-&gt;Attachments-&gt;First-&gt;GetHeader('To');<br />
<br />
if ($to =~/^partial\@.*\.?yourdomain\.net/) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'ONE' );<br />
}<br />
<br />
if ($to =~/fixed\@.*\.?yourdomain\.net/) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'TWO' );<br />
}<br />
<br />
$self-&gt;TicketObj-&gt;SetPriority( 1 );<br />
<br />
return 1;<br />
<br />
<br />
<br />
<br />
== EXAMPLE 2: CF Value based on requestor's email address (returns $1 @ $2) ==<br />
<br />
Condition: OnCreate<br />
Action: User Defined<br />
Template: Global template: Transaction<br />
Stage: TransactionCreate<br />
<br />
CUSTOM CONDITION:<br />
<br />
PREPARATION CODE:<br />
<br />
return 1;<br />
<br />
CLEANUP CODE:<br />
<br />
my $ticketRequestor = lc($self-&gt;TicketObj-&gt;RequestorAddresses);<br />
$ticketRequestor =~ /(^.+)@([^\.].*\.[a-z]{2,}$)/;<br />
<br />
if ( $1 =~ /^username$/m ) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'ONE' );<br />
}<br />
<br />
if ( $2 =~ /^yourdomain.net$/m ) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'TWO' );<br />
}<br />
<br />
$self-&gt;TicketObj-&gt;SetPriority( 1 );<br />
<br />
return 1;<br />
<br />
== EXAMPLE 3: CF &amp; Title change based on requestor's email address (returns $1 @ $2) ==<br />
<br />
Condition: OnCreate<br />
Action: User Defined<br />
Template: Global template: Transaction<br />
Stage: TransactionCreate<br />
<br />
<br />
CUSTOM CONDITION:<br />
<br />
PREPARATION CODE:<br />
<br />
return 1;<br />
<br />
<br />
CLEANUP CODE:<br />
<br />
my $ticketRequestor = lc($self-&gt;TicketObj-&gt;RequestorAddresses);<br />
$ticketRequestor =~ /(^.+)@([^\.].*\.[a-z]{2,}$)/;<br />
<br />
if ( $2 =~ /^gmail.com$/m ) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Some CF', Value =&gt; 'SOME VALUE' );<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Region', Value =&gt; 'ONE' );<br />
$self-&gt;TicketObj-&gt;SetSubject ('TAG: '.$self-&gt;TicketObj-&gt;Subject);<br />
}<br />
<br />
<br />
<br />
<br />
== EXAMPLE 4: Notify Groups based on req/destination email or CF Values ==<br />
<br />
Pre-Requirements:<br />
<br />
<nowiki>* You will have to create specific sub-groups and add members to be notified<br />
* You will need "rt-notify-group-admin" to create scrip Actions to notify the above sub-groups<br />
<br />
<br />
<br />
Condition: User Defined<br />
Action: Notify YOURGROUP<br />
Template: Global template: Transaction<br />
Stage: TransactionCreate<br />
<br />
</nowiki><br />
<br />
CUSTOM CONDITION:<br />
<br />
my $to = $self-&gt;TransactionObj-&gt;Attachments-&gt;First-&gt;GetHeader('To');<br />
my $ticketRequestor = lc($self-&gt;TicketObj-&gt;RequestorAddresses);<br />
$ticketRequestor =~ /(^.+)@([^\.].*\.[a-z]{2,}$)/;<br />
<br />
if ($to =~/^nms\@.*\.?yourdomain\.net/) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Type', Value =&gt; 'NAGIOS' );<br />
return 1; } else { return 0;}<br />
<br />
if ( $1 =~ /^nagios$/m ) {<br />
$self-&gt;TicketObj-&gt;AddCustomFieldValue( Field =&gt; 'Type', Value =&gt; 'NAGIOS' );<br />
return 1; } else { return 0;}<br />
<br />
<br />
<br />
PREPARATION CODE:<br />
<br />
return 1;<br />
<br />
<br />
CLEANUP CODE:<br />
<br />
return 1;<br />
<br />
<br />
= RT 3.6 and older =<br />
<br />
See [[AutomaticCustomFieldValue]]</div>Ghotihttps://rt-wiki.bestpractical.com/index.php?title=RTAddressRegexp&diff=2936RTAddressRegexp2010-10-22T21:32:07Z<p>Ghoti: </p>
<hr />
<div>$'''RT''''''Address''''''Regexp''' is used to prevent RT messaging itself and generating mail loops, for example when $[[ParseNewMessageForTicketCcs]] is enabled and other. Anyway to protect you from loops and other problems you must set up this option.<br />
<br />
In this option you '''MUST''' cover every email address that can be used to interact with RT via email. If you have aliases of redirect messages to RT from some address those also should be covered.<br />
<br />
An example expression:<br />
<br />
Set($RTAddressRegexp , '^help(-comment)?\@(help|admin)\.(example\.org|ourother\.domain\.com)$');]<br />
<br />
<br />
Would work for a server with the names "help" and "admin" and multiple domains. This will catch:<br />
<br />
help@help.example.org<br />
help-comment@help.example.org<br />
help@admin.example.org<br />
.<br />
.<br />
.<br />
help-comment@admin.ourother.domain.com<br />
<br />
== Simple way ==<br />
<br />
If you don't understand perl regular expression you can use simple way:<br />
<br />
* collect list of addresses you must cover<br />
* escape . (dot), @ and + symbols with \<br />
* fill them into template ^(escaped address 1|escaped address 2|escaped address 3|...)$<br />
<br />
Example:<br />
<br />
* addresses: bugs@my.com, bugs-comment@my.com, sales@my.com and sales-comment@my.com<br />
* escaped: <code>bugs\@my\.com</code>, <code>bugs-comment\@my\.com</code>, <code>sales\@my\.com</code> and <code>sales-comment\@my\.com</code><br />
* regexp: <code>^(bugs\@my\.com|bugs-comment\@my\.com|sales\@my\.com|sales-comment\@my\.com)$</code><br />
<br />
As you can see this can get very long if there are several names for the server.<br />
<br />
== Regexp rules you must know ==<br />
<br />
Short perl regexps rules you must know:<br />
<br />
* \ - is used to escape character with special meaning, like dot, @, parens and other<br />
* <code>.</code> - matches any character, so you usually should escape them<br />
* <code>@</code> - is used to access arrays, so you escape it to match @ literaly<br />
* <code>^</code> and <code>$</code> - match at begin and end of the string respectively, note that regexp <code>rt\@example\.com</code> would match robert@example.com and rt@example.com.au addresses, most probably '''it's not''' what you want, use <code>^rt\@example\.com$</code> regexp.<br />
* <code>()</code> - group things, often used with <code>|</code> to group alternatives<br />
* <code>|</code> - separator for alternative parts, note that <code>^rt\@foo\.com|rt\@bar\.com$</code> matches rt@foo.com.au and robert@bar.com as <code>^</code> applies to the left alternative part and <code>$</code> to the right only, so you can ready this expression as "address starts with rt@foo.com or ends with rt@bar.com". You must group alternatives <code>^(rt\@foo\.com|rt\@bar\.com)$</code><br />
* <code>?</code> - makes precedence atom optional, for example <code>^rt(-comment)?\@example\.com$</code> matches rt@example.com and rt-comment@example.com<br />
<br />
== See also ==<br />
<br />
[[EmailInterface]] and [[SiteConfig]]</div>Ghotihttps://rt-wiki.bestpractical.com/index.php?title=CleanMasonCache&diff=500CleanMasonCache2009-01-27T19:37:50Z<p>Ghoti: </p>
<hr />
<div>Each file in the <code>share/html</code> directory is a mason component. Mason precompiles these files into Perl code and stores precompiled files in the cache dir. This feature speeds up processing as it doesn't need to recompile components each time. Also we can turn off checks on the original components if recompilation is required. Skipping such tests is done to speed up things more. RT uses both of these features. So when you change anything in the <code>share/html</code> or <code>local/html</code> directories, you '''must clear the mason cache''' to see changes. To clear the cache, run this command:<br />
<br />
shell&gt; rm -rf /opt/rt3/var/mason_data/obj/*<br />
<br />
<br />
'''NOTE''' Your path to RT may differ if you're using a packaged version of RT. Please, enter below paths for your OS distribution.<br />
<br />
== FreeBSD ==<br />
<br />
In [[FreeBSD]], all third-party software is installed in /usr/local/, so the command would be:<br />
<br />
rm -rf /usr/local/rt3/var/mason_data/obj/*<br />
<br />
== Debian &amp; Ubuntu ==<br />
<br />
If you're using Debian packages then the filesystem location mentioned above is more likely to be /var/cache/request-tracker3.4/mason_data<br />
<br />
It may also be useful to know that [[DevelMode]] requires a Perl module called Module::Refresh, a package for which is not easily found. So if you're hacking on something and want to see the changes, you can clear the cache and restart Apache in one go like so:<br />
<br />
find /var/cache/request-tracker3.4/mason_data/ -type f -exec rm -f {} \;; /etc/init.d/apache2 restart<br />
<br />
== For developers ==<br />
<br />
The [[DevelMode]] option allows you to avoid this step, but note that you don't want to use this option in production environment.</div>Ghoti