Scrip failure following 3.8.1 -> 3.8.8 upgrade

RT Users
1

We’ve just upgraded our RT installation from 3.8.1 to 3.8.8 and it
mostly went very seamlessly.

However, since making the new version live I’ve noticed that one of our
global Scrips has stopped working.

The scrip reads:

Description: Open on take
Condition: User defined
Action: Open Tickets
Template: Global template: Blank
Stage: TransactionCreate

Custom Condition:
if ($self->TicketObj->Status eq ‘new’ && $self->TransactionObj->Type eq
‘Take’)
{
return 1;
}
else
{
return undef;
}

So, a fairly simple Scrip to ‘Open’ a ticket when it’s taken by someone.
However, since the upgrade to 3.8.8 it has stopped working.

Any idea what could be causing it? I don’t see anything applicable in RT
or Apache logs…

Cheers,

John.

[Apologies for the horrible disclaimer, it’s out of my hands]

John Beranek, Senior Software Engineer, Engineering Tools Group
Pace plc. Tel: +44 1274 538356
Victoria Road, Saltaire, Shipley Fax: +44 1274 538056
West Yorkshire, BD18 3LF, UK. Web: http://www.pace.com/
[Pace plc is registered in England and Wales #1672847]

This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Pace plc is registered in England and Wales (Company no. 1672847) and our Registered Office is at Victoria Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274 532000 Fax +44 (0) 1274 532010. http://www.pace.com
Save where otherwise agreed in writing between you and Pace (i) all orders for goods and/or services placed by you are made pursuant to Pace’s standard terms and conditions of sale which may have been provided to you, or in any event are available at CommScope | now meets next (ii) all orders for goods and/or services placed by Pace are subject to Pace’s standard terms and conditions of purchase which may have been provided to you, or in any event are available at CommScope | now meets next. All other inconsistent terms in any other documentation including without limitation any purchase order, reschedule instruction, order acknowledgement, delivery note or invoice are hereby excluded.

This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

2

Do you have a “Return 1;” in the Condition and/or Prep code?-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of John
Beranek
Sent: Wednesday, August 18, 2010 9:23 AM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Scrip failure following 3.8.1 → 3.8.8 upgrade

We’ve just upgraded our RT installation from 3.8.1 to 3.8.8 and it
mostly went very seamlessly.

However, since making the new version live I’ve noticed that one of our
global Scrips has stopped working.

The scrip reads:

Description: Open on take
Condition: User defined
Action: Open Tickets
Template: Global template: Blank
Stage: TransactionCreate

Custom Condition:
if ($self->TicketObj->Status eq ‘new’ && $self->TransactionObj->Type eq
‘Take’)
{
return 1;
}
else
{
return undef;
}

So, a fairly simple Scrip to ‘Open’ a ticket when it’s taken by someone.
However, since the upgrade to 3.8.8 it has stopped working.

Any idea what could be causing it? I don’t see anything applicable in RT
or Apache logs…

Cheers,

John.

[Apologies for the horrible disclaimer, it’s out of my hands]

John Beranek, Senior Software Engineer, Engineering Tools Group
Pace plc. Tel: +44 1274 538356
Victoria Road, Saltaire, Shipley Fax: +44 1274 538056
West Yorkshire, BD18 3LF, UK. Web: http://www.pace.com/
[Pace plc is registered in England and Wales #1672847]

This E-mail and any attachments hereto are strictly confidential and
intended solely for the addressee. If you are not the intended addressee
please notify the sender by return and delete the message. You must not
disclose, forward or copy this E-mail or attachments to any third party
without the prior consent of the sender. Pace plc is registered in
England and Wales (Company no. 1672847) and our Registered Office is at
Victoria Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274
532000 Fax +44 (0) 1274 532010. http://www.pace.com
Save where otherwise agreed in writing between you and Pace (i) all
orders for goods and/or services placed by you are made pursuant to
Pace’s standard terms and conditions of sale which may have been
provided to you, or in any event are available at
CommScope | now meets next (ii) all orders for goods and/or
services placed by Pace are subject to Pace’s standard terms and
conditions of purchase which may have been provided to you, or in any
event are available at CommScope | now meets next. All other
inconsistent terms in any other documentation including without
limitation any purchase order, reschedule instruction, order
acknowledgement, delivery note or invoice are hereby excluded.

This message has been scanned for viruses by BlackSpider MailControl -
www.blackspider.com

RT Training in Washington DC, USA on Oct 25 & 26 2010
Last one this year – Learn how to get the most out of RT!

CONFIDENTIALITY NOTICE: The information contained in this email message, including any attachments, may be
privileged, confidential and otherwise protected from disclosure. If the reader of this message is not the
intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this
message, including any attachments, is strictly prohibited. If you have received this email message in
error, please notify the sender by reply email and delete/destroy the email message, including attachments,
and any copies thereof. Although we have taken precautions to minimize the risk of transmitting viruses via
email and attachments thereto, we do not guarantee that either is virus-free, and we accept no liability for
any damages sustained as a result of any such viruses.

3

Do you have a “Return 1;” in the Condition and/or Prep code?

I pasted my Custom condition code in the initial list post - it contains
a ‘return 1;’ in one side of an ‘if’…

Cheers,

John.

John Beranek, Senior Software Engineer, Engineering Tools Group
Pace plc. Tel: +44 1274 538356
Victoria Road, Saltaire, Shipley Fax: +44 1274 538056
West Yorkshire, BD18 3LF, UK. Web: http://www.pace.com/
[Pace plc is registered in England and Wales #1672847]

This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Pace plc is registered in England and Wales (Company no. 1672847) and our Registered Office is at Victoria Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274 532000 Fax +44 (0) 1274 532010. http://www.pace.com
Save where otherwise agreed in writing between you and Pace (i) all orders for goods and/or services placed by you are made pursuant to Pace’s standard terms and conditions of sale which may have been provided to you, or in any event are available at CommScope | now meets next (ii) all orders for goods and/or services placed by Pace are subject to Pace’s standard terms and conditions of purchase which may have been provided to you, or in any event are available at CommScope | now meets next. All other inconsistent terms in any other documentation including without limitation any purchase order, reschedule instruction, order acknowledgement, delivery note or invoice are hereby excluded.

This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

4

We’ve just upgraded our RT installation from 3.8.1 to 3.8.8 and it
mostly went very seamlessly.

However, since making the new version live I’ve noticed that one of our
global Scrips has stopped working.

What happens when you use $RT::Logger->warn to track the Type and
Status? My guess is that the Type is not what you expect.

-kevin

5

We’ve just upgraded our RT installation from 3.8.1 to 3.8.8 and it
mostly went very seamlessly.

However, since making the new version live I’ve noticed that one of our
global Scrips has stopped working.

What happens when you use $RT::Logger->warn to track the Type and
Status? My guess is that the Type is not what you expect.

Hmm, that doesn’t show anything as such (after I get the logging syntax
right)…but I know can see that an error in the log does appear to be
associated with this Scrip:

[Wed Aug 18 14:55:25 2010] [warning]: *** Type: Take Status: new ((eval
5574):1)
[Wed Aug 18 14:55:25 2010] [error]: Template parsing error: Can’t call
method “SubValue” on an undefined value at template line 9.

Now, to see what it thinks it means…

John.

John Beranek, Senior Software Engineer, Engineering Tools Group
Pace plc. Tel: +44 1274 538356
Victoria Road, Saltaire, Shipley Fax: +44 1274 538056
West Yorkshire, BD18 3LF, UK. Web: http://www.pace.com/
[Pace plc is registered in England and Wales #1672847]

This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Pace plc is registered in England and Wales (Company no. 1672847) and our Registered Office is at Victoria Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274 532000 Fax +44 (0) 1274 532010. http://www.pace.com
Save where otherwise agreed in writing between you and Pace (i) all orders for goods and/or services placed by you are made pursuant to Pace’s standard terms and conditions of sale which may have been provided to you, or in any event are available at CommScope | now meets next (ii) all orders for goods and/or services placed by Pace are subject to Pace’s standard terms and conditions of purchase which may have been provided to you, or in any event are available at CommScope | now meets next. All other inconsistent terms in any other documentation including without limitation any purchase order, reschedule instruction, order acknowledgement, delivery note or invoice are hereby excluded.

This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

6

We’ve just upgraded our RT installation from 3.8.1 to 3.8.8 and it
mostly went very seamlessly.

However, since making the new version live I’ve noticed that one of our
global Scrips has stopped working.

What happens when you use $RT::Logger->warn to track the Type and
Status? My guess is that the Type is not what you expect.

Hmm, that doesn’t show anything as such (after I get the logging syntax
right)…but I know can see that an error in the log does appear to be
associated with this Scrip:

[Wed Aug 18 14:55:25 2010] [warning]: *** Type: Take Status: new ((eval
5574):1)
[Wed Aug 18 14:55:25 2010] [error]: Template parsing error: Can’t call
method “SubValue” on an undefined value at template line 9.

OK this second error is actually a red herring, caused by another Scrip
I had created to investigate this problem.

What does fix it is to change the Action to ‘User Defined’ with the code:

$self->TicketObj->Open();

So, the problem seems to be with the “Open Tickets” action…

John.

John Beranek, Senior Software Engineer, Engineering Tools Group
Pace plc. Tel: +44 1274 538356
Victoria Road, Saltaire, Shipley Fax: +44 1274 538056
West Yorkshire, BD18 3LF, UK. Web: http://www.pace.com/
[Pace plc is registered in England and Wales #1672847]

This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Pace plc is registered in England and Wales (Company no. 1672847) and our Registered Office is at Victoria Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274 532000 Fax +44 (0) 1274 532010. http://www.pace.com
Save where otherwise agreed in writing between you and Pace (i) all orders for goods and/or services placed by you are made pursuant to Pace’s standard terms and conditions of sale which may have been provided to you, or in any event are available at CommScope | now meets next (ii) all orders for goods and/or services placed by Pace are subject to Pace’s standard terms and conditions of purchase which may have been provided to you, or in any event are available at CommScope | now meets next. All other inconsistent terms in any other documentation including without limitation any purchase order, reschedule instruction, order acknowledgement, delivery note or invoice are hereby excluded.

This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

7

John,

Just for kicks, try it this way:

Custom Condition:
return ($self->TicketObj->Status eq ‘new’ &&
$self->TransactionObj->Type eq ‘Take’);

I’d be interested if that worked.

Kenn
LBNLOn Wed, Aug 18, 2010 at 8:50 AM, John Beranek john.beranek@pace.com wrote:

On 18/08/10 15:58, John Beranek wrote:

On 18/08/10 15:37, Kevin Falcone wrote:

On Wed, Aug 18, 2010 at 03:23:28PM +0100, John Beranek wrote:

We’ve just upgraded our RT installation from 3.8.1 to 3.8.8 and it
mostly went very seamlessly.

However, since making the new version live I’ve noticed that one of our
global Scrips has stopped working.

What happens when you use $RT::Logger->warn to track the Type and
Status? My guess is that the Type is not what you expect.

Hmm, that doesn’t show anything as such (after I get the logging syntax
right)…but I know can see that an error in the log does appear to be
associated with this Scrip:

[Wed Aug 18 14:55:25 2010] [warning]: *** Type: Take Status: new ((eval
5574):1)
[Wed Aug 18 14:55:25 2010] [error]: Template parsing error: Can’t call
method “SubValue” on an undefined value at template line 9.

OK this second error is actually a red herring, caused by another Scrip
I had created to investigate this problem.

What does fix it is to change the Action to ‘User Defined’ with the code:

$self->TicketObj->Open();

So, the problem seems to be with the “Open Tickets” action…

John.

–
John Beranek, Senior Software Engineer, Engineering Tools Group
Pace plc. Tel: +44 1274 538356
Victoria Road, Saltaire, Shipley Fax: +44 1274 538056
West Yorkshire, BD18 3LF, UK. Web: http://www.pace.com/
[Pace plc is registered in England and Wales #1672847]

This E-mail and any attachments hereto are strictly confidential and
intended solely for the addressee. If you are not the intended addressee
please notify the sender by return and delete the message. You must not
disclose, forward or copy this E-mail or attachments to any third party
without the prior consent of the sender. Pace plc is registered in England
and Wales (Company no. 1672847) and our Registered Office is at Victoria
Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274 532000 Fax
+44 (0) 1274 532010. http://www.pace.com
Save where otherwise agreed in writing between you and Pace (i) all orders
for goods and/or services placed by you are made pursuant to Pace’s standard
terms and conditions of sale which may have been provided to you, or in any
event are available at CommScope | now meets next (ii) all orders
for goods and/or services placed by Pace are subject to Pace’s standard
terms and conditions of purchase which may have been provided to you, or in
any event are available at CommScope | now meets next. All other
inconsistent terms in any other documentation including without limitation
any purchase order, reschedule instruction, order acknowledgement, delivery
note or invoice are hereby excluded.

This message has been scanned for viruses by BlackSpider MailControl -
www.blackspider.com

RT Training in Washington DC, USA on Oct 25 & 26 2010
Last one this year – Learn how to get the most out of RT!

8

We’ve just upgraded our RT installation from 3.8.1 to 3.8.8 and it
mostly went very seamlessly.

However, since making the new version live I’ve noticed that one of our
global Scrips has stopped working.

What happens when you use $RT::Logger->warn to track the Type and
Status? My guess is that the Type is not what you expect.

Hmm, that doesn’t show anything as such (after I get the logging syntax
right)…but I know can see that an error in the log does appear to be
associated with this Scrip:

[Wed Aug 18 14:55:25 2010] [warning]: *** Type: Take Status: new ((eval
5574):1)
[Wed Aug 18 14:55:25 2010] [error]: Template parsing error: Can’t call
method “SubValue” on an undefined value at template line 9.

OK this second error is actually a red herring, caused by another Scrip
I had created to investigate this problem.

What does fix it is to change the Action to ‘User Defined’ with the code:

$self->TicketObj->Open();

So, the problem seems to be with the “Open Tickets” action…

Looking into this further, in lib/RT/Acton/AutoOpen.pm, in the ‘prepare’
function, $self->TransactionObj->IsInbound is coming out as a positive
integer, so the ‘prepare’ function is returning ‘undef’ and the action
isn’t being performed.

This is some change in the behaviour of RT between 3.8.1 and 3.8.8 that
has caught us unawares. Reading into this a bit more, it looks like the
‘Open Tickets’ action was written with a very specific purpose in mind,
to re-open tickets if the requester sends further email. We were not
using the action for this purpose.

So, I guess the appropriate final solution is indeed to use custom
action code in the Scrip.

Cheers,

John.

John Beranek, Senior Software Engineer, Engineering Tools Group
Pace plc. Tel: +44 1274 538356
Victoria Road, Saltaire, Shipley Fax: +44 1274 538056
West Yorkshire, BD18 3LF, UK. Web: http://www.pace.com/
[Pace plc is registered in England and Wales #1672847]

This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Pace plc is registered in England and Wales (Company no. 1672847) and our Registered Office is at Victoria Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274 532000 Fax +44 (0) 1274 532010. http://www.pace.com
Save where otherwise agreed in writing between you and Pace (i) all orders for goods and/or services placed by you are made pursuant to Pace’s standard terms and conditions of sale which may have been provided to you, or in any event are available at CommScope | now meets next (ii) all orders for goods and/or services placed by Pace are subject to Pace’s standard terms and conditions of purchase which may have been provided to you, or in any event are available at CommScope | now meets next. All other inconsistent terms in any other documentation including without limitation any purchase order, reschedule instruction, order acknowledgement, delivery note or invoice are hereby excluded.

This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

9

We’ve just upgraded our RT installation from 3.8.1 to 3.8.8 and it
mostly went very seamlessly.

However, since making the new version live I’ve noticed that one of our
global Scrips has stopped working.

What happens when you use $RT::Logger->warn to track the Type and
Status? My guess is that the Type is not what you expect.

Hmm, that doesn’t show anything as such (after I get the logging syntax
right)…but I know can see that an error in the log does appear to be
associated with this Scrip:

[Wed Aug 18 14:55:25 2010] [warning]: *** Type: Take Status: new ((eval
5574):1)
[Wed Aug 18 14:55:25 2010] [error]: Template parsing error: Can’t call
method “SubValue” on an undefined value at template line 9.

OK this second error is actually a red herring, caused by another Scrip
I had created to investigate this problem.

What does fix it is to change the Action to ‘User Defined’ with the code:

$self->TicketObj->Open();

So, the problem seems to be with the “Open Tickets” action…

Looking into this further, in lib/RT/Acton/AutoOpen.pm, in the ‘prepare’
function, $self->TransactionObj->IsInbound is coming out as a positive
integer, so the ‘prepare’ function is returning ‘undef’ and the action
isn’t being performed.

This implies that the person taking the ticket is also a Requestor,
possibly because you’re creating test tickets.

This is some change in the behaviour of RT between 3.8.1 and 3.8.8 that
has caught us unawares. Reading into this a bit more, it looks like the
‘Open Tickets’ action was written with a very specific purpose in mind,
to re-open tickets if the requester sends further email. We were not
using the action for this purpose.

Check the logic again, it says “If the ticket is the new and this
transaction was from the Requestor, don’t change it to open”

So, I guess the appropriate final solution is indeed to use custom
action code in the Scrip.

If you goal is to always change the status to open with no
restrictions, then yes, one line of custom action is the correct
solution.

-kevin

10

John,

We do the same thing, but our code is this:

Custom Condition Code:

Check for Ticket Status changed to “open”

my $trans = $self->TransactionObj;

return ($trans->Type eq “Status” &&
$trans->NewValue eq “open”);

Custom Prep Code:

set owner if Nobody

my $ticket = $self->TicketObj;
my $trans = $self->TransactionObj;
my $owner_id = $trans->CreatorObj->PrincipalId;

if ($ticket->OwnerObj->Name() eq ‘Nobody’ )
{
$ticket->SetOwner($owner_id, ‘Force’);
}

return 1;

Hope this helps.

Kenn
LBNLOn Wed, Aug 18, 2010 at 9:21 AM, Kevin Falcone falcone@bestpractical.comwrote:

On Wed, Aug 18, 2010 at 05:10:42PM +0100, John Beranek wrote:

On 18/08/10 16:50, John Beranek wrote:

On 18/08/10 15:58, John Beranek wrote:

On 18/08/10 15:37, Kevin Falcone wrote:

On Wed, Aug 18, 2010 at 03:23:28PM +0100, John Beranek wrote:

We’ve just upgraded our RT installation from 3.8.1 to 3.8.8 and it
mostly went very seamlessly.

However, since making the new version live I’ve noticed that one of
our
global Scrips has stopped working.

What happens when you use $RT::Logger->warn to track the Type and
Status? My guess is that the Type is not what you expect.

Hmm, that doesn’t show anything as such (after I get the logging
syntax
right)…but I know can see that an error in the log does appear to be
associated with this Scrip:

[Wed Aug 18 14:55:25 2010] [warning]: *** Type: Take Status: new
((eval
5574):1)
[Wed Aug 18 14:55:25 2010] [error]: Template parsing error: Can’t call
method “SubValue” on an undefined value at template line 9.

OK this second error is actually a red herring, caused by another Scrip
I had created to investigate this problem.

What does fix it is to change the Action to ‘User Defined’ with the
code:

$self->TicketObj->Open();

So, the problem seems to be with the “Open Tickets” action…

Looking into this further, in lib/RT/Acton/AutoOpen.pm, in the ‘prepare’
function, $self->TransactionObj->IsInbound is coming out as a positive
integer, so the ‘prepare’ function is returning ‘undef’ and the action
isn’t being performed.

This implies that the person taking the ticket is also a Requestor,
possibly because you’re creating test tickets.

This is some change in the behaviour of RT between 3.8.1 and 3.8.8 that
has caught us unawares. Reading into this a bit more, it looks like the
‘Open Tickets’ action was written with a very specific purpose in mind,
to re-open tickets if the requester sends further email. We were not
using the action for this purpose.

Check the logic again, it says “If the ticket is the new and this
transaction was from the Requestor, don’t change it to open”

So, I guess the appropriate final solution is indeed to use custom
action code in the Scrip.

If you goal is to always change the status to open with no
restrictions, then yes, one line of custom action is the correct
solution.

-kevin

RT Training in Washington DC, USA on Oct 25 & 26 2010
Last one this year – Learn how to get the most out of RT!

11

[snip]

Looking into this further, in lib/RT/Acton/AutoOpen.pm, in the ‘prepare’
function, $self->TransactionObj->IsInbound is coming out as a positive
integer, so the ‘prepare’ function is returning ‘undef’ and the action
isn’t being performed.

This implies that the person taking the ticket is also a Requestor,
possibly because you’re creating test tickets.

Ah, you’re spot on!

This is some change in the behaviour of RT between 3.8.1 and 3.8.8 that
has caught us unawares. Reading into this a bit more, it looks like the
‘Open Tickets’ action was written with a very specific purpose in mind,
to re-open tickets if the requester sends further email. We were not
using the action for this purpose.

Check the logic again, it says “If the ticket is the new and this
transaction was from the Requestor, don’t change it to open”

Well, I don’t quite understand the logic, because I don’t understand the
significance of “$self->TransactionObj->IsInbound”.

So, I guess the appropriate final solution is indeed to use custom
action code in the Scrip.

If you goal is to always change the status to open with no
restrictions, then yes, one line of custom action is the correct
solution.

Yes, I don’t really think we want the additional logic in AutoOpen at all.

Many thanks for your help.

Cheers,

John.

John Beranek, Senior Software Engineer, Engineering Tools Group
Pace plc. Tel: +44 1274 538356
Victoria Road, Saltaire, Shipley Fax: +44 1274 538056
West Yorkshire, BD18 3LF, UK. Web: http://www.pace.com/
[Pace plc is registered in England and Wales #1672847]

This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Pace plc is registered in England and Wales (Company no. 1672847) and our Registered Office is at Victoria Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274 532000 Fax +44 (0) 1274 532010. http://www.pace.com
Save where otherwise agreed in writing between you and Pace (i) all orders for goods and/or services placed by you are made pursuant to Pace’s standard terms and conditions of sale which may have been provided to you, or in any event are available at CommScope | now meets next (ii) all orders for goods and/or services placed by Pace are subject to Pace’s standard terms and conditions of purchase which may have been provided to you, or in any event are available at CommScope | now meets next. All other inconsistent terms in any other documentation including without limitation any purchase order, reschedule instruction, order acknowledgement, delivery note or invoice are hereby excluded.

This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

12

This is some change in the behaviour of RT between 3.8.1 and 3.8.8 that
has caught us unawares. Reading into this a bit more, it looks like the
‘Open Tickets’ action was written with a very specific purpose in mind,
to re-open tickets if the requester sends further email. We were not
using the action for this purpose.

Check the logic again, it says “If the ticket is the new and this
transaction was from the Requestor, don’t change it to open”

Well, I don’t quite understand the logic, because I don’t understand the
significance of “$self->TransactionObj->IsInbound”.

I know your problem is solved at this point, but if you want to
understand more, Transaction_Overlay.pm contains documentation for
that method.

-kevin

13

[snip[

If you goal is to always change the status to open with no
restrictions, then yes, one line of custom action is the correct
solution.

Yes, I don’t really think we want the additional logic in AutoOpen at all.

Many thanks for your help.

It’s probably worth saying, for the record, that this was nothing to do
with our upgrade from 3.8.1 to 3.8.8.

It was merely me seeing some odd behaviour while testing after the
upgrade and making the assumption that the upgrade broke something. :confused:

John.

John Beranek, Senior Software Engineer, Engineering Tools Group
Pace plc. Tel: +44 1274 538356
Victoria Road, Saltaire, Shipley Fax: +44 1274 538056
West Yorkshire, BD18 3LF, UK. Web: http://www.pace.com/
[Pace plc is registered in England and Wales #1672847]

This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Pace plc is registered in England and Wales (Company no. 1672847) and our Registered Office is at Victoria Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274 532000 Fax +44 (0) 1274 532010. http://www.pace.com
Save where otherwise agreed in writing between you and Pace (i) all orders for goods and/or services placed by you are made pursuant to Pace’s standard terms and conditions of sale which may have been provided to you, or in any event are available at CommScope | now meets next (ii) all orders for goods and/or services placed by Pace are subject to Pace’s standard terms and conditions of purchase which may have been provided to you, or in any event are available at CommScope | now meets next. All other inconsistent terms in any other documentation including without limitation any purchase order, reschedule instruction, order acknowledgement, delivery note or invoice are hereby excluded.

This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

14

This is some change in the behaviour of RT between 3.8.1 and 3.8.8 that
has caught us unawares. Reading into this a bit more, it looks like the
‘Open Tickets’ action was written with a very specific purpose in mind,
to re-open tickets if the requester sends further email. We were not
using the action for this purpose.

Check the logic again, it says “If the ticket is the new and this
transaction was from the Requestor, don’t change it to open”

Well, I don’t quite understand the logic, because I don’t understand the
significance of “$self->TransactionObj->IsInbound”.

I know your problem is solved at this point, but if you want to
understand more, Transaction_Overlay.pm contains documentation for
that method.

Ah, that plus the RT::Action::AutoOpen POD does seem to just about cover
the documentation angle, indeed.

John.

John Beranek, Senior Software Engineer, Engineering Tools Group
Pace plc. Tel: +44 1274 538356
Victoria Road, Saltaire, Shipley Fax: +44 1274 538056
West Yorkshire, BD18 3LF, UK. Web: http://www.pace.com/
[Pace plc is registered in England and Wales #1672847]

This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. Pace plc is registered in England and Wales (Company no. 1672847) and our Registered Office is at Victoria Road, Saltaire, West Yorkshire, BD18 3LF, UK. Tel +44 (0) 1274 532000 Fax +44 (0) 1274 532010. http://www.pace.com
Save where otherwise agreed in writing between you and Pace (i) all orders for goods and/or services placed by you are made pursuant to Pace’s standard terms and conditions of sale which may have been provided to you, or in any event are available at CommScope | now meets next (ii) all orders for goods and/or services placed by Pace are subject to Pace’s standard terms and conditions of purchase which may have been provided to you, or in any event are available at CommScope | now meets next. All other inconsistent terms in any other documentation including without limitation any purchase order, reschedule instruction, order acknowledgement, delivery note or invoice are hereby excluded.

This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com