Request Tracker Wiki - User contributions [en]

User:Bduye

2016-07-22T15:52:23Z

Bduye: Created page with "Bruno Duyé page. RT developper for [http://www.easter-eggs.com/ Easter Eggs]"

Bruno Duyé page.

RT developper for [http://www.easter-eggs.com/ Easter Eggs]

Privileged

2016-07-22T15:47:04Z

Bduye: Add precisions about privileged status

The group '''Privileged''' is one of the three groups for which RT manages the membership automatically. The other two are [[Unprivileged]] and [[Everyone]]. Every user is either a member of the Privileged group or of the Unprivileged group. Membership in the Privileged group means a user can be granted rights. To which one a user belongs can be set in the configuration screen for the user using the 'Let this user be granted rights' checkbox.

To resume:
* unprivileged -> access to [[SelfService]] only (whatever [[Rights]] are)
* privileged -> access are controlled by [[Rights]]

CustomField

2016-07-21T11:05:38Z

Bduye: <pre> </pre>

A '''Custom''''''Field''' (CF) is a user defined property, usually of a [[Ticket]].

Each custom field has a Name, Description and Type.

RT supports the following CF types:

* Select one value
* Select multiple values
* Enter one value
* Enter multiple values
* Fill in one text area (of which you can edit the size: [[ChangeCustomFieldTextAreaSize]])
* Fill in one wikitext area
* Fill in multiple wikitext areas
* Upload one image
* Upload multiple images
* Upload one file
* Upload multiple files

You can define global CustomFields or specific to a [[Queue]] (see "CUSTOM FIELDS IN QUEUES" at [[ManualAdministration]]). They can apply to [[Ticket]], [[Group]], User or Ticket [[Transaction]]s.

== How to set up a custom field in a nutshell ==

==== First, create the Custom Field ====

* Login as one with admin/superuser rights
* Go to Configuration > [[CustomFields]]
* Click on Create
* Fill out the form appropriately and save changes

==== Next, place the Custom Field where you want it ====

* Go to Configuration > Global > [[CustomFields]]
* Choose where you want your [[CustomField]] to appear
* Select the [[CustomField]] you wish to apply and click 'Submit'

If you have installed RTFM you can also define CustomFields for [[RTFM]] Articles 848555157547

== Modify CustomField Value ==

=== RT 3.6 ===

Use the bulk update option

=== RT 3.4 ===

Try the script below based on [http://use.perl.org/~Robrt/journal/25746 this journal entry]. This example renames '[[TaskType]]' values that were 'Sales Call' to 'Prospect' in the 'Sales' queue.

<pre>
<nowiki>#!/home/perl/bin/perl
use strict;
use warnings;
use lib qw(../lib);
use RT;
use RT::Queues;
use RT::Tickets;
use Data::Dumper;

# CONFIGURATION
my $queue = 'Sales';
my $cf_name = 'TaskType';
my $old_value = 'Sales Call'; # NB: This must be a valid value for the CF
my $new_value = 'Prospect';
# END CONFIGURATION

RT::LoadConfig();
RT::Init();
my $tx = RT::Tickets->new($RT::SystemUser);
my $cf = RT::CustomField->new($RT::SystemUser);
my $q = RT::Queue->new($RT::SystemUser);
$tx->FromSQL(qq[queue="$queue" and "cf.$queue.{$cf_name}" = '$old_value']);
$q->Load($queue);
$cf->LoadByNameAndQueue(Queue => $q->Id, Name => $cf_name);
unless( $cf->id ) {
# queue 0 is special case and is a synonym for global queue
$cf->LoadByNameAndQueue( Name => $cf_name, Queue => '0' );
}
unless( $cf->id ) {
print "No field $cf_name in queue ". $q->Name;
die "Could not load custom field";
}

my $i=0;
while (my $t = $tx->Next) {
print "Processing record #" . ++$i . "\n";
my $type = $t->FirstCustomFieldValue($cf_name);
print "Old Type = $type\n";
my ($ret, $msg) = $t->DeleteCustomFieldValue(
Field => $cf->Id,
Value => $type
);
die "Error deleting old value: $msg" unless $ret;
$t->AddCustomFieldValue(
Field => $cf->Id,
Value => 'Prospect'
);
$type = $t->FirstCustomFieldValue($cf_name);
print "New Type = $type\n";
}
</nowiki>
</pre>

== Simple Search Custom Field Values ==

[[SearchCustomField]]

== Custom Fields in Email Ticket Creation ==

[[OnCreateCheckCF]]

SuppressOutgoingMail

2016-07-21T10:42:48Z

Bduye: <pre> </pre>

= Suppress All Outgoing Mail =

Posted by Steve Turner, March 3, 2006.

This modification allows you to turn off ALL outgoing mail by using a new config variable. It is useful if you need to load tickets into a live system from a perl script (from a legacy system, for example) and you don't want RT to send mail for all the tickets you are loading.

All that's required is a new config variable (we called it $RT::[[MailSendingOff]]) and a minor mod to RT/lib/Action/[[SendEmail]].pm.

If the config variable is true, no email will be sent by RT. Otherwise (config variable false or undef), mail will be sent as usual.

Typically on our live system we have this variable set to 0 in [[RT SiteConfig|RT_SiteConfig]].pm so that RT's mail continues to work as expected for our users. In our data load scripts we turn off outgoing email for the duration of the load by coding this:

<pre>
$RT::MailSendingOff = 1;
</pre>

The modification to [[SendEmail]],pm is at the top of the [[SendMessage]] method:

<pre>
sub SendMessage {
my $self = shift;
my $MIMEObj = shift;

my $msgid = $MIMEObj->head->get('Message-Id');
chomp $msgid;

# BEGIN MOD:
# Do not send mail if the config says not to:
if ($RT::MailSendingOff) {
return (1);
}
# END MOD:

$RT::Logger->info( $msgid . " #"
. $self->TicketObj->id . "/"
. $self->TransactionObj->id
. " - Scrip "
. $self->ScripObj->id . " "
. $self->ScripObj->Description );
</pre>

== RT 4 ==

<pre>
$RT::MailSendingOff = 1;
becomes
Set($MailSendingOff, 1);
</pre>
and
<pre>
if ($RT::MailSendingOff) {
becomes
if (RT->Config->Get('MailSendingOff')) {
</pre>

= Suppress Some Outgoing Mail =

Posted by Chris Adams, Jan 31, 2008

'''The easiest way to suppress outgoing mail to a particular user (eg. noreply@example.com) is to remove the e-mail address from the autocreated user.''' As long as their username is the same as their e-mail address, that user will still be used for incoming messages, but outgoing messages won't be sent.

If you want finer-grained control, this modification allows you to specify certain addresses which will be removed when RT generates email by adding something like this to [[RT SiteConfig|RT_SiteConfig]].pm:

<pre>
Set($SquelchList, 'root@example.edu,www-data@example.edu,nobody@example.edu');
</pre>

The mod applies to =RT/Action/[[SendEmail]].pm= just before it uses @blacklist to yank recipients - here's the patch against the Debian 3.6.1-4 package:

<pre>
--- SendEmail.pm 2008-01-31 11:51:15.344883000 -0800
+++ /usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm 2008-01-31 11:54:30.000000000 -0800
@@ -593,6 +593,15 @@
push @blacklist, $attribute->Content;
}

+ # BEGIN SNL Modification: global squelch list
+ # This allows you to add a variable to RT_SiteConfig.pm containing addresses which will always be squelched:
+ # Set($SquelchList, 'root@example.edu,www-data@example.edu,nobody@example.edu');
+ if ($RT::SquelchList) {
+ $RT::Logger->debug("Using global squelch list: $RT::SquelchList\n");
+ push @blacklist, split(/,/, $RT::SquelchList);
+ }
+ # END SNL Modification: global squelch list
+
# Cycle through the people we're sending to and pull out anyone on the
# system blacklist
</pre>

= Suppress Some Outgoing Mail by Regular Expression =

Posted by Michael Brader April 22, 2009.

This is similar to the above but removes the addresses if they match a regular expression. In [[RT SiteConfig|RT_SiteConfig]].pm:

<pre>
Set($SquelchRegexp, qr/noreply|sell-it-support|spam_master/);
</pre>

The patch to to =RT/Action/[[SendEmail]].pm= (from 3.8.2) checks each address against the regexp after the blacklist check

<pre>
--- local/lib/RT/Action/SendEmail.pm 2009-04-22 02:56:09.000000000 +0000
+++ lib/RT/Action/SendEmail.pm 2009-01-12 23:18:46.000000000 +0000
@@ -826,11 +826,6 @@
$RT::Logger->info( $msgid . "$addr was blacklisted for outbound mail on this transaction. Skipping");
next;
}
- # Global Squelch Regexp
- if ($RT::SquelchRegexp and $addr =~ /$RT::SquelchRegexp/) {
- $RT::Logger->info( $msgid . "$addr was squelched based on \$RT::SquelchRegexp in RT_SiteConfig.pm. Skipping");
- next;
- }
push @addrs, $addr;
}
@{ $self->{$type} } = @addrs;
</pre>

= Suppress an email address by using a Scrip =

If you have a need for certain email addresses to be suppressed in a particular queue (for example, tickets coming in from an automated system which uses an address which does not accept replies), you can create a Scrip to squelch the address. Use the '''On Create''' condition, and a '''User Defined''' action. The '''Prepare''' should be simply:

<pre>
1;
</pre>

and the '''Commit''' code should be something like:

<pre>
return 1 unless $self->TicketObj->IsWatcher( Type => 'Requestor',
Email => 'noreply@example.com' );
$self->TicketObj->SquelchMailTo('noreply@example.com');
return 1;
</pre>

SuppressOutgoingMail

2016-07-21T10:42:23Z

Bduye: <pre> </pre>

= Suppress All Outgoing Mail =

Posted by Steve Turner, March 3, 2006.

This modification allows you to turn off ALL outgoing mail by using a new config variable. It is useful if you need to load tickets into a live system from a perl script (from a legacy system, for example) and you don't want RT to send mail for all the tickets you are loading.

All that's required is a new config variable (we called it $RT::[[MailSendingOff]]) and a minor mod to RT/lib/Action/[[SendEmail]].pm.

If the config variable is true, no email will be sent by RT. Otherwise (config variable false or undef), mail will be sent as usual.

Typically on our live system we have this variable set to 0 in [[RT SiteConfig|RT_SiteConfig]].pm so that RT's mail continues to work as expected for our users. In our data load scripts we turn off outgoing email for the duration of the load by coding this:

<pre>
$RT::MailSendingOff = 1;
</pre>

The modification to [[SendEmail]],pm is at the top of the [[SendMessage]] method:

<pre>
sub SendMessage {
my $self = shift;
my $MIMEObj = shift;

my $msgid = $MIMEObj->head->get('Message-Id');
chomp $msgid;

# BEGIN MOD:
# Do not send mail if the config says not to:
if ($RT::MailSendingOff) {
return (1);
}
# END MOD:

$RT::Logger->info( $msgid . " #"
. $self->TicketObj->id . "/"
. $self->TransactionObj->id
. " - Scrip "
. $self->ScripObj->id . " "
. $self->ScripObj->Description );
</pre>

== RT 4 ==

<pre>
$RT::MailSendingOff = 1;
becomes
Set($MailSendingOff, 1);
</pre>
and
<pre>
if ($RT::MailSendingOff) {
becomes
if (RT->Config->Get('MailSendingOff')) {
</pre>

= Suppress Some Outgoing Mail =

Posted by Chris Adams, Jan 31, 2008

'''The easiest way to suppress outgoing mail to a particular user (eg. noreply@example.com) is to remove the e-mail address from the autocreated user.''' As long as their username is the same as their e-mail address, that user will still be used for incoming messages, but outgoing messages won't be sent.

If you want finer-grained control, this modification allows you to specify certain addresses which will be removed when RT generates email by adding something like this to [[RT SiteConfig|RT_SiteConfig]].pm:

Set($SquelchList, 'root@example.edu,www-data@example.edu,nobody@example.edu');

The mod applies to =RT/Action/[[SendEmail]].pm= just before it uses @blacklist to yank recipients - here's the patch against the Debian 3.6.1-4 package:

--- SendEmail.pm 2008-01-31 11:51:15.344883000 -0800
+++ /usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm 2008-01-31 11:54:30.000000000 -0800
@@ -593,6 +593,15 @@
push @blacklist, $attribute->Content;
}

+ # BEGIN SNL Modification: global squelch list
+ # This allows you to add a variable to RT_SiteConfig.pm containing addresses which will always be squelched:
+ # Set($SquelchList, 'root@example.edu,www-data@example.edu,nobody@example.edu');
+ if ($RT::SquelchList) {
+ $RT::Logger->debug("Using global squelch list: $RT::SquelchList\n");
+ push @blacklist, split(/,/, $RT::SquelchList);
+ }
+ # END SNL Modification: global squelch list
+
# Cycle through the people we're sending to and pull out anyone on the
# system blacklist

= Suppress Some Outgoing Mail by Regular Expression =

Posted by Michael Brader April 22, 2009.

This is similar to the above but removes the addresses if they match a regular expression. In [[RT SiteConfig|RT_SiteConfig]].pm:

<pre>
Set($SquelchRegexp, qr/noreply|sell-it-support|spam_master/);
</pre>

The patch to to =RT/Action/[[SendEmail]].pm= (from 3.8.2) checks each address against the regexp after the blacklist check

<pre>
--- local/lib/RT/Action/SendEmail.pm 2009-04-22 02:56:09.000000000 +0000
+++ lib/RT/Action/SendEmail.pm 2009-01-12 23:18:46.000000000 +0000
@@ -826,11 +826,6 @@
$RT::Logger->info( $msgid . "$addr was blacklisted for outbound mail on this transaction. Skipping");
next;
}
- # Global Squelch Regexp
- if ($RT::SquelchRegexp and $addr =~ /$RT::SquelchRegexp/) {
- $RT::Logger->info( $msgid . "$addr was squelched based on \$RT::SquelchRegexp in RT_SiteConfig.pm. Skipping");
- next;
- }
push @addrs, $addr;
}
@{ $self->{$type} } = @addrs;
</pre>

= Suppress an email address by using a Scrip =

If you have a need for certain email addresses to be suppressed in a particular queue (for example, tickets coming in from an automated system which uses an address which does not accept replies), you can create a Scrip to squelch the address. Use the '''On Create''' condition, and a '''User Defined''' action. The '''Prepare''' should be simply:

<pre>
1;
</pre>

and the '''Commit''' code should be something like:

<pre>
return 1 unless $self->TicketObj->IsWatcher( Type => 'Requestor',
Email => 'noreply@example.com' );
$self->TicketObj->SquelchMailTo('noreply@example.com');
return 1;
</pre>

SuppressOutgoingMail

2016-07-21T10:41:52Z

Bduye: <pre> </pre>

= Suppress All Outgoing Mail =

Posted by Steve Turner, March 3, 2006.

This modification allows you to turn off ALL outgoing mail by using a new config variable. It is useful if you need to load tickets into a live system from a perl script (from a legacy system, for example) and you don't want RT to send mail for all the tickets you are loading.

All that's required is a new config variable (we called it $RT::[[MailSendingOff]]) and a minor mod to RT/lib/Action/[[SendEmail]].pm.

If the config variable is true, no email will be sent by RT. Otherwise (config variable false or undef), mail will be sent as usual.

Typically on our live system we have this variable set to 0 in [[RT SiteConfig|RT_SiteConfig]].pm so that RT's mail continues to work as expected for our users. In our data load scripts we turn off outgoing email for the duration of the load by coding this:

<pre>
$RT::MailSendingOff = 1;
</pre>

The modification to [[SendEmail]],pm is at the top of the [[SendMessage]] method:

<pre>
sub SendMessage {
my $self = shift;
my $MIMEObj = shift;

my $msgid = $MIMEObj->head->get('Message-Id');
chomp $msgid;

# BEGIN MOD:
# Do not send mail if the config says not to:
if ($RT::MailSendingOff) {
return (1);
}
# END MOD:

$RT::Logger->info( $msgid . " #"
. $self->TicketObj->id . "/"
. $self->TransactionObj->id
. " - Scrip "
. $self->ScripObj->id . " "
. $self->ScripObj->Description );
</pre>

== RT 4 ==

<pre>
$RT::MailSendingOff = 1;
becomes
Set($MailSendingOff, 1);
</pre>
and
<pre>
if ($RT::MailSendingOff) {
becomes
if (RT->Config->Get('MailSendingOff')) {
</pre>

= Suppress Some Outgoing Mail =

Posted by Chris Adams, Jan 31, 2008

'''The easiest way to suppress outgoing mail to a particular user (eg. noreply@example.com) is to remove the e-mail address from the autocreated user.''' As long as their username is the same as their e-mail address, that user will still be used for incoming messages, but outgoing messages won't be sent.

If you want finer-grained control, this modification allows you to specify certain addresses which will be removed when RT generates email by adding something like this to [[RT SiteConfig|RT_SiteConfig]].pm:

Set($SquelchList, 'root@example.edu,www-data@example.edu,nobody@example.edu');

The mod applies to =RT/Action/[[SendEmail]].pm= just before it uses @blacklist to yank recipients - here's the patch against the Debian 3.6.1-4 package:

--- SendEmail.pm 2008-01-31 11:51:15.344883000 -0800
+++ /usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm 2008-01-31 11:54:30.000000000 -0800
@@ -593,6 +593,15 @@
push @blacklist, $attribute->Content;
}

+ # BEGIN SNL Modification: global squelch list
+ # This allows you to add a variable to RT_SiteConfig.pm containing addresses which will always be squelched:
+ # Set($SquelchList, 'root@example.edu,www-data@example.edu,nobody@example.edu');
+ if ($RT::SquelchList) {
+ $RT::Logger->debug("Using global squelch list: $RT::SquelchList\n");
+ push @blacklist, split(/,/, $RT::SquelchList);
+ }
+ # END SNL Modification: global squelch list
+
# Cycle through the people we're sending to and pull out anyone on the
# system blacklist

= Suppress Some Outgoing Mail by Regular Expression =

Posted by Michael Brader April 22, 2009.

This is similar to the above but removes the addresses if they match a regular expression. In [[RT SiteConfig|RT_SiteConfig]].pm:

Set($SquelchRegexp, qr/noreply|sell-it-support|spam_master/);

The patch to to =RT/Action/[[SendEmail]].pm= (from 3.8.2) checks each address against the regexp after the blacklist check

--- local/lib/RT/Action/SendEmail.pm 2009-04-22 02:56:09.000000000 +0000
+++ lib/RT/Action/SendEmail.pm 2009-01-12 23:18:46.000000000 +0000
@@ -826,11 +826,6 @@
$RT::Logger->info( $msgid . "$addr was blacklisted for outbound mail on this transaction. Skipping");
next;
}
- # Global Squelch Regexp
- if ($RT::SquelchRegexp and $addr =~ /$RT::SquelchRegexp/) {
- $RT::Logger->info( $msgid . "$addr was squelched based on \$RT::SquelchRegexp in RT_SiteConfig.pm. Skipping");
- next;
- }
push @addrs, $addr;
}
@{ $self->{$type} } = @addrs;

= Suppress an email address by using a Scrip =

If you have a need for certain email addresses to be suppressed in a particular queue (for example, tickets coming in from an automated system which uses an address which does not accept replies), you can create a Scrip to squelch the address. Use the '''On Create''' condition, and a '''User Defined''' action. The '''Prepare''' should be simply:

<pre>
1;
</pre>

and the '''Commit''' code should be something like:

<pre>
return 1 unless $self->TicketObj->IsWatcher( Type => 'Requestor',
Email => 'noreply@example.com' );
$self->TicketObj->SquelchMailTo('noreply@example.com');
return 1;
</pre>

SuppressOutgoingMail

2016-07-21T10:40:08Z

Bduye: RT4 update

= Suppress All Outgoing Mail =

Posted by Steve Turner, March 3, 2006.

This modification allows you to turn off ALL outgoing mail by using a new config variable. It is useful if you need to load tickets into a live system from a perl script (from a legacy system, for example) and you don't want RT to send mail for all the tickets you are loading.

All that's required is a new config variable (we called it $RT::[[MailSendingOff]]) and a minor mod to RT/lib/Action/[[SendEmail]].pm.

If the config variable is true, no email will be sent by RT. Otherwise (config variable false or undef), mail will be sent as usual.

Typically on our live system we have this variable set to 0 in [[RT SiteConfig|RT_SiteConfig]].pm so that RT's mail continues to work as expected for our users. In our data load scripts we turn off outgoing email for the duration of the load by coding this:

<pre>
$RT::MailSendingOff = 1;
</pre>

The modification to [[SendEmail]],pm is at the top of the [[SendMessage]] method:

<pre>
sub SendMessage {
my $self = shift;
my $MIMEObj = shift;

my $msgid = $MIMEObj->head->get('Message-Id');
chomp $msgid;

# BEGIN MOD:
# Do not send mail if the config says not to:
if ($RT::MailSendingOff) {
return (1);
}
# END MOD:

$RT::Logger->info( $msgid . " #"
. $self->TicketObj->id . "/"
. $self->TransactionObj->id
. " - Scrip "
. $self->ScripObj->id . " "
. $self->ScripObj->Description );
</pre>

== RT 4 ==

<pre>
$RT::MailSendingOff = 1;
becomes
Set($MailSendingOff, 1);
</pre>
and
<pre>
if ($RT::MailSendingOff) {
becomes
if (RT->Config->Get('MailSendingOff')) {
</pre>

= Suppress Some Outgoing Mail =

Posted by Chris Adams, Jan 31, 2008

'''The easiest way to suppress outgoing mail to a particular user (eg. noreply@example.com) is to remove the e-mail address from the autocreated user.''' As long as their username is the same as their e-mail address, that user will still be used for incoming messages, but outgoing messages won't be sent.

If you want finer-grained control, this modification allows you to specify certain addresses which will be removed when RT generates email by adding something like this to [[RT SiteConfig|RT_SiteConfig]].pm:

Set($SquelchList, 'root@example.edu,www-data@example.edu,nobody@example.edu');

The mod applies to =RT/Action/[[SendEmail]].pm= just before it uses @blacklist to yank recipients - here's the patch against the Debian 3.6.1-4 package:

--- SendEmail.pm 2008-01-31 11:51:15.344883000 -0800
+++ /usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm 2008-01-31 11:54:30.000000000 -0800
@@ -593,6 +593,15 @@
push @blacklist, $attribute->Content;
}

+ # BEGIN SNL Modification: global squelch list
+ # This allows you to add a variable to RT_SiteConfig.pm containing addresses which will always be squelched:
+ # Set($SquelchList, 'root@example.edu,www-data@example.edu,nobody@example.edu');
+ if ($RT::SquelchList) {
+ $RT::Logger->debug("Using global squelch list: $RT::SquelchList\n");
+ push @blacklist, split(/,/, $RT::SquelchList);
+ }
+ # END SNL Modification: global squelch list
+
# Cycle through the people we're sending to and pull out anyone on the
# system blacklist

= Suppress Some Outgoing Mail by Regular Expression =

Posted by Michael Brader April 22, 2009.

This is similar to the above but removes the addresses if they match a regular expression. In [[RT SiteConfig|RT_SiteConfig]].pm:

Set($SquelchRegexp, qr/noreply|sell-it-support|spam_master/);

The patch to to =RT/Action/[[SendEmail]].pm= (from 3.8.2) checks each address against the regexp after the blacklist check

--- local/lib/RT/Action/SendEmail.pm 2009-04-22 02:56:09.000000000 +0000
+++ lib/RT/Action/SendEmail.pm 2009-01-12 23:18:46.000000000 +0000
@@ -826,11 +826,6 @@
$RT::Logger->info( $msgid . "$addr was blacklisted for outbound mail on this transaction. Skipping");
next;
}
- # Global Squelch Regexp
- if ($RT::SquelchRegexp and $addr =~ /$RT::SquelchRegexp/) {
- $RT::Logger->info( $msgid . "$addr was squelched based on \$RT::SquelchRegexp in RT_SiteConfig.pm. Skipping");
- next;
- }
push @addrs, $addr;
}
@{ $self->{$type} } = @addrs;

= Suppress an email address by using a Scrip =

If you have a need for certain email addresses to be suppressed in a particular queue (for example, tickets coming in from an automated system which uses an address which does not accept replies), you can create a Scrip to squelch the address. Use the '''On Create''' condition, and a '''User Defined''' action. The '''Prepare''' should be simply:

1;

and the '''Commit''' code should be something like:

return 1 unless $self->TicketObj->IsWatcher( Type => 'Requestor',
Email => 'noreply@example.com' );
$self->TicketObj->SquelchMailTo('noreply@example.com');
return 1;

SuppressOutgoingMail

2016-07-21T10:24:08Z

Bduye: /* Suppress All Outgoing Mail */

= Suppress All Outgoing Mail =

Posted by Steve Turner, March 3, 2006.

This modification allows you to turn off ALL outgoing mail by using a new config variable. It is useful if you need to load tickets into a live system from a perl script (from a legacy system, for example) and you don't want RT to send mail for all the tickets you are loading.

All that's required is a new config variable (we called it $RT::[[MailSendingOff]]) and a minor mod to RT/lib/Action/[[SendEmail]].pm.

If the config variable is true, no email will be sent by RT. Otherwise (config variable false or undef), mail will be sent as usual.

Typically on our live system we have this variable set to 0 in [[RT SiteConfig|RT_SiteConfig]].pm so that RT's mail continues to work as expected for our users. In our data load scripts we turn off outgoing email for the duration of the load by coding this:

<pre>
$RT::MailSendingOff = 1;
</pre>

The modification to [[SendEmail]],pm is at the top of the [[SendMessage]] method:

<pre>
sub SendMessage {
my $self = shift;
my $MIMEObj = shift;

my $msgid = $MIMEObj->head->get('Message-Id');
chomp $msgid;

# BEGIN MOD:
# Do not send mail if the config says not to:
if ($RT::MailSendingOff) {
return (1);
}
# END MOD:

$RT::Logger->info( $msgid . " #"
. $self->TicketObj->id . "/"
. $self->TransactionObj->id
. " - Scrip "
. $self->ScripObj->id . " "
. $self->ScripObj->Description );
</pre>

= Suppress Some Outgoing Mail =

Posted by Chris Adams, Jan 31, 2008

'''The easiest way to suppress outgoing mail to a particular user (eg. noreply@example.com) is to remove the e-mail address from the autocreated user.''' As long as their username is the same as their e-mail address, that user will still be used for incoming messages, but outgoing messages won't be sent.

If you want finer-grained control, this modification allows you to specify certain addresses which will be removed when RT generates email by adding something like this to [[RT SiteConfig|RT_SiteConfig]].pm:

Set($SquelchList, 'root@example.edu,www-data@example.edu,nobody@example.edu');

The mod applies to =RT/Action/[[SendEmail]].pm= just before it uses @blacklist to yank recipients - here's the patch against the Debian 3.6.1-4 package:

--- SendEmail.pm 2008-01-31 11:51:15.344883000 -0800
+++ /usr/share/request-tracker3.6/lib/RT/Action/SendEmail.pm 2008-01-31 11:54:30.000000000 -0800
@@ -593,6 +593,15 @@
push @blacklist, $attribute->Content;
}

+ # BEGIN SNL Modification: global squelch list
+ # This allows you to add a variable to RT_SiteConfig.pm containing addresses which will always be squelched:
+ # Set($SquelchList, 'root@example.edu,www-data@example.edu,nobody@example.edu');
+ if ($RT::SquelchList) {
+ $RT::Logger->debug("Using global squelch list: $RT::SquelchList\n");
+ push @blacklist, split(/,/, $RT::SquelchList);
+ }
+ # END SNL Modification: global squelch list
+
# Cycle through the people we're sending to and pull out anyone on the
# system blacklist

= Suppress Some Outgoing Mail by Regular Expression =

Posted by Michael Brader April 22, 2009.

This is similar to the above but removes the addresses if they match a regular expression. In [[RT SiteConfig|RT_SiteConfig]].pm:

Set($SquelchRegexp, qr/noreply|sell-it-support|spam_master/);

The patch to to =RT/Action/[[SendEmail]].pm= (from 3.8.2) checks each address against the regexp after the blacklist check

--- local/lib/RT/Action/SendEmail.pm 2009-04-22 02:56:09.000000000 +0000
+++ lib/RT/Action/SendEmail.pm 2009-01-12 23:18:46.000000000 +0000
@@ -826,11 +826,6 @@
$RT::Logger->info( $msgid . "$addr was blacklisted for outbound mail on this transaction. Skipping");
next;
}
- # Global Squelch Regexp
- if ($RT::SquelchRegexp and $addr =~ /$RT::SquelchRegexp/) {
- $RT::Logger->info( $msgid . "$addr was squelched based on \$RT::SquelchRegexp in RT_SiteConfig.pm. Skipping");
- next;
- }
push @addrs, $addr;
}
@{ $self->{$type} } = @addrs;

