Scrip question

To all,

I have a question that perhaps the longtime users of RT can answer; I 

am planning a series of scrips that will evaluate certain Custom Fields
(which can only be modified by certain people) and based on that result
and the current status of the ticket, CHANGE the current status of said
ticket. This will, in essence, allow me to automate the work-flow of a
ticket from request to development to QA to Implementeded to Resolved or
any other stages of status I desire. My question is this, when a ticket
is modified does RT evaluate and attempt to execute any and all
"user-defined" scrips that are applied (by either Queue or Globally) for
that ticket? Thanks.

Kenn
LBNL

At Monday 4/9/2007 08:13 PM, Kenneth Crocker wrote:

To all,

    I have a question that perhaps the longtime users of RT can 

answer; I am planning a series of scrips that will evaluate certain
Custom Fields (which can only be modified by certain people) and
based on that result and the current status of the ticket, CHANGE
the current status of said ticket. This will, in essence, allow me
to automate the work-flow of a ticket from request to development
to QA to Implementeded to Resolved or any other stages of status I
desire. My question is this, when a ticket is modified does RT
evaluate and attempt to execute any and all “user-defined” scrips
that are applied (by either Queue or Globally) for that ticket? Thanks.

Hello Kenn,

RT will look at all scrips appropriate to the ticket (queue &
global) and see whether it should execute them, whether or not they
have user defined code. So if you want a user-defined condition to
execute only on a status change (for example) you have to code that
condition in the custom condition.

Also, there’s a potential trap you can get caught in when updating
ticket fields in scrips - if the update that fires the scrip is
triggered from a ticket update screen, the value that is shown on the
screen when the submit button is pressed can override your scrip
update. For example, if your ticket is open, you make an update to a
custom field, and this triggers a scrip that, in custom code, changes
the status to ‘stalled’, the sequence of events that take place may
set the ticket back to what it was on the screen (ie open). I haven’t
found a way round this one -

Steve

Stephen Turner wrote:

Also, there’s a potential trap you can get caught in when updating
ticket fields in scrips - if the update that fires the scrip is
triggered from a ticket update screen, the value that is shown on the
screen when the submit button is pressed can override your scrip update.
For example, if your ticket is open, you make an update to a custom
field, and this triggers a scrip that, in custom code, changes the
status to ‘stalled’, the sequence of events that take place may set the
ticket back to what it was on the screen (ie open). I haven’t found a
way round this one -

This just bit me today. I have a scrip that changes a custom field on
owner change. When user gives away a ticket from /Ticket/Modify.html,
there’s also the current value of said custom field selected.

What happens is that the scrip changes the value of the custom field
just to have it set back in the next transaction.

This of course doesn’t happen if I change the owner in the
ModifyPeople.html, but I don’t think I am able to educate my users…

I really hope there is a solution to this that does not involve
modifying RT. If not, I’ll just disable the owner update from
Modify.html. But that is, to put it mildly, crude.

Any ideas?

regards,
Borut Mrak.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Erm, about scrips:

What the “transaction” field means anyway?

I’m basing my scrips on
Request Tracker Wiki,
but I want to auto-deal with Nagios and Cron-Apt automatic emails. Can
I create two different scrips and apply to the same ‘thing’ (onCreate)?

I tried that for the cron-apt emails, with no luck:

Based on

http://marc.free.net.ph/message/20040319.180325.27528377.en.html

Modificado por yves.junqueira@mds.gov.br para uso no cron-apt

“CRON-APT completed on romario [/etc/cron-apt/config]”

my $update_host = undef;

my $Transaction = $self->TransactionObj;
my $subject = $Transaction->Attachments->First->GetHeader(‘Subject’);
if ($subject =~ m#CRON-APT completed on (\w+) [/etc/cron-apt/config]#) {
# This looks like a nagios recovery message
$update_host = $1;

$RT::Logger->debug("Encontrada atualiza��o relacionada:

$update_host");
} else {
return 1;
}

Ok, now let’s merge this ticket with it’s PROBLEM msg.

my $search = RT::Tickets->new($RT::SystemUser);
$search->LimitQueue(VALUE => ‘rede’);
$search->LimitStatus(VALUE => ‘new’, OPERATOR => ‘=’, ENTRYAGGREGATOR
=> ‘or’);
$search->LimitStatus(VALUE => ‘open’, OPERATOR => ‘=’);

if ($search->Count == 0) { return 1; }
my $id = undef;
while (my $ticket = $search->Next) {
# Ignore the ticket that opened this transation (the recovery one…)
next if $self->TicketObj->Id == $ticket->Id;
# Look for nagios PROBLEM warning messages…
if ( $ticket->Subject =~ m#CRON-APT completed on (\w+)
[/etc/cron-apt/config]# ) {
if ($1 eq $update_host){
# Aha! Found the Problem TICKET corresponding to this RECOVERY
# ticket
$id = $ticket->Id;
# Nagios may send more then one PROBLEM message, right?
$RT::Logger->debug(“Merging ticket " .
$self->TicketObj->Id . " into $id because of OA number match.”);
$self->TicketObj->MergeInto($id);
# Keep looking for more PROBLEM tickets…
}
}
}

$id || return 1;

Auto-close/resolve this whole thing

#$self->TicketObj->SetStatus( “stalled” );
1;
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGG6cEv0TDyic/J4kRAh9kAJ47rTHOgM4rkaVam29vscJCmChrFwCfeVru
Qk/n9Ld83hiTIS/fEnrsKtY=
=2kAI
-----END PGP SIGNATURE-----

Have you tried setting the scrip stage to TransactionBatch? The scrip
will then get triggered only once after all transactions have been
generated. You then have to iterate over all the transactions to look
for your condition. There is an example in the RT Essentials book.

Karen Nyenhuis wrote:

Have you tried setting the scrip stage to TransactionBatch? The scrip
will then get triggered only once after all transactions have been
generated. You then have to iterate over all the transactions to look
for your condition. There is an example in the RT Essentials book.

No, I haven’t tried that yet. I’ll do it to learn another trick.

Does enabling TransactionBatch have any effect on current scrips, or is it
transparent? I wouldn’t want to have to rewrite all scrips… But I assume
enabling it in config file just makes it possible to select it per-scrip.

thanks,
Borut Mrak.

Karen, Borut, & Stephan,

Thank you all for your replies. My intent is that once a person has 

already updated a CF, RT would recognise that a transaction has occurred
against the ticket and my user-defined condition would execute, which
would modify the ticket status field only. It’s crucial to my design.
Actually, if the CF goes back to it’s previous setting, I won’t really
care as long as the status change takes place. I was also thinking of
using this method for approvals (modify status to “rq apprvd”) because I
think it is less cumbersome than the delivered version (I can more
easily control the effect). Thanks again.

Kenn
LBNL

Karen Nyenhuis wrote:

Hi

RT 3.8.7
MySQL

I have been asked to do the following: when updating a ticket and a
specific User is selected as the new Owner, I will Force that User to be
the new Owner. We have several Users which I need to Force as new Owners.
Is it possible to create a Scrip to do this? Should I use the
TransactionObj or the TicketObj? I am thinking I should use the
TransactionCreate Stage.

Thanks,
Roman