Trouble with notification scrip

To all,

I am new to RT and Perl. I have been trying to learn how to change some 

of this stuff by looking at the code you all write about as well as look
at the RT Essentials book. I have a new scrip that has the following
parameters set:

Condition: User Defined
Action: NotifyOwner
Template: Global template: Reviewed (a new I created)
Stage: TransactionCreate

I have tried several version of this code:
my $trans = $self->TransactionObj;

return 1 if {$trans->Type eq “CustomField” &&
$trans->Field == get_custom_id(‘Approval-Status’) &&
$trans->NewValue eq “Reviewing Request”};

and this version:
my $trans = $self->TransactionObj;

return 1 if {$trans->Type eq “CustomField” &&
$trans->Field eq “Approval-Status” &&
$trans->NewValue eq “Reviewing Request”};

and this version:
my $trans = $self->TransactionObj;

return o unless {$trans->Type eq “CustomField” &&
$trans->Field eq “Approval-Status” &&
$trans->NewValue eq “Reviewing Request”};

and this version:
my $trans = $self->TransactionObj;

return o unless {$trans->Type eq “CustomField” &&
$trans->Field == get_custom_id(‘Approval-Status’) &&
$trans->NewValue eq “Reviewing Request”};

and this version:
my $trans = $self->TransactionObj;

return o unless {$trans->Type eq “CustomField”};
return 1 if {$trans->Field eq “Approval-Status” &&
$trans->NewValue eq “Reviewing Request”};

All but the latter sent out a notification regardless of what field I
changed or what I changed it to. The last one never worked at all, period.

I am getting EXTREMELY frustrated with this. I can’t find a good example
of what I’m trying to do in the RT Essentials book, which makes it
practically useless for and many others, I would think. I’ve tried
various code from several of you users and that doesn’t work.

I feel like either I’m an idiot or RT needs to be better documented for
stuff like this for dummies like me. Not everyone who gets/inherits this
system knows Perl well (and all the gadzillion variations of the same
working code, which is confusing) let alone how to apply it to RT. I
looked at the OVERLAY stuff and that doesn’t seem very well spelled out
as well.

I need help or I’m just gonna have to throw up my hands and forget it.
Thanks.

Kenn
LBNL

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

Gene,

Sorry for all the hassle. In the Perl class I took, I got the 

impression that it didn’t matter what type of brackets you used, as long
as they matched left & right. Also, why do you use == in the second
line? Why not just another eq? Another question; I was under the
impression that if the code failed, nothing happened. In my case it
seems that the code was wrong, but I was getting a notification no
matter what. That doesn’t make sense.

Kenn

Gene LeDuc wrote:

At Friday 5/18/2007 12:09 PM, Kenneth Crocker wrote:

Gene,

    Sorry for all the hassle. In the Perl class I took, I got 

the impression that it didn’t matter what type of brackets you
used, as long as they matched left & right. Also, why do you use ==
in the second line? Why not just another eq? Another question; I
was under the impression that if the code failed, nothing happened.
In my case it seems that the code was wrong, but I was getting a
notification no matter what. That doesn’t make sense.

Kenn

Hi Kenn,

Regarding the last part about notification, you should see something
in the RT log when a scrip with invalid Perl code is executed.

Steve

At Friday 5/18/2007 12:09 PM, Kenneth Crocker wrote:

Gene,

    Sorry for all the hassle. In the Perl class I took, I got 

the impression that it didn’t matter what type of brackets you
used, as long as they matched left & right. Also, why do you use ==
in the second line? Why not just another eq? Another question; I
was under the impression that if the code failed, nothing happened.
In my case it seems that the code was wrong, but I was getting a
notification no matter what. That doesn’t make sense.

Kenn

Kenn,

Sorry, I just re-read your message more closely. If there’s a syntax
error in the Perl, then the error will be logged and the scrip won’t
run. But if the syntax is OK and is just not doing what you want, it
will run but give you unwanted results.

Steve

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:

I used “==” in the second comparison instead of “eq” because that’s what
you had. It should work because the CF id is an integer and
get_custom_id() returns an integer or undef, so you’re comparing
integers. Sometimes perl is pretty good about making things work when they
aren’t quite correct, so using “eq” might work also.

I don’t know enough about perl’s guts to be able to say why the "{ … }"
block returns true every time. It’s an interesting question, maybe it’s a
property of code blocks that they are always true. I just know that
{braces}, (parentheses), and [brackets] are not interchangeable.

Gene

At 09:09 AM 5/18/2007, Kenneth Crocker wrote:

Kenn,

The following code might do what you need - it’s taken from a similar
scrip we use.

Steve

my $trans = $self->TransactionObj;

if ($trans->Type eq ‘CustomField’) {
my $cf = new RT::CustomField($RT::SystemUser);
$cf->LoadByName(Queue => $self->TicketObj->QueueObj->id,
Name => “Approval-Status”);
return 0 unless $cf->id;
if ($trans->Field == $cf->id && $trans->NewValue
&& $trans->NewValue eq “Reviewing Request” ) {
return 1;
}
}