= Suppress an email address by using a Scrip =

If you have a need for certain email addresses to be suppressed in a particular queue (for example, tickets coming in from an automated system which uses an address which does not accept replies), you can create a Scrip to squelch the address. Use the '''On Create''' condition, and a '''User Defined''' action. The '''Prepare''' should be simply:

1;

and the '''Commit''' code should be something like:

return 1 unless $self->TicketObj->IsWatcher( Type => 'Requestor',
Email => 'noreply@example.com' );
$self->TicketObj->SquelchMailTo('noreply@example.com');
return 1;

WriteCustomAction

2016-07-21T10:21:46Z

Bduye: /* From "User Defined" to a module */

This text in Portuguese in [[WriteCustomActionBR]]

How to write custom action code

== Introduction ==

Included in RT3 is the ability to create your own custom ticket actions via the Web UI. The RT3 Custom Scrip capability lets you access the RT API and is a very powerful tool for customising RT.

== Basics ==

[[File:Example1ScripUI.png|thumb|left|325px|Modify a scrip UI]]Let's start with Web UI. Goto Configuration -> Globals -> Scrips -> New Scrip.

The Scrip UI will display the following selectors: Description, Condition, Action, Template and Stage. In the action selector you can pick actions based on files (modules). An outstanding action from this list is "User Defined". The rest of this document describes this action. So in the Action field, select "User Defined" from the menu.

