[rt-users] Help with code identifying QueueWatcher AdminCc

[Kenneth Crocker]

Kevin,

Actually, no. I didn't. but it still worked and now I'm wondering why.
However, I made the change so that it is coded correctly. AHH! I see why it
worked before. The "HasMamber" subroutine ends if it is called with an
argument that isn't a PrincipalId. Since I didn't use an Id related to a
correct object, it ended and since that scrip was an "Extra" notification
that I wanted to drop under those circumstances, "HasMember" ending made it
look like it worked. I double checked against the logs and yes, that code
was wrong. I just checked it again and it worked without the error message.

Good catch, Kevin. Must be why they pay you the "big Bucks"! ;-).

Kenn
LBNL

On Mon, May 2, 2011 at 8:33 AM, Kevin Falcone <falcone at bestpractical.com>wrote:

> On Fri, Apr 29, 2011 at 02:08:49PM -0700, Kenneth Crocker wrote:
> >    Kevin,
> >
> >    Got it. This is what works:
> >
> >    Custom Condition:
> >    # Initiate Email when Ticket is created & Requestor or Owner are NOT
> AdminCc
> >
> >    my $trans = $self->TransactionObj;
> >    my $ticket = $self->TicketObj;
> >    my $queue = $ticket->QueueObj;
>
> That doesn't look quite right, since you can't call HasMember on a
> QueueObj.  I assume you were doing $ticket->QueueObj->AdminCc to get a
> group?
>
> -kevin
>
> >    my $owner = $ticket->OwnerObj->PrincipalID;
> >    my $requestor =
> $ticket->Requestors->UserMembersObj->First->PrincipalId;
> >
> >    if ($queue->HasMember($owner) or
> >    $queue->HasMember($requestor))
> >    {
> >    return 0;
> >    }
> >
> >    return ($trans->Type eq "Create");
> >    return 0;
> >
> >    Thanks for your help.
> >
> >    Kenn
> >    LBNL
> >
> >    On Fri, Apr 29, 2011 at 9:40 AM, Kenneth Crocker <[1]
> kfcrocker at lbl.gov> wrote:
> >
> >      Kevin,
> >
> >      HA! Well, as I'm sure you've noticed, the world of RT Users seem to
> find a LOT of things
> >      they want to do that NO ONE could have planned for. I think it's a
> @#$%#$%^ good product.
> >      There will ALWAYS be someone, including me, that would wish RT did
> things this way or that,
> >      but you guys really do put out a helluva good product.
> >
> >      My forte has always been as a project leader (in design and QA) from
> large mainframe systems
> >      on down to mini-computers (pre-cursor to PC's and Client-server
> systems) for 40 yrs, so it's
> >      easy for me to look at something and have that perfect 20/20 vision
> that hindsight gives
> >      you. If we all had those "well, I shoulda done it this way" ideas in
> the beginning, I'd be
> >      willing to bet you would STILL get some bitching here or there.
> That's why someone create
> >      the "version number x.xx" for software, he he.
> >
> >      Great job. I'm looking forward to playing with 4.0 soon.
> >
> >      Kenn
> >      LBNL
> >
> >      On Fri, Apr 29, 2011 at 9:21 AM, Kevin Falcone <[2]
> falcone at bestpractical.com> wrote:
> >
> >        On Fri, Apr 29, 2011 at 09:17:44AM -0700, Kenneth Crocker wrote:
> >        > Got it. Thanks. I think I'm getting a LITTLE better at this,
> believe it or not.
> >
> >        Great. I would love IsWatcher to search Queue watcher groups also,
> >        but it's not something I've even sketched code for.
> >        >
> >        > On Thu, Apr 28, 2011 at 8:09 PM, Kevin Falcone <[1][3]
> falcone at bestpractical.com> wrote:
> >        >
> >        > On Thu, Apr 28, 2011 at 03:47:40PM -0700, Kenneth Crocker wrote:
> >        > > To List,
> >        > >
> >        > > I've got some code that I'm using to try and identify certain
> users as the Queue
> >        AdminCc.
> >        > I
> >        > > want to do this so I can stop sending emails to Queue
> AdminCc's when they are also the
> >        > > Requestor or Owner. The code is as follows:
> >        >
> >        > If you want to check Queue AdminCc's not Ticket AdminCcs, you
> need to
> >        > look at the queue ($ticket->QueueObj) not the $ticket
> >        >
> >        > $ticket->QueueObj->AdminCc will give you an RT::Group and you
> want to
> >        > read about the HasMember method on groups
> >        > -kevin
> >        > >
> =======================================================================
> >        > > # Initiate Email when Ticket Status is created and Requestor
> or Owner are not Queue
> >        > AdminCc
> >        > >
> >        > > my $trans = $self->TransactionObj;
> >        > > my $ticket = $self->TicketObj;
> >        > > my $owner = $ticket->OwnerObj->EmailAddress;
> >        > > my $requestor =
> $ticket->Requestors->UserMembersObj->First->EmailAddress;
> >        > >
> >        > > if ($ticket->IsWatcher(Type => 'AdminCc', EmailAddress =>
> $owner) or
> >        > > $ticket->IsWatcher(Type => 'AdminCc', EmailAddress =>
> $requestor))
> >        > > {
> >        > > return 0;
> >        > > }
> >        > >
> >        > > return ($trans->Type eq "Create");
> >        > > return 0;
> >        > > ==============================================================
> >        > >
> >        > > It always fails. I always get a couple emails going to the
> same person. I've tried
> >        using
> >        > > PrincipalID and Name as the identifiers and still no joy.
> >        > >
> >        > > I've also checked the code in Queue_Overlay.pm and I can't
> seem to see (I'mbasically a
> >        > perl
> >        > > newbie) where the Queue AdminCc is differentiated from the
> Ticket AdminCc, which we
> >        NEVER
> >        > use.
> >        >
> >        > References
> >        >
> >        > Visible links
> >        > 1. mailto:[4]falcone at bestpractical.com
> >
> > References
> >
> >    Visible links
> >    1. mailto:kfcrocker at lbl.gov
> >    2. mailto:falcone at bestpractical.com
> >    3. mailto:falcone at bestpractical.com
> >    4. mailto:falcone at bestpractical.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20110502/cf6bad27/attachment.htm>