Hi,
I’m having a frustrating time setting the value of a global customfield
when triggered by changing the queue of the ticket.
My custom commit code sets the field fine, with;
$self->TicketObj->AddCustomFieldValue(Field => 21, Value => ‘SPAM’)
however, directly afterwards another transaction takes place that
apparently calls DeleteCustomFieldValue, because I get the message
’SPAM is no longer a value for custom field SA-Trained’
The debug log gives me this info:
Aug 23 10:18:16 localhost RT: About to think about scrips for
transaction #7080
Aug 23 10:18:16 localhost RT: About to prepare scrips for transaction
#7080
Aug 23 10:18:16 localhost RT: Found 3 scrips
Aug 23 10:18:16 localhost RT: About to commit scrips for transaction #7080
Aug 23 10:18:17 localhost RT: About to think about scrips for
transaction #7081
Aug 23 10:18:17 localhost RT: About to prepare scrips for transaction
#7081
Aug 23 10:18:17 localhost RT: Found 3 scrips
Aug 23 10:18:17 localhost RT: About to commit scrips for transaction #7081
Aug 23 10:18:17 localhost RT: About to think about scrips for
transaction #7082
Aug 23 10:18:17 localhost RT: About to prepare scrips for transaction
#7082
Aug 23 10:18:17 localhost RT: Found 3 scrips
Aug 23 10:18:17 localhost RT: About to commit scrips for transaction #7082
Transaction 7080 is the initial change queue transaction, 7081 is the
custom field change transaction, and 7082 is the mystery transaction
that re-sets the custom field to NULL.
On closer inspection to the transaction table in the database for 7081
and 7082, it appears that the Reference fields are being set rather than
the Value fields. Is this significant?
I also am not sure how to go about identifying which 3 scrips rt finds
for each transaction. One of these must be the culprit right?
Does anyone have any ideas?
I’m running RT 3.4.1 on Debian stable.
Thanks,
Max.