[rt-users] Problems with scrips modifying custom filed values

Silvana.Giberti at esa.int Silvana.Giberti at esa.int
Fri Apr 20 08:42:29 EDT 2007

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


Gene LeDuc <gleduc at mail.sdsu.edu> 
19/04/2007 18:24

Silvana.Giberti at esa.int
RT-Users at lists.bestpractical.com
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!

At 12:19 AM 4/19/2007, Silvana.Giberti at 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? 


Gene LeDuc, GSEC
Security Analyst
San Diego State University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20070420/7b911753/attachment.htm>

More information about the rt-users mailing list