Privacy bug leads to internal notes being sent to customers. Confirmation?

Hi,
I use OTRS 3.3.7 but from what I saw on github the problem is also present
in 4.x.
Problem: When an event notification (ADMIN->Notifications (Event)) with

Hi Iosif,
The AGENT ARTICLE is simply documented as the last article the agent
saved in the ticket. Whether this is internal or external does not
matter.
I know organisations that use 'internal notes' to close the ticket and
set up an event based notifications to push these notes out to
customers.
If you don't want to send the last Agent Article to the customer then
don't use the tag.
It's more or less similar to not use the tag
Hi,
I use OTRS 3.3.7 but from what I saw on github the problem is also present in 4.x.
Problem: When an event notification (ADMIN->Notifications (Event)) with
in its text is fired, if the latest article added by an agent is an internal note, then the body of the generated notification email will contain the first 10 lines of the internal note. Seeing how these notifications are registered in history as SendCustomerNotification, then it's very debatable they should have access to internal notes at all.
Repro steps: 1. Configure an event notification triggered when ticket state is changed, to be sent to the customer or an arbitrary email address, with article body containing
2. Customer posts a new ticket (state is "new") 3. Agent posts an internal note (state is not changed) 4. Customer adds an article to the ticket and changes the state from "new" to "open" => email notification is sent to customer containing lines from the internal note Is the problem correctly identified? Is there a workaround?
/bogdan
P.S: Here is the relevant code from v3.3.7, Kernel\System\Ticket\Event\NotificationEvent.pm, line 725:
All articles are retrieved in @ArticleBoxAgent and then the latest one sent by an agent is taken in %ArticleAgent, regardless of whether or not it's an internal note.
# latest customer and agent article my @ArticleBoxAgent = $Self->{TicketObject}->ArticleGet( TicketID => $Param{TicketID}, UserID => $Param{UserID}, DynamicFields => 0, ); my %ArticleAgent; for my $Article ( reverse @ArticleBoxAgent ) { next if $Article->{SenderType} ne 'agent'; %ArticleAgent = %{$Article}; last; }
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev

Michiel, thanks for the reply.
I understand that the tag is currently used as is and so it could be a
problem if it chances.
Even so, I believe there's a strong argument for incoherence/bug with the
way it works now. A notification that is designed to be recorded in history
as Send---->Customer<----Notification has access to internal notes which
are by design NOT for customers. It's reasonable to believe there are more
OTRS users who would be unhappy about their internal notes being exposed to
customers than those who are happy with that. I can tell you that my
support people entered panic mode when they found out about it and
immediately halted all customer notifications.
One way forward would be to introduce a new tag, as you suggested.
I propose an alternative: make the current tag ignore internal notes if
"Notification article type" is "email-notification---->ext<---". I think
the field is not used for any other decision from what I saw in code.
It's easy to implement and would still allow all behaviors.
/bogdan
On 25 September 2015 at 00:01, Michiel Beijen
Hi Iosif,
The AGENT ARTICLE is simply documented as the last article the agent saved in the ticket. Whether this is internal or external does not matter. I know organisations that use 'internal notes' to close the ticket and set up an event based notifications to push these notes out to customers.
If you don't want to send the last Agent Article to the customer then don't use the tag. It's more or less similar to not use the tag
if you don't want to send out the password to your database in notifications! Of course, I can understand it if you'd need a tag to LAST_ARTICLE_AGENT_SENT_TO_CUSTOMER or similar :D but that's a different story - and currently not available out of the box in OTRS.
-- Michiel
On Wed, Sep 23, 2015 at 12:22 PM, Bogdan Iosif
wrote: Hi,
I use OTRS 3.3.7 but from what I saw on github the problem is also present in 4.x.
Problem: When an event notification (ADMIN->Notifications (Event)) with
in its text is fired, if the latest article added by an agent is an internal note, then the body of the generated notification email will contain the first 10 lines of the internal note. Seeing how these notifications are registered in history as SendCustomerNotification, then it's very debatable they should have access to internal notes at all.
Repro steps: 1. Configure an event notification triggered when ticket state is changed, to be sent to the customer or an arbitrary email address, with article body containing
2. Customer posts a new ticket (state is "new") 3. Agent posts an internal note (state is not changed) 4. Customer adds an article to the ticket and changes the state from "new" to "open" => email notification is sent to customer containing lines from the internal note Is the problem correctly identified? Is there a workaround?
/bogdan
P.S: Here is the relevant code from v3.3.7, Kernel\System\Ticket\Event\NotificationEvent.pm, line 725:
All articles are retrieved in @ArticleBoxAgent and then the latest one sent by an agent is taken in %ArticleAgent, regardless of whether or not it's an internal note.
# latest customer and agent article my @ArticleBoxAgent = $Self->{TicketObject}->ArticleGet( TicketID => $Param{TicketID}, UserID => $Param{UserID}, DynamicFields => 0, ); my %ArticleAgent; for my $Article ( reverse @ArticleBoxAgent ) { next if $Article->{SenderType} ne 'agent'; %ArticleAgent = %{$Article}; last; }
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
participants (2)
-
Bogdan Iosif
-
Michiel Beijen