Including articles and attachnents to notification emails

[AlexandrAbakumov]

I need to include all the articles and all the attachnents of a ticket to the email notification when ticket is created or changed (added article or attachment).
I tried to setup the Notification (Event) and use <OTRS_CUSTOMER_*>-like fields but it seems like there is no suitable fields for my situation. Probably, the whole idea of this solution is wrong. But what are the alternatives?

So my question is:
What is the best practice to send ticket email notifications with all the articles and all the attachnents of this ticket included to this email?
Is it possible out-of-the-box or I need to implement this by myself?

[crythias]

I need to include all the articles and all the attachnents of a ticket to the email notification when ticket is created or changed (added article or attachment).

Not going to happen. The information is already available at the website. The agents should be using the website to handle the request, anyway, so giving them everything that's at the website makes the website redundant, besides which, what's the first thing the agent is going to do? Reply to the message/customer? And then the customer will have the entire thread, including the "inside" information that's agent only.

[AlexandrAbakumov]

This is not about agents, but the part of integration.

Emails is supposed to be used in another system and have to:
1. indicate the fact that something is changed in a ticket
2. contain comprehensive set of fields used by another system including all the articles and all the attachments of the changed task

So what I'm supposed to do to meet this requirements?

[crythias]

1. indicate the fact that something is changed in a ticket

Which would be the fact that a notification is sent. Specifically, who makes a change to the ticket? If the agent, what kind of change would he make? It's in the ticketing system. He's not going to get notifications for things he does, and if the ticket is locked to him, nobody else will (or needs to) get notification, except if the agent responds to the customer through the system and then the customer gets that notification.

If the customer responds, if the ticket is locked, only the owner, responsible, and watchers get notification, but the content is still in the ticketing system. If the ticket is unlocked, all agents with "My Queues" is sent a notification that "something happened" in the ticket. (What happened? Well, whatever the type of action is, but if you want more information, go to the website to get that information.)

2. contain comprehensive set of fields used by another system including all the articles and all the attachments of the changed task

Who gets this and why? Why would anything need that 15MB attachment from the first article every. single. time. a change is made? This ticket just got "changed" 50 times over its life. That means something just got the 15MB attachment 50 times over the life of the ticket, and all the other attachments. So, what's likely to be 15MB is now 750MB plus plus plus. And for what purpose? To fulfill a requirement. What can I say? It never makes sense to do this.

[AlexandrAbakumov]

What can I say in my turn? Your point of view can take place for sure.
But from the other side, why intentionally restrict use cases of a system when there is no any visible special need?
For me as a customer of OTRS and a developer, it is a little bit strange why I can send, for instance, a ticket body text in the email notification every time I want but not allowed to send another "requisites" of the ticket by my choice such as list of its articles and attachments.
The problem really is in the potentially huge size of the notification emails? But stop! This is the responsibility of a guy who embeds a solution based on OTRS to bother about this kind of things. You're (meaning a OTRS team's staff) just expected to provide an comprehensive framework that can be tuned to meet various customer's requirements.

I beleive this kind of limitations is the thing that makes no sense.

And as a developer, I have certain requirements to the system I'm working at and can't just change it because it makes no sense in terms of OTRS especially when I don't see any reason for that limitation.

I beleive the whole issue can be resolved with a minimal coding. But I just would like to make it sure before diving into the OTRS sources.

[jojo]

you can turn a car into a boat with some changes, but still it is not intented to be used as a boat.

Your usecase does not make any sense and violates common sense standards of system to system communications. There is no technical need to copy everything everytime.

Why are you not using webservices and trigger communication by events?

[crythias]

I'm a programmer, too. I can send all the data or a pointer to the data.

It does not make sense to duplicate data, especially multiple times. The *first* time you get the fields you want, your recipient has the information. He should never need it again, but reference it from the first time he got it.

But even if he had *one* additional copy of the data, he should have access to the data at source one or source two. How [term redacted] is it to say "oh, you know that stuff you sent me 5 minutes ago? Send it to me again because you made a change." Not only is it not sufficient that the information is available in the place it's supposed to be, the duplicate place is so useless as to completely forget everything it just received.

[AlexandrAbakumov]

Why are you not using webservices and trigger communication by events?

This is obviously my second option.
But AFAIK I need to implement custom invoker to use this aproach since there is no one out-of-the-box.
And, in addition, I have to implement a SOAP service that this invoker would send messages to.
Am i right?
And if so, is there a suitable invoker maybe as part of some OTRS Feature Add-On?

[Giulio Soleni]

Hallo

And if so, is there a suitable invoker maybe as part of some OTRS Feature Add-On?

Generic Interface is available since the 3.2.x versions as a core part of OTRS, no add-on required... as jojo suggested you should be able to configure OTRS as invoker and trigger the communication on specific ticket events. http://otrs.github.io/doc/manual/admin/ ... rface.html

Otherwise, taking a different approach, you may take a look at /opt/otrs/bin/otrs.GetTicketThread.pl and build up a module or wrap this command inside another perl script developed to your goal.

HTH
Giulio

[AlexandrAbakumov]

Giulio, thanks for helping!

Generic Interface is available since the 3.2.x versions as a core part of OTRS, no add-on required... as jojo suggested you should be able to configure OTRS as invoker and trigger the communication on specific ticket events

To configure OTRS as invoker, there have to be a suitable invoker registered in OTRS, but I don't know where it can be found.
All I could find is Test:Test and Test:TestSimple invokers that barely could be used for serious purposes.
So, if I'm not mistaken, I have 2 options: whether I have to implement my own invoker, or there could be an invoker that meets my needs as part of some OTRS Feature Add-On.
This is why I asked about OTRS Feature Add-Ons.