Once you have selected "User Defined" from the Action Field, the following two Action code areas are enabled and used by RT:
* Custom action preparation code
* Custom action cleanup code

When a [[Transaction]] is created, RT does the following steps to enable all this magic and give you a chance to be a small God:

* Select [[Scrip|Scrips]]
* Check applicability of scrips by executing [[Condition]]s
* Execute preparation code scrip by scrip
* Scrips that fail will be thrown away
* Execute commit code of survived scrips proceeding scrip by scrip

When RT executes your perl Action code within this scrip, your code can become an actor upon the ticket. RT has already defined the variable $self. This variable represents an instance of class [=RT::Action::[[UserDefined]]], a subclass of <code>RT::Action::Generic</code>. You can get more info from perldoc and from the source code.

Instance <code>$self</code> provides your Action code with very useful methods:

$self->TransactionObj

Returns <code>RT::Transaction</code> instance, the transaction that has been created and caused all this.

$self->TicketObj

Returns <code>RT::Ticket</code> instance which represents the ticket. Our transaction was applied to it.

$self->TemplateObj

Returns the template (<code>RT::Template</code>) which was selected for this scrip.

=== Getting more info about these objects ===

You can get complete information about these objects from their POD (embedded documentation).

perldoc /opt/rt3/lib/RT/Ticket.pm
perldoc /opt/rt3/lib/RT/Ticket_Overlay.pm
perldoc /opt/rt3/lib/RT/Tickets.pm
perldoc /opt/rt3/lib/RT/Tickets_Overlay.pm
perldoc /opt/rt3/lib/RT/Transaction.pm
perldoc /opt/rt3/lib/RT/Transaction_Overlay.pm
perldoc /opt/rt3/lib/RT/Transactions.pm
perldoc /opt/rt3/lib/RT/Transactions_Overlay.pm
...

