I checked the condition code in both scrips, but they look right to me:
they both check field number of the custom fields.
I looked at the Transaction table in the database and compared a
successful case with a wrong one. What I can see is that for a successful
update I only have 2 transaction, while 3 for the wrong case. Instead, it
seems that for the good case, there is one more transaction of type
“CustomField” at ticket creation time. Moreover, the transactions order is
different.
I also noticed that scrips work well or not depending on the ticket
itself, that is, if the scrip is successful the first time after the
ticket creation, then it will never fail afterwords on the same ticket,
and viceversa when it fails the first time.
In the end, it seems to me that the problem starts at ticket creation
time, and maybe for the transaction execution timing. I also tried to
force a different scrip order (by adding a number in the scrip name), but
it doesn’t seem to solve the problem.
Any other ideas on this issue?
Regards,
Silvana
Gene LeDuc gleduc@mail.sdsu.edu
19/04/2007 18:24
To
Silvana.Giberti@esa.int
cc
RT-Users@lists.bestpractical.com
Subject
Re: [rt-users] Problems with scrips modifying custom filed values
Hi Silvana,
Since you’re suspecting that an extra transaction might be causing your
problem, you probably need to find out what that extra transaction is.
The easiest way I’ve found to do this is to go into your rt3 database and
look for the transaction number (from the rt log) in the Transactions
table (I like Toad for accessing mysql from Windows). The Type, Field,
OldValue, and NewValue fields should get you started. Don’t be tempted to
make any changes, though.
You also might want to double-check that the condition code in “scrip Y”
is producing TRUE only when the first custom field changes value (not when
any custom field changes):
{ my $x = 7; return ($self->TransactionObj->Type eq ‘CustomField’) &&
($self->TransactionObj->Field == $x); }
where $x is the field number for the first custom field.
Good luck!
Gene
At 12:19 AM 4/19/2007, Silvana.Giberti@esa.int wrote:
I’m having problems with scrips modifying the values of 2 custom fields.
The first custom field is created and assigned at ticket creation (by
scrip X), while the second custom field is updated whenever the first one
is modified (by scrip Y), that is after ticket creation and also everytime
the user modifes the first cf.
What sometime happens is that scrip Y updates the second custom field
twice, that is, a first time assigning the new value and then a second
time setting it back to its original value. Sometimes instead the same
scrips work properly on both custom fields, assigning the right value also
to the second one.
The same scrips work always well when the custom fields are first created
and assigned the first value.
Comparing the 2 cases in RT log file, it looks like there’s an extra
transaction firing after the update of the second custom field, but I
can’t tell what it does.
The function I call to update the custom fields is the
“AddCustomFieldValue”, from Record.pm.
The custom fields are defined global for tickets in all queues.
(RT 3.6.1, MySQL 4.1.12)
Does anyone have an idea of what to do to fix this problem?
Thanks,
Silvana
Gene LeDuc, GSEC
Security Analyst
San Diego State University