#{article.body_as_html} uses the last article, even private ones

Infos:

  • Used Zammad version: 3.3.x
  • Used Zammad installation source: package
  • Operating system: Debian 4.9.189-3+deb9u2 (2019-11-11) x86_64 GNU/Linux
  • Browser + version: any

Expected behavior:

  • #{article.body_as_html} should use the last public article, i.e. no private notes

Actual behavior:

  • #{article.body_as_html} uses the last article, even if it is set to private

Steps to reproduce the behavior:

  • Create automation/scheduler that sends an e-mail notification to the customer with #{article.body_as_html} in the subject/content
  • Add a private note to a ticket
1 Like

I am no developer but I would think this works as intended. Maybe s.o. wants to send an email via trigger to internal agents and they should see the private note. You can prevent sending private notes to customers by adding the condition Article -> Visibility -> public in your trigger and automation.

2 Likes

Correct. This is working as designed. :slight_smile:

Honestly I don’t think that the system should—ever—send private/internal notes to anyone except agents or admins…

I understand that {#article.xyz} refers to the latest article within a ticket—and while I think that the current way absolutely suits the internal communication (hence “is working as designed”), there should definitely be a way to remind customers of an open ticket—ideally including the last message from the agent to the customer. E.g. Zendesk does it with a variable named ticket.public_comments_formatted.

Also, something like this was suggested by @martini a while ago…

(edited a few times for cleanup)

As this is possible via triggers and schedulers, one might to this intentionally and thus it’s possible.

Currently, at least in the workflow we’re talking about, Zammads triggers always handle something because of the article the trigger got fired for. I understand that this might not fit your use case, but that would be a feature request.

If the community agrees, I’m sure this won’t be an issue to implement.
I can’t provide more information on if or if not at this moment, sorry.

I’d love to contribute, but as always—:smiley: sorry!—I don’t know where to start. If someone could point me in the right direction, I’d owe them a beer! :joy:

Found it and tried to implement it:

Let me know what you think :slight_smile:

2 Likes

Thanks for your effort. A developer will have a look as soon as we find time.

I can’t qualify those changes well enough. :slight_smile:

1 Like

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.

@thorsteneckel on GitHub:

Today we had an internal discussion with the team about this pull request. Unfortunately we can’t take this PR into our codebase and maintain it. We think the underlying issue is the lack of a proper template engine in Zammad that would enable the administrator to build advanced templates without the need of changing the code. That would also come with the benefit of a clean and maintainable architecture for us maintainers.

Asking you to integrate a whole template engine would totally not be feasible - that’s clear to us. Therefore we would suggest to migrate your changes into an community addon until we’re ready and making it available over at the community board.

Sorry it took me so long! While I still think part of that functionality should be in Zammad’s core—at least regarding sending automated ticket reminders to customers like for example Zendesk does—I would love to create a community add-on.

Whenever you find the time, please tell me where to start. Thanks in advance!

1 Like

This thread may help you on your journey:

1 Like

Can this some how be accomplished by using #{article.internal} and if that is true then include #{article.body}

Like !#{article.internal}.#{article.body} would only print the body if internal was false

Is this a request for change or an add on ?

I also very much would like to have a variable “article.last-public-comment” but since this doesn’t exist, I implemented a workaround. This has already been mentioned, but I wanted to share how I did this:

There are 3 cases how you can close a ticket:
1 - add public comment, set status to closed and update the ticket for both changes
2 - add private comment, set status to closed and update the ticket for both changes
3 - add private or public comment, update the ticket. Then set status to closed and update the ticket again

For case 1 I implemented a trigger like:
If status is closed, action is update, visibility is public
then E-Mail with visibility public to customer with text in the body #{article.body_as_html}

So when you write a public note and close the ticket simultaneously, the customer will get this note in the notification-email that the ticket was closed and doesn’t have to check the ticket.

For case 2 and 3 I implemented the following trigger:
If status is closed, action is update
then E-Mail with visibility public to customer without text in the body #{article.body_as_html}

Now the customer will only get the basic text that the ticket was closed. He needs to manually check the ticket in the portal to see the public comments inside.

That’s not ideal, but this way no private notes are sent out and if you write your note while closing the ticket, it will still receive the customer.

On the other hand, when writing a note inside the ticket, the customer gets an email notification anyway (we set it up like that), so no public notes are hidden that the customer wasn’t informed about.

Maybe this helps others as well :slight_smile:

You should open a feature request if you want to request a feature. Doing so somewhere on a long thread won’t help at all.

You can do so here:

Looking at the thread there were already some discussions and a try to implement this, so maybe there’s already being some work done.
That’s why I didn’t want to request the feature here but rather share with the community how we managed to get around this while it doesn’t exist (yet).

2 Likes