== Simple example ==

Ok, let's try to change something.

Requirement: There is a support queue for special customers where each request must have high priority on ticket creation.

[[File:Example1ScripBehavior.png|thumb|275px]]Preparation code:

<nowiki>
# we don't need any preparation yet.
return 1;

</nowiki>

Commit code:

$self->TicketObj->SetPriority( 100 );
return 1;

I hope that this example is understandable enough, but it has at least one weakness. I've hardcoded the priority value. Since RT lets the administrator define default final priority per queue, our code should reflect that.

my $qfp = $self->TicketObj->QueueObj->FinalPriority || 100;
$self->TicketObj->SetPriority( int( $qfp * 0.9 ) );
return 1;

This change to the logic first retrieves the [[FinalPriority]] of the current Queue or 100 if no [[FinalPriority]] is set for the Queue. Then it sets the Priority of this ticket to 90% of the retrieved Priority. The final 10% of the priority is reserved for very exclusive, super high priority requests.

== Errors handling ==

It's important to check errors to protect you from headache. Most methods in RT that change something return a tuple ($status, $msg). If $status is not true value then something failed and $msg is error text describing the reason. Let's extend our code:

my $qfp = $self->TicketObj->QueueObj->FinalPriority || 100;
my ($status, $msg) = $self->TicketObj->SetPriority( int( $qfp * 0.9 ) );
unless ( $status ) {
$RT::Logger->error("Couldn't change priority: $msg");
return 0;
}
return 1;

