[Rt-devel] rt-escalate/Custom Field Scrip Condition bug in 3.4.2

[Ruslan U. Zakirov]

Jens Porup wrote:
> On Fri, Jun 10, 2005 at 04:08:13PM +0200, Rolf Grossmann wrote:
> 
>>Jens Porup wrote:
>>
>>
>>>puzzling over an interesting bug involving rt-escalate and Custom Scrip
>>>conditions.
>>>
>>>In my queue "incoming-batch", there is a Scrip that creates
>>>a ticket in a different queue "media-ticket" using the Custom Condition:
>>>
>>>	return undef unless 
>>>	($self->TicketObj->FirstCustomFieldValue('batch_state') =~
>>>	/Incoming Received/i);
>>>	return 1;
>>>
>>>Before rt-escalate was implemented as cron job, this worked fine.
>>>The end user would change the custom field value to Received, the media
>>>ticket would be created, end of story.
>>>
>>>Now.... every time rt-escalate runs (until final priority is reached),
>>>that custom condition is being tested, and the media ticket created.
>>>
>>>I've had a look through the RT::Action::EscalatePriority.pm code,
>>>and some of a look at the TicketObj code, but I'm stumped on this one.
>>>
>>>Anyone have any ideas?
>>
>>Sounds pretty logical to me. Every time rt-escalate runs, it changes the 
>>priority, which is a transaction, therefore all Scrips get run if their 
>>Condition is true. Since your condition only tests for the Value, it's 
>>always true after that Value has been set. You might want to add a test 
>>if the Scrip is actually being triggered by a change to the CustomField 
>>or if the action has already been performed.
> 
> 
> Hi Rolf (et al),
> 
> Not quite sure the best way to do this using the RT API.
> 
> There's no way for me to test the existence of a ticket in a different queue
> (which is the result of the scrip) that I can think of.
> 
> Is there an easy way to test for if the change to the CustomFieldValue
> has just happened (besides some contortion involving the LastUpdated
> field and time comparisons)?
Look at
http://wiki.bestpractical.com/admin/index.cgi?OnCustomFieldValueChange


> 
> Thanks,
> 
> Jens
> _______________________________________________
> Rt-devel mailing list
> Rt-devel at lists.bestpractical.com
> http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel
>