[rt-users] Scrip failure following 3.8.1 -> 3.8.8 upgrade
falcone at bestpractical.com
Wed Aug 18 12:21:42 EDT 2010
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
More information about the rt-users