Change ticket subject before first outgoing correspondence

RT Users
1

So I have a scrip which runs at at the TransactionCreate stage for a
queue, checks the subject and the body, and then rewrites the subject
to something informative.

It works; when I look at the ticket for inbound emails matching the
condition, the subject is precisely what I want it to be.

Except that the first outgoing email is sent before the subject is
rewritten; in my inbox, the message still reflects the original title.
This happens whether I put my scrip’s action code in the prepare or
cleanup stages.

From an external perspective, this is what the sequence looks like:

  1. RT receives an email with a subject of “Foo” and a body of “Bar\nBaz”
  2. RT sends me an email with a subject of “[queuename #999] Foo” and a
    boxy including “Bar\nBaz”
  3. I look at queuename #999, and I see a ticket with subject of Bar – Baz.

While what I want to happen is:

  1. RT receives an email with a subject of “Foo” and a body of “Bar\nBaz”
  2. RT sends me an email with a subject of “queuename #999] Bar – Baz”
  3. I look at queuename #999, and I see a ticket with a subject of Bar – Baz.

How do I get that first email to reflect the desired ticket subject?

:wq

2

You can adjust the order in which scrips run by moving them up and down in
the list.

I’m guessing that both scrips have the “on create” condition. Simply swap
their order on the queue’s Scrips page (or the global one if necessary),
and I believe everything should work as you expect.On 7 August 2014 22:52, Michael Mol mikemol@gmail.com wrote:

So I have a scrip which runs at at the TransactionCreate stage for a
queue, checks the subject and the body, and then rewrites the subject
to something informative.

It works; when I look at the ticket for inbound emails matching the
condition, the subject is precisely what I want it to be.

Except that the first outgoing email is sent before the subject is
rewritten; in my inbox, the message still reflects the original title.
This happens whether I put my scrip’s action code in the prepare or
cleanup stages.

From an external perspective, this is what the sequence looks like:

  1. RT receives an email with a subject of “Foo” and a body of “Bar\nBaz”
  2. RT sends me an email with a subject of “[queuename #999] Foo” and a
    boxy including “Bar\nBaz”
  3. I look at queuename #999, and I see a ticket with subject of Bar – Baz.

While what I want to happen is:

  1. RT receives an email with a subject of “Foo” and a body of “Bar\nBaz”
  2. RT sends me an email with a subject of “queuename #999] Bar – Baz”
  3. I look at queuename #999, and I see a ticket with a subject of Bar –
    Baz.

How do I get that first email to reflect the desired ticket subject?

–
:wq

RT Training - Boston, September 9-10
http://bestpractical.com/training

3

Actually, I’m second-guessing my (untested) advice now because I suspect
that both scrips would run on the initial transaction—that is, the emailing
scrip might not necessarily pick up on the subject change because that
would be a different transaction.

I wonder whether both moving the subject-renaming scrip to execute first,
and modifying the emailing scrip to run at the “batch” stage might solve
your problem.On 8 August 2014 00:55, Alex Peters alex@peters.net wrote:

You can adjust the order in which scrips run by moving them up and down in
the list.

I’m guessing that both scrips have the “on create” condition. Simply swap
their order on the queue’s Scrips page (or the global one if necessary),
and I believe everything should work as you expect.

On 7 August 2014 22:52, Michael Mol mikemol@gmail.com wrote:

So I have a scrip which runs at at the TransactionCreate stage for a
queue, checks the subject and the body, and then rewrites the subject
to something informative.

It works; when I look at the ticket for inbound emails matching the
condition, the subject is precisely what I want it to be.

Except that the first outgoing email is sent before the subject is
rewritten; in my inbox, the message still reflects the original title.
This happens whether I put my scrip’s action code in the prepare or
cleanup stages.

From an external perspective, this is what the sequence looks like:

  1. RT receives an email with a subject of “Foo” and a body of “Bar\nBaz”
  2. RT sends me an email with a subject of “[queuename #999] Foo” and a
    boxy including “Bar\nBaz”
  3. I look at queuename #999, and I see a ticket with subject of Bar –
    Baz.

While what I want to happen is:

  1. RT receives an email with a subject of “Foo” and a body of “Bar\nBaz”
  2. RT sends me an email with a subject of “queuename #999] Bar – Baz”
  3. I look at queuename #999, and I see a ticket with a subject of Bar –
    Baz.

How do I get that first email to reflect the desired ticket subject?

–
:wq

RT Training - Boston, September 9-10
http://bestpractical.com/training

4

I wonder whether both moving the subject-renaming scrip to execute first, and
modifying the emailing scrip to run at the “batch” stage might solve your
problem.

While it’s possible to alter the Autoreply template to fetch the newer
subject, making the On Create Autoreply to Requestors Scrip be in the
Batch stage is the easier and correct solution.

Batch scrips are executed after all other Scrips, so ordering them is
irrelevant.

-kevin

5

I wonder whether both moving the subject-renaming scrip to execute first, and
modifying the emailing scrip to run at the “batch” stage might solve your
problem.

While it’s possible to alter the Autoreply template to fetch the newer
subject, making the On Create Autoreply to Requestors Scrip be in the
Batch stage is the easier and correct solution.

Batch scrips are executed after all other Scrips, so ordering them is
irrelevant.

I don’t have an On Create Autoreply to Requestors scrip. I think I
deleted it early, early on in this install since root@somebox doesn’t
need a reply when some cron job or management agent generates an email
from that address.

I did go through and set every scrip with a Notify action to run
during the TransactionBatch stage, but that had no effect. (Setting
them to Disabled does result in my not receiving an email; I’m on the
AdminCC for all created tickets).

I tried some things in response to Alex’s emails, and replied, but
didn’t realize those weren’t going to the list. I’ll reproduce that
(or the gist of it) below:

  • Scrip re-ordering appears to be a feature of the 4.2 line of RT. I’m
    running the vendor packages of RT 4 on Ubuntu 14.04.

  • I looked into upgrading, but I did not find any repositories making
    backported packages available to 14.04. Pity; I selected 14.04 so I
    wouldn’t have to override the system as often.

  • Even though I can’t reorder scrips, I can create disable global
    scrips and create local scrips with the same name, resulting in a
    higher ID number (and theoretically later execution). However, this
    has no apparent effect, regardless of whether I run the overriding
    Notify scrips in the TransactionCreate or TransactionBatch stages.

I’m beginning to wonder if I need to set something beyond just the
ticket subject in my scrip. The scrip doing the work in question will
look familiar:

Begin snippet

Find the message from transactionobj->content

Set the subject to the message by using ticketobj->SetSubject

my $body = $self->TransactionObj->Content;
my @lines = split(m/\n/, $body);
my $trapID = $lines[0];
my $message = $lines[2];

$RT::Logger->warn("Setting RT ticket subject: " . “$trapID – $message”);

$self->TicketObj->SetSubject(“$trapID – $message”);

End snippet

My last option appears to be to write a template that duplicates the
above logic in the template itself, which feels dirty, and looks
worse…

:wq

6

[snip]

Begin snippet

Find the message from transactionobj->content

Set the subject to the message by using ticketobj->SetSubject

my $body = $self->TransactionObj->Content;
my @lines = split(m/\n/, $body);
my $trapID = $lines[0];
my $message = $lines[2];

$RT::Logger->warn("Setting RT ticket subject: " . “$trapID – $message”);

$self->TicketObj->SetSubject(“$trapID – $message”);

End snippet

My last option appears to be to write a template that duplicates the
above logic in the template itself, which feels dirty, and looks
worse…

For completeness and google-worthy archives, here’s the Template that
works. It’s a queue-specific template with the name “Transaction”:

Begin snippet

RT-Attach-Message: yes

if ( $Ticket->Subject eq “HP Insight Management Agents Trap Alarm” ) {
my $body = $self->TransactionObj->Content;
my @lines = split(m/\n/, $body);
my $trapID = $lines[0];
my $message = $lines[2];

$subject = "$trapID -- $message";

} else {
$subject = $Ticket->Subject;
}
$subject; # Return the subject out of the code block, and thus into
the template body.
}

<URL: {RT->Config->Get(‘WebURL’)}Ticket/Display.html?id={$Ticket->id} >

{$Transaction->Content()}

End snippet

It needs to be combined with the above Scrip for full effectiveness,
if you want the ticket subject to be reflected in the email.

I’m tempted to drill down deeper and parse out $trapID and make it
it’s own header; the content is always something like “Trap-ID=3047”
or “Trap-ID=11020”, and I could make the template add a header of
“X-Trap-ID: 3047”, but that would serve no useful purpose at this
time. OTOH, if I created more custom fields for the queue, I could
dump each of those individually into headers. But, again, not
immediately useful, so not doing that, regardless of how cool it’d be.
Maybe after I implement sieve on our mailservers…

:wq

7
  • Scrip re-ordering appears to be a feature of the 4.2 line of RT. I’m
    running the vendor packages of RT 4 on Ubuntu 14.04.

Nope. On RT 4.0, which is what I assume you mean by “vendor packages RT
4 on Ubuntu 14.04” you order scrips by their descriptions. Typically
this is done by literally numbering scrips that will run in the same
condition.

  • I looked into upgrading, but I did not find any repositories making
    backported packages available to 14.04. Pity; I selected 14.04 so I
    wouldn’t have to override the system as often.

Debian has 4.2 packages available in testing, encouraging Ubuntu to
take upgrades would be helpful.

  • Even though I can’t reorder scrips, I can create disable global
    scrips and create local scrips with the same name, resulting in a
    higher ID number (and theoretically later execution). However, this
    has no apparent effect, regardless of whether I run the overriding
    Notify scrips in the TransactionCreate or TransactionBatch stages.

ID number has nothing to do with ordering.

I’m beginning to wonder if I need to set something beyond just the
ticket subject in my scrip. The scrip doing the work in question will
look familiar:

My last option appears to be to write a template that duplicates the
above logic in the template itself, which feels dirty, and looks
worse…

You still haven’t said what the Scrip is that isn’t firing, both Alex
and I assumed it was your Autoreply to Requestors because you were
unclear.

I’ve certainly modified a subject in a Scrip and then had an Autoreply
fire with the correct subject by using a TransactionBatch scrip.

Keep in mind, if you make all your Notify scrips TransactionBatch,
they will no longer show up in the Preview Scrips box.

I’ve seen your rewritten template, but a Notify scrip running in the
transaction batch stage which has merely

should be more than sufficient, assuming it runs after your Subject
modification scrip, preferably in a TransactionBatch scrip on the same
Condition.

-kevin

8
  • Scrip re-ordering appears to be a feature of the 4.2 line of RT. I’m
    running the vendor packages of RT 4 on Ubuntu 14.04.

Nope. On RT 4.0, which is what I assume you mean by “vendor packages RT
4 on Ubuntu 14.04” you order scrips by their descriptions. Typically
this is done by literally numbering scrips that will run in the same
condition.

Oh, that’s good to know! I searched for at least an hour trying to
find that precise piece of information.

  • I looked into upgrading, but I did not find any repositories making
    backported packages available to 14.04. Pity; I selected 14.04 so I
    wouldn’t have to override the system as often.

Debian has 4.2 packages available in testing, encouraging Ubuntu to
take upgrades would be helpful.

I don’t think it’s likely for 14.04, which is an LTS. If 4.2 is in
Debian/testing, then it should show up in Ubuntu 14.10, at which point
a backports repository traditionally appears. So I’d guess that RT 4.2
will become available to Ubuntu 14.04 users in a few months.

  • Even though I can’t reorder scrips, I can create disable global
    scrips and create local scrips with the same name, resulting in a
    higher ID number (and theoretically later execution). However, this
    has no apparent effect, regardless of whether I run the overriding
    Notify scrips in the TransactionCreate or TransactionBatch stages.

ID number has nothing to do with ordering.

I’m beginning to wonder if I need to set something beyond just the
ticket subject in my scrip. The scrip doing the work in question will
look familiar:

My last option appears to be to write a template that duplicates the
above logic in the template itself, which feels dirty, and looks
worse…

You still haven’t said what the Scrip is that isn’t firing, both Alex
and I assumed it was your Autoreply to Requestors because you were
unclear.

Custom condition, matching the ticket subject and queue name. (The
latter being redundant, since it’s a queue-specific scrip.)

The scrip does fire, as evidenced by the ticket’s subject changing.
However, the AdminCC emails go out before the scrip fires. This is
true even though I have all of the Notify scrips in the
TransactionBatch stage, even though I have this scrip in the
TransactionCreate stage.

Here: (The queue name has been replaced with “somequeuename”)

Begin snippet for custom condition

return 0 unless $self->TransactionObj->Type eq “Create”;
return 0 unless $self->TicketObj->QueueObj->Name eq “somequeuename”;

return 1 if $self->TicketObj->Subject =~ “HP Insight Management Agents
Trap Alarm”;

return 1 if $self->TicketObj->Subject =~ “HP Agent Trap Alert”;

return 0;

End snippet for custom condition

Begin snippet for custom action preparation code

Find the message from transactionobj->content

Set the subject to the message by using ticketobj->SetSubject

my $body = $self->TransactionObj->Content;
my @lines = split(m/\n/, $body);
my $trapID = $lines[0];
my $message = $lines[2];

$self->TicketObj->SetSubject(“$trapID – $message”);

End snippet for custom action preparation code

Begin snippet for custom action cleanup code

No cleanup necessary; all the work was done in the prep stage.

return 1;

End snippet for custom action cleanup code

I’ve certainly modified a subject in a Scrip and then had an Autoreply
fire with the correct subject by using a TransactionBatch scrip.

Keep in mind, if you make all your Notify scrips TransactionBatch,
they will no longer show up in the Preview Scrips box.

I’ve seen your rewritten template, but a Notify scrip running in the
transaction batch stage which has merely

Subject: { $Ticket->Subject }

should be more than sufficient, assuming it runs after your Subject
modification scrip, preferably in a TransactionBatch scrip on the same
Condition.

Interesting. Where does the subject come from, if not
$Ticket->Subject? (I guess I could just look at the source code for
that.)

:wq

9

I have a question related to this thread.

Kevin you mention that scrips fire in order of name so does that mean when the order is set for a queue this is ignored? If so what is the purpose of the “Move Up, Down” for the scrips on a queue?

Thanks

Sorry for butting in.

Bryon Baker
Network Operations Manager
Copesan - Specialists in Pest Solutions
800-267-3726 . 262-783-6261 ext. 2296
bbaker@copesan.com

"Servicing North America with Local Care"From: rt-users [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Kevin Falcone
Sent: Monday, August 11, 2014 10:09 AM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Change ticket subject before first outgoing correspondence.

  • Scrip re-ordering appears to be a feature of the 4.2 line of RT. I’m
    running the vendor packages of RT 4 on Ubuntu 14.04.

Nope. On RT 4.0, which is what I assume you mean by “vendor packages RT
4 on Ubuntu 14.04” you order scrips by their descriptions. Typically this is done by literally numbering scrips that will run in the same condition.

  • I looked into upgrading, but I did not find any repositories making
    backported packages available to 14.04. Pity; I selected 14.04 so I
    wouldn’t have to override the system as often.

Debian has 4.2 packages available in testing, encouraging Ubuntu to take upgrades would be helpful.

  • Even though I can’t reorder scrips, I can create disable global
    scrips and create local scrips with the same name, resulting in a
    higher ID number (and theoretically later execution). However, this
    has no apparent effect, regardless of whether I run the overriding
    Notify scrips in the TransactionCreate or TransactionBatch stages.

ID number has nothing to do with ordering.

I’m beginning to wonder if I need to set something beyond just the
ticket subject in my scrip. The scrip doing the work in question will
look familiar:

My last option appears to be to write a template that duplicates the
above logic in the template itself, which feels dirty, and looks
worse…

You still haven’t said what the Scrip is that isn’t firing, both Alex and I assumed it was your Autoreply to Requestors because you were unclear.

I’ve certainly modified a subject in a Scrip and then had an Autoreply fire with the correct subject by using a TransactionBatch scrip.

Keep in mind, if you make all your Notify scrips TransactionBatch, they will no longer show up in the Preview Scrips box.

I’ve seen your rewritten template, but a Notify scrip running in the transaction batch stage which has merely

Subject: { $Ticket->Subject }

should be more than sufficient, assuming it runs after your Subject modification scrip, preferably in a TransactionBatch scrip on the same Condition.

-kevin

10

I have a question related to this thread.

Kevin you mention that scrips fire in order of name so does that mean when the order is set for a queue this is ignored? If so what is the purpose of the “Move Up, Down” for the scrips on a queue?

Thanks

Sorry for butting in.

No; scrip-order-by-name does not apply to RT 4.2. If you have “Move
Up, Down” buttons, you don’t need to worry about order-by-name. I’m
dealing with an older version of RT, which is why the order-by-name
stuff came up.

:wq

11

Oh, that’s good to know! I searched for at least an hour trying to
find that precise piece of information.

It is all over the mailing list archives, answered at last monthly
these days. It should also be in the wiki.

Begin snippet for custom action preparation code

Find the message from transactionobj->content

Set the subject to the message by using ticketobj->SetSubject

my $body = $self->TransactionObj->Content;
my @lines = split(m/\n/, $body);
my $trapID = $lines[0];
my $message = $lines[2];

$self->TicketObj->SetSubject(“$trapID – $message”);

End snippet for custom action preparation code

Begin snippet for custom action cleanup code

No cleanup necessary; all the work was done in the prep stage.

return 1;

End snippet for custom action cleanup code

This is dangerous. RT executes the Prepare during scrip prep without
doing the Commit. You should never make changes in the Prepare.

I’ve seen your rewritten template, but a Notify scrip running in the
transaction batch stage which has merely

Subject: { $Ticket->Subject }

should be more than sufficient, assuming it runs after your Subject
modification scrip, preferably in a TransactionBatch scrip on the same
Condition.

Interesting. Where does the subject come from, if not
$Ticket->Subject? (I guess I could just look at the source code for
that.)

Have you tried my suggestion yet?

The answer is, at best, complicated.

-kevin

12

Oh, that’s good to know! I searched for at least an hour trying to
find that precise piece of information.

It is all over the mailing list archives, answered at last monthly
these days. It should also be in the wiki.

The best I can say is that I loathe having to ask questions of
mailing lists and IRC channels, as I expect to get answers like this.
I seriously hate getting replies intoning that the information is
readily available, so I do the best I can using Google and reading all
the available documentation I can find. I may have spent more than an
hour looking for that precise piece of information, but I spent more
than a week digging through all the available documentation on the
wiki and BestPractical’s website docs. The wiki consists primarily of
tutorials.

If it’s in the mailing list archives, either my google-fu must be
weakening, google unhelpfully directed me toward the wrong resources
based on search history, or I didn’t have the right keywords.
“requesttracker scrip ordering” didn’t get me anywhere.

I apologize if I’m a bit bristly, but I’ve always spent at least
several hours searching and reading before opening a thread on a
mailing list or IRC channel, because I hate “RTFM” or “LMGTFY”
responses.

Begin snippet for custom action preparation code

Find the message from transactionobj->content

Set the subject to the message by using ticketobj->SetSubject

my $body = $self->TransactionObj->Content;
my @lines = split(m/\n/, $body);
my $trapID = $lines[0];
my $message = $lines[2];

$self->TicketObj->SetSubject(“$trapID – $message”);

End snippet for custom action preparation code

Begin snippet for custom action cleanup code

No cleanup necessary; all the work was done in the prep stage.

return 1;

End snippet for custom action cleanup code

This is dangerous. RT executes the Prepare during scrip prep without
doing the Commit. You should never make changes in the Prepare.

Good to know. I did not find documentation describing the precise
processing behavior of RT scrips.

I’ve seen your rewritten template, but a Notify scrip running in the
transaction batch stage which has merely

Subject: { $Ticket->Subject }

should be more than sufficient, assuming it runs after your Subject
modification scrip, preferably in a TransactionBatch scrip on the same
Condition.

Interesting. Where does the subject come from, if not
$Ticket->Subject? (I guess I could just look at the source code for
that.)

Have you tried my suggestion yet?

The answer is, at best, complicated.

I have not. I have something that works (though I’ll be sure to move
my code from Prepare to Cleanup), and I’m not in a rush to change that
with as much as I have on my plate. I have another pattern of emails I
want to process similarly (certain cron job messages), so I’ll give it
a try there and follow up if I can.

:wq

13

The best I can say is that I loathe having to ask questions of
mailing lists and IRC channels, as I expect to get answers like this.
I seriously hate getting replies intoning that the information is
readily available, so I do the best I can using Google and reading all
the available documentation I can find. I may have spent more than an
hour looking for that precise piece of information, but I spent more
than a week digging through all the available documentation on the
wiki and BestPractical’s website docs. The wiki consists primarily of
tutorials.

Found in the second hit on the wiki after typing Scrip into the search
box.
http://requesttracker.wikia.com/wiki/ScripExecOrder
Should be updated to reflect 4.2, but such is life.

Trivially testable too.
Condition: ON Create
Action: User Defined
Prepare: 1;
Commit: RT->Logger->error(“I’m the first scrip”);
Template: Blank

That’s as much time as I have this week to search the wiki
and mailing list archives for things I’ve written.

I apologize if I’m a bit bristly, but I’ve always spent at least
several hours searching and reading before opening a thread on a
mailing list or IRC channel, because I hate “RTFM” or “LMGTFY”
responses.

I actually generally don’t bother answering questions that I’ve
answered within the last two weeks. This was an exception because I
saw things being led astray.

Good to know. I did not find documentation describing the precise
processing behavior of RT scrips.

Patches welcome.

-kevin

14

The best I can say is that I loathe having to ask questions of
mailing lists and IRC channels, as I expect to get answers like this.
I seriously hate getting replies intoning that the information is
readily available, so I do the best I can using Google and reading all
the available documentation I can find. I may have spent more than an
hour looking for that precise piece of information, but I spent more
than a week digging through all the available documentation on the
wiki and BestPractical’s website docs. The wiki consists primarily of
tutorials.

Found in the second hit on the wiki after typing Scrip into the search
box.
http://requesttracker.wikia.com/wiki/ScripExecOrder
Should be updated to reflect 4.2, but such is life.

Trivially testable too.
Condition: ON Create
Action: User Defined
Prepare: 1;
Commit: RT->Logger->error(“I’m the first scrip”);
Template: Blank

So, there’s my problem. I didn’t use Wikia’s search field for that
particular query, I used raw Google and DuckDuckgo. (Well, could also
be because I didn’t use a simple enough query, but such is life.)

This particular wiki’s search functionality is more useful than the
built-in search features of the vast majority out there. Noted.

That’s as much time as I have this week to search the wiki
and mailing list archives for things I’ve written.

I apologize if I’m a bit bristly, but I’ve always spent at least
several hours searching and reading before opening a thread on a
mailing list or IRC channel, because I hate “RTFM” or “LMGTFY”
responses.

I actually generally don’t bother answering questions that I’ve
answered within the last two weeks. This was an exception because I
saw things being led astray.

Fair enough.

Good to know. I did not find documentation describing the precise
processing behavior of RT scrips.

Patches welcome.

Knowing the processing behavior is the first step to being able to author one.

:wq