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

[Jens Porup]

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)?

Thanks,

Jens