[rt-users] Notification sent to requestor even when squelched

[Marcos Orallo]

Hi Alex,

Thanks for your reply. My comments inline.

2015-06-22 19:46 GMT+02:00 Alex Vandiver <alex at chmrr.net>:

> On Mon, 22 Jun 2015 19:10:50 +0200 Marcos Orallo <m_orallo at yahoo.es>
> wrote:
> > I manage an RT 4.2.11 deployment using Debian Wheezy, Apache 2.2,
> > mod_fcgid
> >
> > Today we had a very concerning issue regarding a notification being
> > sent to a requestor even when it had been explicitly unchecked in the
> > recipients list. At first I didn't believe the user, but then I found
> > this in the log:
> > [snip]
>
> There's a 47-second interval between the first and the second of
> those.  Can you show the full log of everything between them?


That's the full log, nothing in between (syslog, "info" level). The gap is
indeed strange...


> My guess is that the first one was a "dry run" to list the potential
> recipients,
> and the second was the actual submission.  This would explain the
> different process IDs, as well as the different behaviors.
>

But the "blacklisting" happened just for that transaction when composing
the message, it was not a permanent squelch. So the system didn't know it
was blacklisted in the preparation stage...


>
> > You can see that the requestor address was unchecked, but he was
> > notified anyway. The notificatoin script uses a custom condition to
> > just send the notification when using the web interface, with the
> > possibility of squelching recipients manually. The default behaviour
> > (implicit notification to all requestors even for correspondence by
> > mail) was confusing for my team mates.
>
> Your wording is confusing.  Is this jut the stock "Notify Requestor and
> Ccs" action, with a custom condition?
>

Exactly. This is the custom condition, taken from RT wiki, IIRC.

my $trans = $self->TransactionObj;
return 0 unless $trans->Type eq "Correspond";

my $msgattr = $trans->Message->First;
return 0 unless $msgattr;

return 1 unless $msgattr->GetHeader('Received');
return 0;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20150622/28220324/attachment.htm>