== What you can (not) do with scrips ==

You can manipulate almost any object in RT within a scrip.

* update properties of tickets, for example set properties of tickets with commands in email
* change linked tickets, for example [[OpenTicketOnAllMemberResolve]] and [[OpenDependantsOnResolve]]
* extract info from messages, implement own workflow, create approvals and many-many more actions

Let's talk about impossible things you don't even want to try to do with a scrip:

* you couldn't deny action scrip's triggered, for example you don't want to allow users to open ticket unless it has owner, you may think that you can create scrip "on ticket open block action if ticket has no owner", but it's impossible. I said impossible? no... sure you can create such scrip, but instead of preventing action you can revert it by setting status back to old value. yeah, this works but don't forget that it would be two transactions 'set open status' and 'set previouse status'. Each action could be applied to other scrips, so really it's not preventing action.
* you couldn't run scrip at some time, remember RT runs scrips after creating transactions, but of course we have solution for this situation - rt-crontool.

== How to be silent ==

Now you put SetXxxx calls all over the places in RT and suddenly note that strange transactions appear in tickets. They have creator [[RT System|RT_System]] and describe what you've done with your scrips. Sometimes it's better to be silent and not mislead users. These transactions also go through the steps described earlier and could trigger some conditions too. Just use the long form of SetXxx functions:

$TicketObj->_Set(Field => 'Priority', Value => 90, RecordTransaction => 0);

The zero in the [[RecordTransaction]] argument informs RT not to record the change as a new transaction.

== How to change ticket custom field values ==

Step 1, get the custom field (CF) object or ID. Don't use the hardcoded CF ID from the database. [why?] Step 2, get the CF object by ticket object by ticket object (I hope you remember how to get a ticket object) and CF name.

<pre>
...
my $CFName = 'MyCustomField';
my $CF = RT::CustomField->new( $RT::SystemUser );
$CF->LoadByNameAndQueue( Name => $CFName, Queue => $Ticket->Queue );
# RT has bug/feature until 3.0.10, you should load global CF yourself
unless( $CF->id ) {
# queue 0 is special case and is a synonym for global queue
$CF->LoadByNameAndQueue( Name => $CFName, Queue => '0' );
}

unless( $CF->id ) {
$RT::Logger->error( "No field $CFName in queue ". $Ticket->QueueObj->Name );
return undef;
}
...
</pre>

Now we could add value to ticket:
<pre>
my $Value = 'MyValue';
$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value );
</pre>
or
<pre>
$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value, RecordTransaction => 0 );
</pre>
you also could use custom field id instead of object.
<pre>
$Ticket->AddCustomFieldValue( Field => NN , Value => $Value );
</pre>

== Step by step or "Tickets, transactions and attachments" ==

Lets look what happens with RT from the beginning when a user clicks on create button in their browser. Web server gets request with queue id, ticket subject and body, owner and etc. RT fetches info from the request that is needed for Ticket record: its Queue id, Status, Subject, [[CurrentUser]](Creator), and then runs the next code:

<pre>
# init empty instance of RT::Ticket class
my $TicketObj = RT::Ticket->new( $session{'CurrentUser'} );

# create new record
# if you more familiar with SQL then it's INSERT
# this call is inherited from SearchBuilder API
my $id = $TicketObj->Create( %ARGS );

</pre>

Ticket is created and it's time to record transaction into table. RT has all info for this: ticket's id that was recently created and transaction type - 'Create'.

<pre>
# this call creates new transaction record
# this is very similar to situation with new ticket record
my $TransactionObj = $Ticket->_RecordTransaction( %ARGS );

</pre>

Transactions in RT has an many-to-one mapping with ticket. One ticket => one or more transactions. You can get collection of transactions by calling Transactions method on a ticket object:
<pre>
my $transactions = $TicketObj->Transactions;
</pre>
Each transaction belongs to only one ticket and you get ticket object with the following code:
<pre>
my $ticket = $TransactionObj->TicketObj;
</pre>
As you can see RT still didn't use content that you wrote in the body. Content is an RT::Attachment object. You know how RT creates new record and know about Ticket-Transaction relation, the same relationship applies to Attachments and Transactions.

== From "User Defined" to a module ==

User defined actions you write in the web UI are handy and quick way to write an action. However, at some point you want to re-use your action, make it configurable, edit it in more suitable editor rather than text area, make it more complex and consist of additional methods. So it's time to move from "User Defined" action to your first module file.

<pre>

use strict;
use warnings;

package RT::Action::MyAction;
use base qw(RT::Action::Generic);

sub Prepare {
my $self = shift;

... here goes preparation code ...

return 1;
}

sub Commit {
my $self = shift;

... here goes commit code ...

return 1;
}

1;

</pre>

''Note'': for RT4, replace '''RT::Action::Generic''' by '''RT::Action'''