return 0;

Stephan,

A question; why do you have ($trans->NewValue
      && $trans->NewValue eq "Reviewing Request")

in the code? it looks like $trans->NewValue is in there twice. I don't 

understand why it is not just

if ($trans->Field == $cf->id &&
         $trans->NewValue eq "Reviewing Request" )
         return 1;

I'm learning here, so please be patient. Thanks.

Kenn
LBNL

Stephen Turner wrote:

At Friday 5/18/2007 01:19 PM, Kenneth Crocker wrote:

Stephan,

    A question; why do you have ($trans->NewValue
     && $trans->NewValue eq "Reviewing Request")

    in the code? it looks like $trans->NewValue is in there 

twice. I don’t understand why it is not just

    if ($trans->Field == $cf->id &&
        $trans->NewValue eq "Reviewing Request" )
        return 1;

    I'm learning here, so please be patient. Thanks.

Kenn
LBNL

Hi Kenn,

No problem - you’re probably right - that first bit (
$trans->NewValue ) may be superfluous. I was checking for null
before doing the comparison, but I don’t think Perl would object if
that null check weren’t there.

Steve

Stephan,

I have another question; why all the references to QueueObj? On page 

129 of the RT Essentials book (in reference to Transactions, I am
assuming transactions generated by changing a field, etc.) it says “For
updates that alter a field or custom field, field tracks what was
changed”. That sounds to me like all I should need to refer to is the
name of the field, not what Queue it is in. I can’t find an easy
reference to this kind of relationship. I find that the RT Essentials
book could do a MUCH better job of making some of this stuff easier to
understand, like more specific examples and models of various code (like
how to trigger a notification from a CF being changed or how to do that
plus modify another field (custom or otherwise)). It would seem to me
that for beginners like myself, simple little things like that would
make a world of difference in our ability to get some simple
modifications going.
Jesse, how about it? Is a new and updated release due out soon?

Kenn
LBNL

Stephen Turner 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:

At Friday 5/18/2007 01:33 PM, Kenneth Crocker wrote:

Stephan,

    I have another question; why all the references to 

QueueObj? On page 129 of the RT Essentials book (in reference to
Transactions, I am assuming transactions generated by changing a
field, etc.) it says “For updates that alter a field or custom
field, field tracks what was changed”. That sounds to me like all I
should need to refer to is the name of the field, not what Queue it
is in. I can’t find an easy reference to this kind of relationship.
I find that the RT Essentials book could do a MUCH better job of
making some of this stuff easier to understand, like more specific
examples and models of various code (like how to trigger a
notification from a CF being changed or how to do that plus modify
another field (custom or otherwise)). It would seem to me that for
beginners like myself, simple little things like that would make a
world of difference in our ability to get some simple modifications going.
Jesse, how about it? Is a new and updated release due out soon?

Kenn
LBNL

Hello Kenn,

RT allows you to have many custom fields with the same name - you
could have more than one queue with an “Approval-Status” custom
field, for example. So you need to specify the queue when getting a
custom field so that you get the right one. However, I just noticed
that RT allows you to have multiple fields with the same name in the
same queue, so the uniqueness of field name & queue is not enforced.
In reality though, you wouldn’t choose to have the same name for
multiple fields in a queue, so the assumption that queue and field
name uniquely identifies a queue-custom field is probably a safe one.

Steve

Gene,

I created the CF as "select one value" and a list of about 6 different 

values, all of which show when update the cf. It is applied to “Tickets"
and I have it applied to the Queue I am using for the test. That’s why
the error doesn’t make sense to me. Every time I change it to some
different value within the drop down I get that error message. Is there
something else I was supposed to do? I have a group with the
"SeeCustomField” and “ModifyCustomField” rights (I am a member) as well
as I am also a superuser. Again, RT Essentials doesn’t seem to include a
description of the various relationships that exist or are required for
permissions to work like one would expect. They need a
new/updated/improved release of that book.

Kenn
LBNL

Gene LeDuc wrote:

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:

Stephen,

Thanks a bunch. I used your code (with a little modification) as follows:

my $trans = $self->TransactionObj;
my $ticket = $self->TicketObj;

if ($trans->Type eq ‘CustomField’)
{my $cf = new RT::CustomField($RT::SystemUser);
$cf->LoadByName(Queue => $ticket->QueueObj->id,
Name => “Approval-Status”);
return 0 unless $cf->id;
if ($trans->Field == $cf->id &&
$trans->NewValue eq “Reviewing Request”)
{
return 1;
}
}

return 0;

and it worked real well. I guess I just didn't realise the QueueObj 

requirement for identifying a field in the transaction record for this.
I won’t forget now. I STILL believe that someone should put out an
"Essentials" book for morons with all kinds of simple examples to model
after. Thanks again. Now all I have to do is add some more code to
modify another custom field and the ticket status while it sends out the
notification.

Kenn
LBNL

Stephen Turner wrote: