Scrips firing at will - huh?

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);
}

Leif Nixon - Systems expert
ppNational Supercomputer Centre - Linkoping University

I hate to say never, but scrips will never run from clicking
on the Reply link. Scrips run as a result of transactions being
created, and no transaction is created by clicking on Reply.On Tue, Dec 06, 2005 at 09:33:02AM +0100, 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);
}


Leif Nixon - Systems expert

ppNational Supercomputer Centre - Linkoping University


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at http://bestpractical.com/services/training.html

Todd Chapman todd@chaka.net writes:

I hate to say never, but scrips will never run from clicking
on the Reply link. Scrips run as a result of transactions being
created, and no transaction is created by clicking on Reply.

Yes, I know. Unfortunately, RT doesn’t.

At first, I didn’t believe the report I got on this behaviour, but
then I managed to recreate it myself.

Leif Nixon - Systems expert
National Supercomputer Centre - Linkoping University

Leif Nixon wrote:

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.

If true, that would actually be really cool. I’d love to be able to run
scrips that set up various things immediately when the user clicks the
"Reply", “Comment”, etc links.

But, err, I don’t have an answer to your question :slight_smile:

Rick R.

Rick Russell
For computer help, call xHELP (x4357 or 713-348-4357)
OpenPGP/GnuPG Public Key at ldap://certificate.rice.edu
761D 1C20 6428 580F BD98 F5E5 5C8C 56CA C7CB B669
Helpdesk Supervisor, Client Services
IT/Academic & Research Computing
Rice University
Voice: 713.348.5267 Fax: 713.348.6099

signature.asc (254 Bytes)

Looking at your scrip, I don’t think you should be calling die
from a scrip. You should log the error with $RT::Logger->error
and then return 0.

-ToddOn Tue, Dec 06, 2005 at 09:33:02AM +0100, 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);
}


Leif Nixon - Systems expert

ppNational Supercomputer Centre - Linkoping University


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT Wiki at http://wiki.bestpractical.com

Download a free sample chapter of RT Essentials from O’Reilly Media at http://rtbook.bestpractical.com

WE’RE COMING TO YOUR TOWN SOON - RT Training in Amsterdam, Boston and
San Francisco - Find out more at http://bestpractical.com/services/training.html

Todd Chapman todd@chaka.net writes:

Looking at your scrip, I don’t think you should be calling die
from a scrip. You should log the error with $RT::Logger->error
and then return 0.

Thanks for the tip. I didn’t really write that code myself, it was the
result of some serious cargo cult programming that has sort of
propagated through our RT servers… I’ll definitely rewrite it.

Leif Nixon - Systems expert
National Supercomputer Centre - Linkoping University

Rick Russell rickr@rice.edu writes:

Leif Nixon wrote:

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.

If true, that would actually be really cool.

Oh, you’re welcome to try it.

Leif Nixon - Systems expert
National Supercomputer Centre - Linkoping University

Leif Nixon wrote:

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.

If true, that would actually be really cool. I’d love to be able to run
scrips that set up various things immediately when the user clicks the
"Reply", “Comment”, etc links.

But, err, I don’t have an answer to your question :slight_smile:

That could be done, but your RT server would get very busy
recording all those transactions and preparing and running
scrips.

Perhaps something more lightweight could be done, but that
is left as an exercise for the reader.

-Todd

At Tuesday 12/6/2005 10:44 AM, Leif Nixon wrote:

Todd Chapman todd@chaka.net writes:

I hate to say never, but scrips will never run from clicking
on the Reply link. Scrips run as a result of transactions being
created, and no transaction is created by clicking on Reply.

Yes, I know. Unfortunately, RT doesn’t.

At first, I didn’t believe the report I got on this behaviour, but
then I managed to recreate it myself.

If I remember correctly, the Modify screen does run the scrips (but doesn’t
commit them) in order to determine the list of email recipients at the
bottom of the screen - this could be why your scrip is firing.

Steve

Stephen Turner sturner@MIT.EDU writes:

If I remember correctly, the Modify screen does run the scrips (but
doesn’t commit them) in order to determine the list of email
recipients at the bottom of the screen - this could be why your scrip
is firing.

Ah, that would explain it - at least if all the “prepare” actions are
run in the same context (since the AutoTake manages to trigger the
Owner Change scrip).

Leif Nixon - Systems expert
National Supercomputer Centre - Linkoping University

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:

Ken Crocker KFCrocker@lbl.gov writes:

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)

Yes, that’s our policy. And, coincidentally, this removes the need to
go to the web interface to take the ticket, and lets you stay in your
cozy mail reader. Works nicely for us.

, 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.

I’m afraid I don’t understand this paragraph. Perhaps you
misunderstood me; the strange thing is that a scrip fires at all when
you just click the “reply” link - that shouldn’t create a transaction.
But Stephen’s explanation seems to cover it.

Leif Nixon - Systems expert
National Supercomputer Centre - Linkoping University

Leif,

Is there a chance that you’re running on MySQL with MyISAM tables
(rather than innodb tables)?

Jesse>

Leif

I was wondering if moving the code to the 'Custom action cleanup code’
section would solve the problem? You may also need to put “return 1;” into
the Custom action prep section.

Steve

Jesse Vincent jesse@bestpractical.com writes:

Is there a chance that you’re running on MySQL with MyISAM tables
(rather than innodb tables)?

All tables except “sessions” are InnoDB. MySQL 4.1.12, everything
created through “make initialize-database”, and no fiddling since
then.

Leif Nixon - Systems expert
National Supercomputer Centre - Linkoping University

Hi RT Users,

i have a problem with a Template and i hope someone has a good idea.

Let me explain shortly the situation and what i have tried till now.

I have to Queues: CR:ROBOT and CR:ROBOT-AUTH

These Queues are needed to implement Robot Jobs, but not everybody is
allowed to create a Ticket at the CR:ROBOT.

I have created a procmail Filter, that figures out if the Requestor is
allowed to open a Ticket and if not, the mail will be redirected to the
CR:ROBOT-AUTH Queue.

So far all works fine. But now i need the following workflow.

  • The Ticktes from the CR:ROBOT-AUTH Queue will be handled by a Group of
    users and if they say: OK you can do this change, they guys will move
    the Ticket to the CR:ROBOT Queue

Now i have created a Scrip/Template condition that triggers on a queue
change with a special Template. The Scrip informs the Queue (CR:ROBOT)
Watcher about the new Ticket and the Template should give the original
Informations as Mail Content.

The Queue Watchers at this Queue don’t have access to the RT, they only
acting via Mail, so it is needed to give them the original Content from
the first Request.

So far, so good, this is also working fine. But, the Requestor sends in
each Case a attached word Dokument which MUST also be forwarded to the
AdminCcs of the CR:ROBOT Queue - but this isn’t working till now.

My Template looks like:

RT-Attach-Message: yes

{$Transaction->CreatedAsString}: Change Request {$Ticket->id} was acted
upon.
Transaction: {$Transaction->Description} : This change is approved by
Corporate IT
Queue: {$Ticket->QueueObj->Name}
given)"}
Owner: {$Ticket->OwnerObj->Name}
Requestors: {$Ticket->RequestorAddresses}
Status: {$Ticket->Status}
Ticket <URL: {$RT::WebURL}Ticket/Display.html?id={$Ticket->id} >

{ $Ticket->Transactions->First->Content; }

{ $Transaction->Attachments; } # i also have tried this: {
$Ticket->$Transaction->Attachments; } without success

i have also tried the
http://wiki.bestpractical.com/index.cgi?AddAttachmentLinksToMail scrips
but they don’t work at all…!? and they also only add the Attachment
Link to the Mail but not the attachment.

Has anyone a idea??? I’m going crazy…

Thanks

Torsten

Hi.

I am trying to figure out how I can make a custom field required in
order to process the Create Ticket.

I am pretty sure I can create some code that will not open the ticket if
the custom fields are not filled in, but I don’t know how to bounce it
back in front of the end user to let them know that it was not
completed properly.

Same requirement goes for Subject … it cannot be blank.

Any help would be greatly appreciated!

