rt-escalate/Custom Field Scrip Condition bug in 3.4.2

Greetings,

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?

Jens

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.

Rolf

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

Jens Porup wrote:

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.

I’d use the Links, e.g. “Refers to”. There should be calls in the Ticket
object to set that properly.

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

I was thinking along the lines of just checking the Transaction type. If
it’s about a custom field (and I guess you could even check which one),
that’s probably the transaction you’re looking for. But there’s still a
possibility to overlook some case, that’s why I was suggesting to test
the result of the Scrip.

Rolf

Jens Porup 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

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

This is password-protected “restricted stuff.”

Is it ready to view?

Jens

Jens Porup wrote:

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

grrr… sorry
http://wiki.bestpractical.com/index.cgi?OnCustomFieldValueChange