Scrip question]

RT Users
1

Yes, that’s behaving as defined. It might be possible to use a
cleverer scrip to work around it, but each change to a ticket is a
separate transaction.On Apr 12, 2007, at 3:16 PM, Kenneth Crocker wrote:

Jesse,

Sorry to just address this to you, but it came up in RT Users and
I wanted to ask you if Stephan is correct about this. Is it
possible for a user-defined scrip to be executed and an initial
modification to a CF be reversed? If so, is this a bug that is
corrected in 3.6.3 or what? Thanks.

Kenn
LBNL

From: Stephen Turner sturner@MIT.EDU
Date: April 10, 2007 9:47:46 AM EDT
To: Kenneth Crocker KFCrocker@lbl.gov, rt-users@bestpractical.com
Subject: Re: [rt-users] Scrip question

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

PGP.sig (186 Bytes)