Thanks,
Sam

Hi RT Users,

i have a problem with a Template and i hope someone has a good idea.

Let me explain shortly the situation and what i have tried till now.

I have to Queues: CR:ROBOT and CR:ROBOT-AUTH

These Queues are needed to implement Robot Jobs, but not everybody is
allowed to create a Ticket at the CR:ROBOT.

I have created a procmail Filter, that figures out if the Requestor is
allowed to open a Ticket and if not, the mail will be redirected to the
CR:ROBOT-AUTH Queue.

So far all works fine. But now i need the following workflow.

  • The Ticktes from the CR:ROBOT-AUTH Queue will be handled by a Group of
    users and if they say: OK you can do this change, they guys will move
    the Ticket to the CR:ROBOT Queue

Now i have created a Scrip/Template condition that triggers on a queue
change with a special Template. The Scrip informs the Queue (CR:ROBOT)
Watcher about the new Ticket and the Template should give the original
Informations as Mail Content.

The Queue Watchers at this Queue don’t have access to the RT, they only
acting via Mail, so it is needed to give them the original Content from
the first Request.

So far, so good, this is also working fine. But, the Requestor sends in
each Case a attached word Dokument which MUST also be forwarded to the
AdminCcs of the CR:ROBOT Queue - but this isn’t working till now.

My Template looks like:

RT-Attach-Message: yes

{$Transaction->CreatedAsString}: Change Request {$Ticket->id} was acted
upon.
Transaction: {$Transaction->Description} : This change is approved by
Corporate IT
Queue: {$Ticket->QueueObj->Name}
Subject: {$Transaction->Subject || $Ticket->Subject || “(No subject
given)”}
Owner: {$Ticket->OwnerObj->Name}
Requestors: {$Ticket->RequestorAddresses}
Status: {$Ticket->Status}
Ticket <URL: {$RT::WebURL}Ticket/Display.html?id={$Ticket->id} >

{ $Ticket->Transactions->First->Content; }

{ $Transaction->Attachments; } # i also have tried this: {
$Ticket->$Transaction->Attachments; } without success

i have also tried the
http://wiki.bestpractical.com/index.cgi?AddAttachmentLinksToMail scrips
but they don’t work at all…!? and they also only add the Attachment
Link to the Mail but not the attachment.

Has anyone a idea??? I’m going crazy…
Read FAQ on the wiki, transaction “queue change” has no content and
attachments, attachments you need are linked to the first transaction
(create). Grep for ‘RT-Attach-Message’ in the lib dir, it wouldn’t be
hard to implement ‘RT-Attach-Files-From-Transaction: xxxx’.

Thanks

Torsten

Best regards, Ruslan.

Hi.

On RT 3.4.4 (debian based), we are trying to create a scrip/template
combination that will open tickets and relate them back to a master
ticket based on the settings of various custom fields.

I had this working yesterday, and now I can’t figure out why it
doesn’t work now!

Here’s the actions and symptoms I see:

  • Ticket gets modified
  • Scrip with User Defined condition fires
  • Scrip condition checks out and "return 1;"s
  • CreateByTemplate logs to the debug file

And then nothing.

What I DO NOT see is the Template being executed. The first line of
code in the template logs to the debug file, and that never shows up!

If I change the Action to “Notify Owner”, the template gets executed and
I get an e-mail with the ===Create-Ticket stuff in it.

What could be causing the “Create Tickets” action to fail to execute the
template??? I’ve looked in CreateTickets.pm, but don’t see anything in
there that tips me off. I put a debug line in Parse, and I see it
enters Parse, but I never see the template execution debugging, so I’m
completely at a loss.

Help! I’m almost out of hair to rip out!!

**** Debug log: ****

