[rt-users] Scrips firing at will - huh?

Ken Crocker KFCrocker at lbl.gov
Tue Dec 6 12:31:42 EST 2005


Leif,

    Sounds to like since the code fired off the script notice first 
(also sounds like it assumes anyone who does a reply to an unowned 
ticket just volunteered to be the owner - quite an assumption), based on 
the clicking of the reply button, it's too late to take it back. It's 
gone, like a missle that has a pre-assigned destination and nothings 
gonna stop it ("it's too late, baby, it's just too late" - a la Carol 
King). Unless you change the sequence of the perl code (and for that 
matter find a way to remove the assumption) you're stuck. We like to 
keep the code as "untouched" as we can and just handle the problems like 
yours by doing what the doctor does (he says, "Then Don't do that").  
Sorry for the, perhaps, ill-timed humor, but with freeware, you get what 
you get.

Kenn

Leif Nixon wrote:

>OK, I thought I had some basic understanding of the scrip mechanism,
>but this is just weird...
>
>I'm running RT 3.4.4 with fastcgi on an Apache 2.
>
>I have a AutoTake scrip on the form "On Correspond User Defined with
>template Blank". That "User Defined" bit is a short Perl snippet that
>checks if the current ticket owner is Nobody, and if so, assigns the
>ticket to the current user. The entire snippet is located in the
>"Custom action preparation code" part of the scrip, which is perhaps
>not a good idea. (I'm including the Perl code at the end of this mail
>for the sake of completeness.)
>
>I also have the standard "On Owner Change Notify Owner" scrip.
>
>Now the strange thing: If a user clicks one of the "Reply" links in
>the history of an unowned ticket (on the ordinary Ticket/Display.html
>page), he gets a notification from the Owner Change scrip that he is
>now the owner of the ticket. Note that this is when he just clicks the
>"Reply" link, before he has actually entered a reply and updated the
>ticket!
>
>Furthermore, if you at this point cancel the reply and return to the
>ticket display, it turns out that the ticket still is ownerless. It
>has in fact *not* been assigned to the user, but still the Owner
>Change scrip fired.
>
>I have experimented with splitting the Perl code from the AutoTake
>scrip, so that the check for an ownerless ticket goes in the "action
>preparation" part, and the actual SetOwner() call goes in the "action
>cleanup" part, which seems to help, but I still don't understand the
>anomalous behaviour.
>
>Could someone spread some light on this?
>
>------
>The code from the scrip:
>
>my $ticket = $self->TicketObj;
>if ($ticket->OwnerObj->Id == $RT::Nobody->Id)  {
>  my $Actor = $self->TransactionObj->CreatorObj->Id;
>  if ($Actor != $ticket->OwnerObj->Id) {
>    $RT::Logger->info("Auto assign ticket #". $ticket->id ." to user #". $Actor );
>
>    my ($status, $msg) = $ticket->SetOwner( $Actor );
>    unless( $status ) {
>      die "Error: $msg";
>    }
>  }
>  return( 1 );
>}
>else {
>    return(undef);
>}
>
>  
>



More information about the rt-users mailing list