[rt-users] Trouble with notification scrip

Kenneth Crocker KFCrocker at lbl.gov
Fri May 18 15:54:51 EDT 2007


Gene,

	Upon further thought, maybe the fact that the CF is defined as "select 
ONE value" it tries to delete the old value associated with the ticket 
since it is being replaced with another value. Or maybe it updates the 
ticket custom field first with the new value and then tries to delete 
the old and the error is generated. I know the actual update happens. In 
fact, the sequence of messages show the new value updated first then the 
error that it couldn't find the old one to delete. HHMM. Also, the idiot 
that is sending this e_mail to you didn't include your sub routine, 
that's why it didn't work. I used Stephans and it worked real well. I 
guess I didn't realise that the QueueObj was necessary in identifying 
the custom field. I figured that by simply using the 
self->transactionObj->field would be enough. Simple doesn't apply to any 
of this code, it seems. Anyway, thanks a bunch for your help. Sorry I 
wasn't sharp enough to apply it properly.

Kenn
LBNL

Gene LeDuc wrote:
> Kenn, something is odd here.
> 
> I just grepped the RT code for that error message and it only seems to 
> appear as an error message that is generated if an attempt is made to 
> delete a custom value that is not in the specified custom field (like 
> trying to delete "xyz" from CF1 if it's not in CF1).  I don't think it 
> has anything to do with your scrip condition.
> 
> Is the action of your scrip (or template) trying to delete a value from 
> a custom field?
> 
> Gene
> 
> At 09:23 AM 5/18/2007, Kenneth Crocker wrote:
>> Gene,
>>
>>         I just tried the code:
>>
>> my $trans = $self->TransactionObj;
>>
>> return ($trans->Type eq "CustomField" &&
>>         $trans->Field == get_custom_id("Approval-Status") &&
>>         $trans->NewValue eq "Reviewing Request");
>>
>> and I got the error "* Custom field value Reviewing Request could not 
>> be found for custom field Approval-Status"  and no notification was 
>> sent. The funny thing is, I get that message regardless of what value 
>> I select from the drop down. If I can see the selection in the drop 
>> down, how can that error message be generated? I looked at the custom 
>> field and it is selected for the Queue I am using and I am a 
>> super-user. So I then added myself to a group with "modifycustomfield" 
>> for that custom field (just in case) and the error said the custom 
>> field was "not under consideration". What does that mean? Why is it 
>> saying that when I have the CF applied to the Queue, I am a superuser, 
>> and I am in a group with modifycustomfield rights? this doesn't make 
>> sense.
>>
>> Kenn
>>
>>
>>
>>
>>
>> Gene LeDuc wrote:
>>> Kenn, you're using curly brackets to enclose the condition phrase.  
>>> In this case you really don't need to enclose it at all, but if you 
>>> do then you need to use parentheses.
>>> This should work:
>>>   return 1 if $trans->Type eq "CustomField" && $trans->Field == 
>>> get_custom_id("Approval-Status") && $trans->NewValue eq "Reviewing 
>>> Request";
>>> This too:
>>>   return 1 if ($trans->Type eq "CustomField" && $trans->Field == 
>>> get_custom_id("Approval-Status") && $trans->NewValue eq "Reviewing 
>>> Request");
>>> Also:
>>>   return ($trans->Type eq "CustomField" && $trans->Field == 
>>> get_custom_id("Approval-Status") && $trans->NewValue eq "Reviewing 
>>> Request");
>>> All assuming that the CF name and Value are as stated and that you 
>>> have the get_custom_id sub at the end of your code.
>>> At 04:30 PM 5/17/2007, Kenneth Crocker wrote:
>>>> return 1 if {$trans->Type eq "CustomField" &&
>>>>              $trans->Field == get_custom_id('Approval-Status') &&
>>>>              $trans->NewValue eq "Reviewing Request"};
>>
>>
>> -- 
>> Gene LeDuc, GSEC
>> Security Analyst
>> San Diego State University 
> 



More information about the rt-users mailing list