[rt-users] Wierd CF updating results

[Kenneth Crocker]

To all,


	This should be a real good test of our understanding of how a scrip can 
change a Custom Field. I have two scrips that are alomost exactly alike; 
difference being the value being put into the SAME CF. The actions are 
as follows:

First scrip action;

# set new Work-Status value

my $ticket = $self->TicketObj;
my $cf_obj = RT::CustomField->new($RT::SystemUser);
my $cf_name = "Work-Status";
my $cf_value = "Investigating Request";

$cf_obj->LoadByName( Name => $cf_name );
$RT::Logger->debug( "Loaded \$cf_obj->Name = ". $cf_obj->Name() ."\n" );
$cf_obj->AddValueForObject( Object=>$ticket, Content=>$cf_value, );

# set new Ticket Status value

$ticket->SetStatus("rq approvd");
return 1;

Second scrip action;

# set new Work-Status value

my $ticket = $self->TicketObj;
my $cf_obj = RT::CustomField->new($RT::SystemUser);
my $cf_name = "Work-Status";
my $cf_value = "Estimating Effort";

$cf_obj->LoadByName( Name => $cf_name );
$RT::Logger->debug( "Loaded \$cf_obj->Name = ". $cf_obj->Name() ."\n" );
$cf_obj->AddValueForObject( Object=>$ticket, Content=>$cf_value, );
return 1;

	I have checked the DataBase after executing both og these and in the 
case of the first one, the value I inserted was there in the 
OBJECTCUSTOMFIELDVALUES with the Disabled value as 0. In the case of the 
second one, the value I inserted was there as well, but the Disabled 
value was 1, followed by another record for the same CF and the value 
was reverted to what it was before my scrip ran and the disabled value 
was 0.

	So, why is this happening. Same user (me) with superuser rights modify 
the same CF in the same ticket in the same Queue and in the first 
instance, all is well, in the second, my change is reverted with the 
database indicating that my change was disabled and it's reversion being 
enabled (that, of course, makes sense if my change is gonna be rejected).

	Anyone out there with any brilliant clues? I realise that the first 
scrip is also changin the Ticket Status, but that should not have this 
effect. Oh, also, the CF is a "ticket" CF and is set for "select 1 
value" and both values are valid choices. Hope this tantalises someone.


Kenn
LBNL