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 <michiel.bei...@gmail.com>
wrote:
> 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 <OTRS_CONFIG_DatabasePw>
> 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 <bogdan.io...@gmail.com>
> 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
> > <OTRS_AGENT_BODY[10]> 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 <OTRS_AGENT_BODY[10]>
> > 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
>
_______________________________________________
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
