CustomField is deleted automatically after modified by a scrip

I encountered a strange problem when setting value for a custom field.
If anyone can give me a lead that will be appreciated.
The background of this problem is listed below:

RT version: 3.4.3
CustomField: Evaluator
Type- Enter one value,
Applied to: Tickets,
Assigned to one queue: Changes
Scrip:
Description: Update Evaluator and Test Status
Condition: User Defined
Action: User Defined
Template: Global template: Blank
Stage: TransactionCreate

Custom condition: <omitted as it’s working fine>
Custom action preparation code: return 1;
Custom action cleanup code:
#---------------------------------------Begin---------------------------
my $CF_Eval = ‘Evaluator’;
my $evalor = $self->TransactionObj->Creator;
my $eval1 = RT::User->new(RT::SystemUser);
$eval1->Load($evalor);
my $DV_Eval = $eval1->RealName;
my $QueueObj = $self->TicketObj->QueueObj;
my $CFObj2 = RT::CustomField->new( $QueueObj->CurrentUser );
$CFObj2->LoadByNameAndQueue( Name => $CF_Eval, Queue => $QueueObj->id );
unless( $CFObj2->id ) {
$CFObj2->LoadByNameAndQueue( Name => $CF_Eval, Queue => 0 );
unless( $CFObj2->id ) {
$RT::Logger->error(“custom field ‘$CF_Eval’ isn’t global or
defined for queue '”. $QueueObj->Name ."’");
return undef;
}
}

my( $st, $msg ) = $self->TicketObj->AddCustomFieldValue(
                                      Field => $CFObj2->id,
                                      Value => $DV_Eval,
                                      RecordTransaction => 1 );
unless( $st ) {
  $RT::Logger->error( "Couldn't set $DV_Eval as value for CF

$CF_Eval:". $msg );
return undef;
}

$RT::Logger->info(“My troublshooting - run scrip Set Evaluator”);

return 1;
#---------------------------------------End-----------------------------

Note: this action is to set current transaction user to be the
Evaluator, fill in his real name instead of RT id.

History record in the ticket:
RT_System - Evaluator James Wot added
wotj01 - Evaluator James Wot deleted

Note: first line shows that the scrip updated the CF:Evaluator
successfully but then there’s another transaction shows that the user
deleted the CF’s value. But the user didn’t do that. So it must be some
internal mechanism did that.

Regards,
David

At Thursday 5/11/2006 03:52 AM, David Di wrote:

I encountered a strange problem when setting value for a custom
field. If anyone can give me a lead that will be appreciated.

Note: this action is to set current transaction user to be the
Evaluator, fill in his real name instead of RT id.

History record in the ticket:
RT_System - Evaluator James Wot added
wotj01 - Evaluator James Wot deleted

Note: first line shows that the scrip updated the CF:Evaluator
successfully but then there’s another transaction shows that the
user deleted the CF’s value. But the user didn’t do that. So it must
be some internal mechanism did that.

Hello David,

You didn’t describe what the user-defined condition does, but I can
guess what’s happening. I’m assuming that the problem occurs when a
ticket is updated in the web interface, from a screen that allows
custom fields to be updated.

When you submit the form, the CF value on the screen is blank. The
scrip changes the value to ‘James Wot’. Then the values submitted
from the form are processed - RT sees that the current CF value is
‘James Wot’ and that the submitted value is null. It interprets this
as a deletion.

Steve

Hi Steve,

Thanks for the reply and what you explained was just what I suspected.
But in this case how can I set a CF’s value as the purpose of a scrip is
to do the job without manual intervention. This one sometimes works but
not stable so I can’t make sure it always work and so I can’t put it in
production use. One more problem is when I use one scrip to change two
CFs’ value, one is changed fine and one has this problem that was
deleted afterwards. If you have any solution that will be great help.
Thank you.

Regards,

DavidFrom: Stephen Turner [mailto:sturner@MIT.EDU]
Sent: Thursday, May 11, 2006 9:53 PM
To: David Di; rt-users@lists.bestpractical.com
Subject: Re: [rt-users] CustomField is deleted automatically after
modified by a scrip

At Thursday 5/11/2006 03:52 AM, David Di wrote:

I encountered a strange problem when setting value for a custom
field. If anyone can give me a lead that will be appreciated.

Note: this action is to set current transaction user to be the
Evaluator, fill in his real name instead of RT id.

History record in the ticket:
RT_System - Evaluator James Wot added
wotj01 - Evaluator James Wot deleted

Note: first line shows that the scrip updated the CF:Evaluator
successfully but then there’s another transaction shows that the
user deleted the CF’s value. But the user didn’t do that. So it must
be some internal mechanism did that.

Hello David,

You didn’t describe what the user-defined condition does, but I can
guess what’s happening. I’m assuming that the problem occurs when a
ticket is updated in the web interface, from a screen that allows
custom fields to be updated.

When you submit the form, the CF value on the screen is blank. The
scrip changes the value to ‘James Wot’. Then the values submitted
from the form are processed - RT sees that the current CF value is
‘James Wot’ and that the submitted value is null. It interprets this
as a deletion.

Steve

You can try to use TransactionBatch stage.On 5/12/06, David Di David.Di@sssworldwide.com wrote:

Hi Steve,

Thanks for the reply and what you explained was just what I suspected.
But in this case how can I set a CF’s value as the purpose of a scrip is
to do the job without manual intervention. This one sometimes works but
not stable so I can’t make sure it always work and so I can’t put it in
production use. One more problem is when I use one scrip to change two
CFs’ value, one is changed fine and one has this problem that was
deleted afterwards. If you have any solution that will be great help.
Thank you.

Regards,

David

-----Original Message-----
From: Stephen Turner [mailto:sturner@MIT.EDU]
Sent: Thursday, May 11, 2006 9:53 PM
To: David Di; rt-users@lists.bestpractical.com
Subject: Re: [rt-users] CustomField is deleted automatically after
modified by a scrip

At Thursday 5/11/2006 03:52 AM, David Di wrote:

I encountered a strange problem when setting value for a custom
field. If anyone can give me a lead that will be appreciated.

Note: this action is to set current transaction user to be the
Evaluator, fill in his real name instead of RT id.

History record in the ticket:
RT_System - Evaluator James Wot added
wotj01 - Evaluator James Wot deleted

Note: first line shows that the scrip updated the CF:Evaluator
successfully but then there’s another transaction shows that the
user deleted the CF’s value. But the user didn’t do that. So it must
be some internal mechanism did that.

Hello David,

You didn’t describe what the user-defined condition does, but I can
guess what’s happening. I’m assuming that the problem occurs when a
ticket is updated in the web interface, from a screen that allows
custom fields to be updated.

When you submit the form, the CF value on the screen is blank. The
scrip changes the value to ‘James Wot’. Then the values submitted
from the form are processed - RT sees that the current CF value is
‘James Wot’ and that the submitted value is null. It interprets this
as a deletion.

Steve


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical: Careers — Best Practical Solutions

Best regards, Ruslan.

David Di wrote:

But in this case how can I set a CF’s value as the purpose of a scrip is
to do the job without manual intervention.

Two options:

(1) Set the rights on the Custom Field so that the user cannot manually
modify it.

(2) Set the scrip execution to “TransactionBatch”, which should wait for
the contents of the form to be submitted before it goes into action.
TransactionBatch mode must be turned on. In the SiteConfig file, I think.

Rick R.

This one sometimes works but