John,<br><br>We do the same thing, but our code is this:<br><br>Custom Condition Code:<br># Check for Ticket Status changed to "open"<br><br>my $trans = $self->TransactionObj;<br><br>return ($trans->Type eq "Status" &&<br>
          $trans->NewValue eq "open");<br><br><br>Custom Prep Code:<br># set owner if Nobody<br><br>my $ticket = $self->TicketObj;<br>my $trans = $self->TransactionObj;<br>my $owner_id = $trans->CreatorObj->PrincipalId;<br>
<br>if  ($ticket->OwnerObj->Name() eq 'Nobody' )<br>   {<br>    $ticket->SetOwner($owner_id, 'Force');<br>   }<br><br>return 1;<br><br>Hope this helps.<br><br>Kenn<br>LBNL<br><br><div class="gmail_quote">
On Wed, Aug 18, 2010 at 9:21 AM, Kevin Falcone <span dir="ltr"><<a href="mailto:falcone@bestpractical.com">falcone@bestpractical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">On Wed, Aug 18, 2010 at 05:10:42PM +0100, John Beranek wrote:<br>
> On 18/08/10 16:50, John Beranek wrote:<br>
> > On 18/08/10 15:58, John Beranek wrote:<br>
> >> On 18/08/10 15:37, Kevin Falcone wrote:<br>
> >>> On Wed, Aug 18, 2010 at 03:23:28PM +0100, John Beranek wrote:<br>
> >>>> We've just upgraded our RT installation from 3.8.1 to 3.8.8 and it<br>
> >>>> mostly went very seamlessly.<br>
> >>>><br>
> >>>> However, since making the new version live I've noticed that one of our<br>
> >>>> global Scrips has stopped working.<br>
> >>><br>
> >>> What happens when you use $RT::Logger->warn to track the Type and<br>
> >>> Status?  My guess is that the Type is not what you expect.<br>
> >><br>
> >> Hmm, that doesn't show anything as such (after I get the logging syntax<br>
> >> right)...but I know can see that an error in the log does appear to be<br>
> >> associated with this Scrip:<br>
> >><br>
> >> [Wed Aug 18 14:55:25 2010] [warning]: *** Type: Take Status: new ((eval<br>
> >> 5574):1)<br>
> >> [Wed Aug 18 14:55:25 2010] [error]: Template parsing error: Can't call<br>
> >> method "SubValue" on an undefined value at template line 9.<br>
> ><br>
> > OK this second error is actually a red herring, caused by another Scrip<br>
> > I had created to investigate this problem.<br>
> ><br>
> > What _does_ fix it is to change the Action to 'User Defined' with the code:<br>
> ><br>
> > $self->TicketObj->Open();<br>
> ><br>
> > So, the problem seems to be with the "Open Tickets" action...<br>
><br>
> Looking into this further, in lib/RT/Acton/AutoOpen.pm, in the 'prepare'<br>
> function, $self->TransactionObj->IsInbound is coming out as a positive<br>
> integer, so the 'prepare' function is returning 'undef' and the action<br>
> isn't being performed.<br>
<br>
</div></div>This implies that the person taking the ticket is also a Requestor,<br>
possibly because you're creating test tickets.<br>
<div class="im"><br>
> This is some change in the behaviour of RT between 3.8.1 and 3.8.8 that<br>
> has caught us unawares. Reading into this a bit more, it looks like the<br>
> 'Open Tickets' action was written with a very specific purpose in mind,<br>
> to re-open tickets if the requester sends further email. We were not<br>
> using the action for this purpose.<br>
<br>
</div>Check the logic again, it says "If the ticket is the new and this<br>
transaction was from the Requestor, don't change it to open"<br>
<div class="im"><br>
> So, I guess the appropriate final solution is indeed to use custom<br>
> action code in the Scrip.<br>
<br>
</div>If you goal is to always change the status to open with no<br>
restrictions, then yes, one line of custom action is the correct<br>
solution.<br>
<font color="#888888"><br>
-kevin<br>
</font><br><br>
RT Training in Washington DC, USA on Oct 25 & 26 2010<br>
Last one this year -- Learn how to get the most out of RT!<br></blockquote></div><br>