[rt-users] AdminCC on Queue Change
Scott Koch
scottkoch at gmail.com
Wed Sep 14 15:48:06 EDT 2016
Thanks for the response, I think you may have misinterpreted my issue, see
below. RT is hard to talk about due to the language overlap(English words
and RT terms), so I may have said something confusing.
On Wed, Sep 14, 2016 at 3:33 PM Matt Zagrabelny <mzagrabe at d.umn.edu> wrote:
> On Wed, Sep 14, 2016 at 1:20 PM, Scott Koch <scottkoch at gmail.com> wrote:
> > RT Version: 4.2.12 (install has existed since 2003 and survived many
> major
> > upgrades)
> >
> > Expected Behavior: When I move a existing ticket from one queue to
> another,
> > the new queues AdminCCs will apply to that ticket for future comments and
> > correspondences. I'm not expecting to see that particular tickets's
> AdminCC
> > settings change, but I expect when a comment is made that the queues
> AdminCC
> > members show up in the BCC field of comment and correspondence emails.
> >
> > Actual Behavior: On comments and correspondences to the moved ticket, it
> > behaves as if there are no AdminCCs set on that queue, despite there
> being
> > queue-wide AdminCCs set. The queue in question works as expected for the
> > same AdminCCs when a ticket is created directly in that queue. I am not
> on
> > the AdminCC list, so my actions should not be subject to the NotifyActor
> > setting.
>
> The way you worded this last sentence gives the impression that you
> have a different understanding of NotifyActor than I do. Perhaps it is
> just how I read the sentence, but perhaps not.
>
> NotifyActor doesn't necessarily have anything to do with AdminCcs. It
> has to do with the creator of the transaction (actor) and any email
> recipients from scrips that would fire off from said transaction.
> Generally "Notify" type actions will check if any of the recipients
> are the actor of the txn, if they are, then those recipients won't get
> an email - unless a configuration is set to do so.
>
>
I only mentioned NotifyActor to demonstrate to my audience that this
setting isn't affecting the desired result, due to my user being the only
user listed in the AdminCC setting(which is not the case). Forget I even
mentioned it.
> > I am trying to figure out if this feature, lets call it "Tickets moved
> to a
> > new queue are affected by AdminCC of new queue", should be:
> > - Something that should just work in RT out of the box(not a
> > scrip/extention/site modification etc), this was my assumption initially
>
> Nope. It would be a scrip.
>
The scrip you mention below is to notify on a ticket changing queues, that
is not the feature I am chasing. I want the list of emails in the
queue-wide AdminCC to get the typical notifications on all future comments
and correspondences made to tickets(specifically tickets that are moved
into a new queue). This feature works for tickets created in the original
queue, and I don't see a script thats doing the notifications, so I assume
its a built in RT feature?
>
> > - Something that is handled by a default scrip (we have done a lot of
> scrip
> > additions, modifications, and possibly deletions? so i'm suspect of our
> > current scrips)
>
> I don't recall if there is a scrip out of the gates that does this. From:
>
> https://github.com/bestpractical/rt/blob/stable/etc/initialdata
>
> it doesn't look like there is a notify for ticket's queue changing.
>
> > - Something that we can create our own scrip to handle
>
> Here is our scrip. It runs under transaction batch:
>
> rt4=# select * from scrips where id = 75 :G
> -[ RECORD 1
> ]----------+-----------------------------------------------------------------------
> id | 75
> description | On Queue Change if Owner is Nobody Notify AdminCcs
> scripcondition | 10
> scripaction | 8
> customisapplicablecode | my $is_queue_changed = 0;
> | my $is_owner_changed = 0;
> |
> | # We make a note of the owner because we have
> another scrip
> | # which will email the AdminCcs if the owner
> is being changed
> | # to or from Nobody
> |
> | my $is_owner_nobody =
> ($self->TicketObj->Owner == RT::Nobody->id);
> |
> | my $batch = $self->TicketObj->TransactionBatch;
> |
> | if ($batch && ref($batch)) {
> | for my $txn (@$batch) {
> | if (($txn->Field || q{}) eq 'Queue') {
> | $is_queue_changed = 1;
> | }
> | elsif (
> | ($txn->Field || q{}) eq 'Owner'
> | &&
> | ($txn->Type || q{}) eq 'SetWatcher'
> | ) {
> | $is_owner_changed = 1;
> | }
> | }
> | }
> |
> | return ($is_queue_changed && !
> $is_owner_changed && $is_owner_nobody);
> custompreparecode |
> customcommitcode |
> template | Queue Change
> creator | 123670
> created | 2014-06-09 21:08:54
> lastupdatedby | 123670
> lastupdated | 2014-06-09 21:09:44
> disabled | 0
>
>
>
> > - Or am I completely missing something?
>
> I don't think you are missing anything. If it used to work, then check
> your scrips and if those look in order, look at logs or start adding
> debugging statements to the code.
>
> > Any information that can be provided about how queue AdminCCs apply to
> > tickets(especially those moved to the queue, instead of create) would be
> > greatly appreciated.
>
> Queue adminccs exist as well as ticket adminccs - at the end of the
> day, they are both adminccs, but the queue ones exist more in the
> background - you don't see them on the ticket display page.
>
> -m
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20160914/ca0e0ecb/attachment.htm>
More information about the rt-users
mailing list