From Request Tracker Wiki
Jump to: navigation, search


This is all about manipulating ticket's fields via email

Security considerations

NOTE: RT needs an authentication infrastructure to do this safely. GPG verification of signatures and decryption is implemented in RT 3.8.

Full access using an extension

Use "command by mail" extension, see Extensions

A few actions using custom email addresses

RT 3.5 has support for take and resolve actions in rt-mailgate script, you can use them, but you should enable them in config.

Simple scrips to do only some things

Below you can find examples and hints on writing a parser of emails and changing properties of tickets.

The following code donated by RuslanZakirov was tested as working on RT 3.2.2.

This allows you to Set-Status and Set-Owner via email on a fault.

I have the following in Custom Action Preparation Code of a Correspondence Scrip.

1; my $AttachObj = $self->TransactionObj->Attachments->First; # go out if content is not text! unless( $AttachObj->ContentType =~ /^text/ ) { <code><pre> return 1; </pre></code> } my $content = $AttachObj->Content; if( $content =~ m/^\QSet-Owner:\E\s<em>(\S+)\s</em>$/m ) { <code><pre> $self-&gt;TicketObj-&gt;SetOwner( $1 ); </pre></code> } if( $content =~ m/^\QSet-Status:\E\s<em>(\S+)\s</em>$/m ) { <code><pre> $self-&gt;TicketObj-&gt;SetStatus( $1 ); </pre></code> } # strip special commands from email content $content =~ s/^\QSet-Status:\E\s<em>(\S+)\s</em>$//gm; $content =~ s/^\QSet-Owner:\E\s<em>(\S+)\s</em>$//gm; # silently overwrite attachment content $AttachObj->__Set( Field => 'Content', Value => $content ); 1;

I then have a normal Scrip AFTER this that executes of On Correspond Requestors and CC's Template Correspondece.

This code allows you then to

Set-Owner: owner

Set-Status: resolved

by email with the above in the first line of the message body and the email will then be sent to the user missing these lines, so I'd advise using it as part of your resolution work on a fault. 26/1/05 Elaine

2005-02-04 - Moose After installing this code, I found that replying to a "new" ticket and resolving it would cause it to open up again afterwards. The solution is to disable the OnCorrespond Scrip that sets status to open, and install a custom Scrip (a quick mod from the original), with the Template Blank:

1; my $AttachObj = $self->TransactionObj->Attachments->First; # go out if content is not text! unless( $AttachObj->ContentType =~ /^text/ ) { <code><pre> $self-&gt;TicketObj-&gt;SetStatus( "open" ); </pre></code> } my $content = $AttachObj->Content; if( $content =~ m/^\QSet-Owner:\E\s<em>(\S+)\s</em>$/m ) { # do nothing } else if( $content =~ m/^\QSet-Status:\E\s<em>(\S+)\s</em>$/m ) { # do nothing } else if( $content =~ m/^\QAction:\E\s<em>(\S+)\s</em>$/m ) { # do nothing } else $self->TicketObj->SetStatus( "open" ); 1;

The "Action:" entry is what a previous ticketing system used to use rather than "Set-Status" - old habits are hard to break.

2006-06-09 - Reenen Kroukamp

To prevent the "new" ticket problem as described above (2005-02-04 - Moose), I have done the following:


I then selected the script with the action which sets the ticket status to open for 'On Correspond', and changed it to:

Description: Open on correspond or set email action

Condition:     On Correspond
Action:    User Defined
Template:  Global Template: Blank
Stage:     TransactionCreate

I then added the following "Custom action preparation code" for it:

my $AttachObj = $self->TransactionObj->Attachments->First; # If not text, just set to open as per normal unless( $AttachObj->ContentType =~ /^text/ ) { $self->TicketObj->SetStatus( "open" ); return 1; } my $content = $AttachObj->Content; unless ( $content =~ m/^\Qset-\E\S+:\s<em>(\S+)\s</em>$/im ) { $self->TicketObj->SetStatus( "open" ); return 1; } if ( $content =~ s/^\Qset-owner:\E\s<em>(\S+)\s</em>$//im ) { $self->TicketObj->SetOwner( $1 ); } if ( $content =~ s/^\Qset-status:\E\s<em>(\S+)\s</em>$//im ) { $self->TicketObj->SetStatus( $1 ); } # silently overwrite attachment content $AttachObj->__Set( Field => 'Content', Value => $content ); 1;

You can now use set-owner and set-status anywhere in the correspondence, as long as it does not contain any whitespace before it on the same line. Eg, to respond via email, at the same time taking and then resolving a request, you could do:

Your request has been done.

set-status: resolved
set-owner: yourlogin

The scrip strips out the "set-status:" and "set-owner:" commands, applies them, and the reply is sent to the requestor. Tested and confirmed working on a stock standard request-tracker3.4 install on Debian Sarge.

2005-02-04 - Bjørn Skovlund Rydén I needed to set a Custom Field called "Severity" from mails etc. and came up with this:

my $attachs = $self->TransactionObj->Attachments; my $attach; while( my $a = $attachs->Next ) { if( $a->ContentType eq 'text/plain' ) { $attach = $a; last } } unless ($attach) { unless ( $attach = $self->TransactionObj->Attachments->First ) { return 1; } unless( $attach->ContentType =~ /^text/ ) { return 1; } } my $content = $attach->Content; if( $content =~ m/^\QSet-Severity:\E\s<em>(\S+)\s</em>$/m ) { my $CFName = 'Severity'; my $Severity = $1; my $DefaultValue = 'myDefValue'; my $RecTransaction = 1; my $QueueObj = $self->TicketObj->QueueObj; my $CFObj = RT::CustomField->new( $QueueObj->CurrentUser ); $CFObj->LoadByNameAndQueue( Name => $CFName, Queue => $QueueObj->id ); unless( $CFObj->id ) { $CFObj->LoadByNameAndQueue( Name => $CFName, Queue => 0 ); unless( $CFObj->id ) { $RT::Logger->crit( "SCRIP: Set fields :: $CFName doesn't exist, Queue -". $QueueObj->Name ."-" ); return undef; } } unless( $self->TicketObj->FirstCustomFieldValue( $CFObj->id ) ) { my( $st, $msg ) = $self->TicketObj->AddCustomFieldValue( Field => $CFObj->id, Value => $Severity, RecordTransaction => $RecTransaction ); unless( $st ) { $RT::Logger->crit( "SCRIP: Set fields :: Couldn't set $Severity as value for CF $CFName:". $msg ); return undef; } } } $content =~ s/^\QSet-Severity:\E\s<em>(\S+)\s</em>$//gm; # silently overwrite attachment content $attach->__Set( Field => 'Content', Value => $content );

It should work with both plain and rich texts. It can probably be optimized a great deal, but it works as is :)

Set ticket properties through mail are all about the manipulation of ticket fields through our email id. This needs an authentication infrastructure to do this work very safely. It verifies the signatures and decrypts the mail by using RT 3.8. For full access they use command by mail as extension.