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
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
Request Tracker Wiki
grrr… sorry
http://wiki.bestpractical.com/index.cgi?OnCustomFieldValueChange