[Fwd: Re: [rt-users] Scrip question]

[Jesse Vincent]

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 at MIT.EDU>
> Date: April 10, 2007 9:47:46 AM EDT
> To: Kenneth Crocker <KFCrocker at lbl.gov>, rt-users at 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20070412/9282ef6b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20070412/9282ef6b/attachment.sig>