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:
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.
The only odd thing I can see in the log is that the “Blacklisted” and the
“sent to …” entries are written by two different perl processes (PID 6157
and 6145 respectively). That didn’t happen when I tried to reproduce the
issue (with no success).
Does anyone know if that’s normal in mod_fcgid? Could it be the cause of
the problem?
It’s a big problem for us if we cannot fully trust the platform to not
spread confidential information to unintended recipients.
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? 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.
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?
It’s a big problem for us if we cannot fully trust the platform to not
spread confidential information to unintended recipients.
Along with Alex’s suggestions / questions, it sounds like this workflow
would benefit from the comment functionality. Ticket comments allow
communication via your internal team (AdminCCs) but do not notify
Requestors and Ccs.
Thank you for the suggestion. However, in this case, it was a Reply with
One-Time-CCs, so I guess a Comment is not the best option. Moreover, we
don’t have control of the mail domain, and you wouldn’t believe the
bureaucracy and delay to get a mail alias for comments.
It’s true that our use of the system is not always adapted to the platform,
my colleagues want the WebUI to be basically a mail client on steroids.
They want all external recipients to be explicit, either when sending a
mail from their client, or in the webUI message composing screen.
Even if I understand the design of RT, I think a few features would make it
come close to what users are most accustomed to in a mail client, and make
it more flexible:
Correspondance subject independent from the ticket title. Copied from the
transaction that you are replying to.
Default recipients selected based on the sender of the transaction you
are replying to, even if they are not the Requestors (with the full list of
Requestors available for checking if desired).
One-Time-To. There is an extension for this, but I couldn’t make it work
properly with RT 4.2.
Preserved To, CC in mail notifications, by setting them to a different
value independent from the SMTP envelope.
Show full list of recipients for transactions in History
It’s a big problem for us if we cannot fully trust the platform to not
spread confidential information to unintended recipients.
Along with Alex’s suggestions / questions, it sounds like this workflow
would benefit from the comment functionality. Ticket comments allow
communication via your internal team (AdminCCs) but do not notify
Requestors and Ccs.
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;