That's it. Save it as '''lib/RT/Action/MyAction.pm''' (it is important that the file have the same name as the package ("MyAction" in the example)), fill in preparation and commit code then you can register your action in the DB. Use the following data file and [[AddDatabaseRecords]] instructions.

<pre>

@ScripActions = (
{
Name => 'My super duper action',
Description => 'Super-puper action that does hell of a job' ,
ExecModule => 'MyAction',
Argument => 'some argument if needed'
},
);

</pre>

Now your action in the DB and you can pick it for a scrip through the Web UI instead of picking "User Defined".

== See also ==

Other documentation on this wiki that may help

[[GlobalObjects]], [[ObjectModel]]

== Special thanks ==

* [[TimWilson]], who was the main editor and reviewer

InitialData

2016-07-20T21:53:23Z

Bduye: /* Example */

= Adding new records into RT's database =

This might be helpful if you want to add a record in the RT DB and don't want to mess things by SQL INSERT queries and don't want to write code.

This is especially helpful when you write custom scrip actions/conditions as module files instead of using <code>User Defined</code> and want to register them in the DB.

= rt-setup-database and initialdata =

RT comes with <code>etc/initialdata</code> file that is parsed and inserted into newly created DB when you install for the first time. When you upgrade RT, database changes comes in similar file.

Basic idea is that you can write such files and use <code>sbin/rt-setup-database</code> script to insert the data:

/path/to/rt3/sbin/rt-setup-database --action insert --datafile /path/to/data-file

= Example =

<pre>
@ScripConditions = (
{ Name => 'On Some Event',
Description => 'When some event happens',
ExecModule => 'SomeEvent',
Argument => 'some argument',
ApplicableTransTypes => 'Any'
},
);
</pre>

= How it works =

File should be a valid perl scrip that fill a bunch of arrays with data that should be inserted, for example: @Queues, @Scrips, @Groups and so on. Full list of available arrays you can find in method InsertData that is in <code>lib/RT/Handle.pm</code> file.

You put hashes with key/value pairs into these arrays. So it looks like this:

<pre>

@SomeArray = (
{
key => 'value',
key => 'value',
...
},
{
key => 'value',
key => 'value',
...
},
...
);
@AnotherArray = (
{
...
},
...
);

</pre>

Usually you don't write any code, but this doesn't mean you can not. Sometimes you do want to write a bit of code, for example to load a bunch of data from a text file.

= Where to find more info =

There is no much to document about it and there are plenty of examples in RT itself. Start from <code>etc/initialdata</code> then look at <code>etc/upgrade/*/content</code> files, then look at the same set in [[RTIR]] extension or any other extension.

= See also =

[[WriteCustomAction]] and [[WriteCustomCondition]] for details on @ScripActions and @ScripConditions

InitialData

2016-07-20T21:53:06Z

Bduye: add <pre> </pre> blocks

= Adding new records into RT's database =

This might be helpful if you want to add a record in the RT DB and don't want to mess things by SQL INSERT queries and don't want to write code.

This is especially helpful when you write custom scrip actions/conditions as module files instead of using <code>User Defined</code> and want to register them in the DB.

= rt-setup-database and initialdata =

RT comes with <code>etc/initialdata</code> file that is parsed and inserted into newly created DB when you install for the first time. When you upgrade RT, database changes comes in similar file.

Basic idea is that you can write such files and use <code>sbin/rt-setup-database</code> script to insert the data:

/path/to/rt3/sbin/rt-setup-database --action insert --datafile /path/to/data-file

= Example =

@ScripConditions = (
{ Name => 'On Some Event',
Description => 'When some event happens',
ExecModule => 'SomeEvent',
Argument => 'some argument',
ApplicableTransTypes => 'Any'
},
);

= How it works =

File should be a valid perl scrip that fill a bunch of arrays with data that should be inserted, for example: @Queues, @Scrips, @Groups and so on. Full list of available arrays you can find in method InsertData that is in <code>lib/RT/Handle.pm</code> file.

You put hashes with key/value pairs into these arrays. So it looks like this:

<pre>

@SomeArray = (
{
key => 'value',
key => 'value',
...
},
{
key => 'value',
key => 'value',
...
},
...
);
@AnotherArray = (
{
...
},
...
);

</pre>

Usually you don't write any code, but this doesn't mean you can not. Sometimes you do want to write a bit of code, for example to load a bunch of data from a text file.

= Where to find more info =

There is no much to document about it and there are plenty of examples in RT itself. Start from <code>etc/initialdata</code> then look at <code>etc/upgrade/*/content</code> files, then look at the same set in [[RTIR]] extension or any other extension.

= See also =

[[WriteCustomAction]] and [[WriteCustomCondition]] for details on @ScripActions and @ScripConditions

WriteCustomAction

2016-07-20T21:51:09Z

Bduye: add <pre> </pre> blocks

This text in Portuguese in [[WriteCustomActionBR]]

How to write custom action code

== Introduction ==

Included in RT3 is the ability to create your own custom ticket actions via the Web UI. The RT3 Custom Scrip capability lets you access the RT API and is a very powerful tool for customising RT.

== Basics ==

[[File:Example1ScripUI.png|thumb|left|325px|Modify a scrip UI]]Let's start with Web UI. Goto Configuration -> Globals -> Scrips -> New Scrip.

The Scrip UI will display the following selectors: Description, Condition, Action, Template and Stage. In the action selector you can pick actions based on files (modules). An outstanding action from this list is "User Defined". The rest of this document describes this action. So in the Action field, select "User Defined" from the menu.

Once you have selected "User Defined" from the Action Field, the following two Action code areas are enabled and used by RT:
* Custom action preparation code
* Custom action cleanup code

When a [[Transaction]] is created, RT does the following steps to enable all this magic and give you a chance to be a small God:

* Select [[Scrip|Scrips]]
* Check applicability of scrips by executing [[Condition]]s
* Execute preparation code scrip by scrip
* Scrips that fail will be thrown away
* Execute commit code of survived scrips proceeding scrip by scrip

When RT executes your perl Action code within this scrip, your code can become an actor upon the ticket. RT has already defined the variable $self. This variable represents an instance of class [=RT::Action::[[UserDefined]]], a subclass of <code>RT::Action::Generic</code>. You can get more info from perldoc and from the source code.

Instance <code>$self</code> provides your Action code with very useful methods:

$self->TransactionObj

Returns <code>RT::Transaction</code> instance, the transaction that has been created and caused all this.

$self->TicketObj

Returns <code>RT::Ticket</code> instance which represents the ticket. Our transaction was applied to it.

$self->TemplateObj

Returns the template (<code>RT::Template</code>) which was selected for this scrip.

=== Getting more info about these objects ===

You can get complete information about these objects from their POD (embedded documentation).

perldoc /opt/rt3/lib/RT/Ticket.pm
perldoc /opt/rt3/lib/RT/Ticket_Overlay.pm
perldoc /opt/rt3/lib/RT/Tickets.pm
perldoc /opt/rt3/lib/RT/Tickets_Overlay.pm
perldoc /opt/rt3/lib/RT/Transaction.pm
perldoc /opt/rt3/lib/RT/Transaction_Overlay.pm
perldoc /opt/rt3/lib/RT/Transactions.pm
perldoc /opt/rt3/lib/RT/Transactions_Overlay.pm
...

== Simple example ==

Ok, let's try to change something.

Requirement: There is a support queue for special customers where each request must have high priority on ticket creation.

[[File:Example1ScripBehavior.png|thumb|275px]]Preparation code:

<nowiki>
# we don't need any preparation yet.
return 1;

</nowiki>

Commit code:

$self->TicketObj->SetPriority( 100 );
return 1;

I hope that this example is understandable enough, but it has at least one weakness. I've hardcoded the priority value. Since RT lets the administrator define default final priority per queue, our code should reflect that.

my $qfp = $self->TicketObj->QueueObj->FinalPriority || 100;
$self->TicketObj->SetPriority( int( $qfp * 0.9 ) );
return 1;

This change to the logic first retrieves the [[FinalPriority]] of the current Queue or 100 if no [[FinalPriority]] is set for the Queue. Then it sets the Priority of this ticket to 90% of the retrieved Priority. The final 10% of the priority is reserved for very exclusive, super high priority requests.

== Errors handling ==

It's important to check errors to protect you from headache. Most methods in RT that change something return a tuple ($status, $msg). If $status is not true value then something failed and $msg is error text describing the reason. Let's extend our code:

my $qfp = $self->TicketObj->QueueObj->FinalPriority || 100;
my ($status, $msg) = $self->TicketObj->SetPriority( int( $qfp * 0.9 ) );
unless ( $status ) {
$RT::Logger->error("Couldn't change priority: $msg");
return 0;
}
return 1;

== What you can (not) do with scrips ==

You can manipulate almost any object in RT within a scrip.

* update properties of tickets, for example set properties of tickets with commands in email
* change linked tickets, for example [[OpenTicketOnAllMemberResolve]] and [[OpenDependantsOnResolve]]
* extract info from messages, implement own workflow, create approvals and many-many more actions

Let's talk about impossible things you don't even want to try to do with a scrip:

* you couldn't deny action scrip's triggered, for example you don't want to allow users to open ticket unless it has owner, you may think that you can create scrip "on ticket open block action if ticket has no owner", but it's impossible. I said impossible? no... sure you can create such scrip, but instead of preventing action you can revert it by setting status back to old value. yeah, this works but don't forget that it would be two transactions 'set open status' and 'set previouse status'. Each action could be applied to other scrips, so really it's not preventing action.
* you couldn't run scrip at some time, remember RT runs scrips after creating transactions, but of course we have solution for this situation - rt-crontool.

== How to be silent ==

Now you put SetXxxx calls all over the places in RT and suddenly note that strange transactions appear in tickets. They have creator [[RT System|RT_System]] and describe what you've done with your scrips. Sometimes it's better to be silent and not mislead users. These transactions also go through the steps described earlier and could trigger some conditions too. Just use the long form of SetXxx functions:

$TicketObj->_Set(Field => 'Priority', Value => 90, RecordTransaction => 0);

The zero in the [[RecordTransaction]] argument informs RT not to record the change as a new transaction.

== How to change ticket custom field values ==

Step 1, get the custom field (CF) object or ID. Don't use the hardcoded CF ID from the database. [why?] Step 2, get the CF object by ticket object by ticket object (I hope you remember how to get a ticket object) and CF name.

<pre>
...
my $CFName = 'MyCustomField';
my $CF = RT::CustomField->new( $RT::SystemUser );
$CF->LoadByNameAndQueue( Name => $CFName, Queue => $Ticket->Queue );
# RT has bug/feature until 3.0.10, you should load global CF yourself
unless( $CF->id ) {
# queue 0 is special case and is a synonym for global queue
$CF->LoadByNameAndQueue( Name => $CFName, Queue => '0' );
}

unless( $CF->id ) {
$RT::Logger->error( "No field $CFName in queue ". $Ticket->QueueObj->Name );
return undef;
}
...
</pre>

Now we could add value to ticket:
<pre>
my $Value = 'MyValue';
$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value );
</pre>
or
<pre>
$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value, RecordTransaction => 0 );
</pre>
you also could use custom field id instead of object.
<pre>
$Ticket->AddCustomFieldValue( Field => NN , Value => $Value );
</pre>

== Step by step or "Tickets, transactions and attachments" ==

Lets look what happens with RT from the beginning when a user clicks on create button in their browser. Web server gets request with queue id, ticket subject and body, owner and etc. RT fetches info from the request that is needed for Ticket record: its Queue id, Status, Subject, [[CurrentUser]](Creator), and then runs the next code:

<pre>
# init empty instance of RT::Ticket class
my $TicketObj = RT::Ticket->new( $session{'CurrentUser'} );

# create new record
# if you more familiar with SQL then it's INSERT
# this call is inherited from SearchBuilder API
my $id = $TicketObj->Create( %ARGS );

</pre>

Ticket is created and it's time to record transaction into table. RT has all info for this: ticket's id that was recently created and transaction type - 'Create'.

<pre>
# this call creates new transaction record
# this is very similar to situation with new ticket record
my $TransactionObj = $Ticket->_RecordTransaction( %ARGS );

</pre>

Transactions in RT has an many-to-one mapping with ticket. One ticket => one or more transactions. You can get collection of transactions by calling Transactions method on a ticket object:
<pre>
my $transactions = $TicketObj->Transactions;
</pre>
Each transaction belongs to only one ticket and you get ticket object with the following code:
<pre>
my $ticket = $TransactionObj->TicketObj;
</pre>
As you can see RT still didn't use content that you wrote in the body. Content is an RT::Attachment object. You know how RT creates new record and know about Ticket-Transaction relation, the same relationship applies to Attachments and Transactions.

== From "User Defined" to a module ==

User defined actions you write in the web UI are handy and quick way to write an action. However, at some point you want to re-use your action, make it configurable, edit it in more suitable editor rather than text area, make it more complex and consist of additional methods. So it's time to move from "User Defined" action to your first module file.

<pre>

use strict;
use warnings;

package RT::Action::MyAction;
use base qw(RT::Action::Generic);

sub Prepare {
my $self = shift;

... here goes preparation code ...

return 1;
}

sub Commit {
my $self = shift;

... here goes commit code ...

return 1;
}

1;

</pre>

That's it. Save it as '''lib/RT/Action/MyAction.pm''' (it is important that the file have the same name as the package ("MyAction" in the example)), fill in preparation and commit code then you can register your action in the DB. Use the following data file and [[AddDatabaseRecords]] instructions.

<pre>

@ScripActions = (
{
Name => 'My super duper action',
Description => 'Super-puper action that does hell of a job' ,
ExecModule => 'MyAction',
Argument => 'some argument if needed'
},
);

</pre>

Now your action in the DB and you can pick it for a scrip through the Web UI instead of picking "User Defined".

== See also ==

Other documentation on this wiki that may help

[[GlobalObjects]], [[ObjectModel]]

== Special thanks ==

* [[TimWilson]], who was the main editor and reviewer