[Thu Dec 8 21:41:09 2005] [debug]: About to commit scrips for
transaction #17171
(/usr/share/request-tracker3.4/lib/RT/Transaction_Overlay.pm:169)
[Thu Dec 8 21:41:09 2005] [debug]: Found 1 scrips
(/usr/share/request-tracker3.4/lib/RT/Scrips_Overlay.pm:356)
[Thu Dec 8 21:41:09 2005] [debug]: In scrip Subtask Manager -
ChangeTicket ((eval 412):1)
[Thu Dec 8 21:41:09 2005] [debug]: Subtask Manager - ChangeTicket -
Trans Type: CustomField ((eval 412):7)
[Thu Dec 8 21:41:09 2005] [debug]: Subtask Manager - ChangeTicket - GO!
((eval 412):9)
[Thu Dec 8 21:41:09 2005] [debug]: In CreateByTemplate
(/usr/share/request-tracker3.4/lib/RT/Action/CreateTickets.pm:561)

**** Scrip configuration: ****

Description: Subtask Manager - ChangeTicket
Condition: User Defined
Action: Create Tickets
Template: Subtask Manager
Stage: TransactionBatch (which is enabled)

**** Scrip custom condition: ****

$RT::Logger->debug(“In scrip Subtask Manager - ChangeTicket”);

my $ticket = $self->TicketObj;
my @batch = @{$ticket->TransactionBatch};

foreach my $txn (@batch) {
$RT::Logger->debug("Subtask Manager - ChangeTicket - Trans Type: " .
$txn->Type);
if ($txn->Type eq ‘CustomField’) {
$RT::Logger->debug(“Subtask Manager - ChangeTicket - GO!”);
return 1;
}
}

$RT::Logger->debug(“Subtask Manager - ChangeTicket - Does Not Apply”);
return 0;

**** Template - Subtask Manager **** Never seems to get executed with
Action: Create Tickets because I never see the first logging line

{
$RT::Logger->debug(“Subtask Manager - ChangeTicket - Starting…”);

my @batch = @{$Ticket->TransactionBatch};

foreach my $txn(@batch) {
$RT::Logger->debug("Subtask Manager - ChangeTicket - Trans Type: " .
$txn->Type);
if (($txn->Type eq ‘CustomField’) &&
($txn->NewValue eq ‘Required’)) {

  # Get the Custom Field name
  my $cf = RT::CustomField->new($Ticket->CurrentUser());
  $cf->Load($txn->Field);
  my $field = $cf->Name();

  # Create the Subject line for the individual sub-tickets
  my $subject = $Transaction->Subject || $Ticket->Subject;
  $subject =~ s/MASTER/$field/ie;

  $RT::Logger->debug("Subtask Manager - ChangeTicket - Creating 

Ticket for ", $subject);

  $Ticket->Comment(Content => 'Created subtask ticket for ' . $field);

  $OUT .= '===Create-Ticket: ' . $field . "\n";
  $OUT .= 'Queue: ' . $field . "\n";
  $OUT .= 'Subject: ' . $subject . "\n";
  $OUT .= 'Requestor: ' . $Ticket->OwnerObj->EmailAddress() . "\n";
  $OUT .= 'RefersTo: ' . $Ticket->id . "\n";
  $OUT .= 'Content: ' . $Ticket->Transactions->First->Content() . "\n";
  $OUT .= "ENDOFCONTENT\n";
}

}

$RT::Logger->debug(“Template output”, $OUT);

$OUT;
}

OK, I’ve figured out a few things …

It seems that the CreateTickets action requires the template start
with “===Create-Ticket: foo” … and the active perl parsing happens
after the template is initially read in.

What this means for me is that I can’t find any way to create multiple
tickets via an active perl template. :frowning:

So, I’ve tried to switch to plan C and do individual tickets (i.e.
TransactionCreate instead of TransactionBatch). However, I can’t seem
to figure out what objects and methods are available to me in the
template with a CreateTickets action.

Stuff like $Ticket and $Transaction don’t seem to be available … only
$Tickets{‘Top’}.

I found a $Tickets{‘TOP’}->Transactions(), which does indeed return me
an object of RT::Transactions, but that doesn’t seem to have a Field()
method like an RT::Transaction would.

All I want to do is find out what the heck the transaction type and
value are so I can create my subtickets, but that sure isn’t going easy.

I’m at the point where I’m just totally shotgun coding, which I hate
doing, so I’m stopping for the night and hoping for some good news from
the list tonight!

Thanks,
Sam