Hi Alex,
Thanks for your reply. My comments inline.
2015-06-22 19:46 GMT+02:00 Alex Vandiver <a...@chmrr.net>:
> On Mon, 22 Jun 2015 19:10:50 +0200 Marcos Orallo <m_ora...@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;
